MySQL репликация успешно, но ведомый не реплицируется

Я создал конфигурацию mysql master-slave, и все выглядит хорошо. «показать мастер статус»; на раб не показывает никакой ошибки. это выход

 Slave_IO_State: Waiting for master to send event
                  Master_Host: 109.123.100.58
                  Master_User: replica
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000001
          Read_Master_Log_Pos: 106
               Relay_Log_File: relay-bin.000001
                Relay_Log_Pos: 4
        Relay_Master_Log_File: mysql-bin.000001
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB: 
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 0
                   Last_Error: 
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 106
              Relay_Log_Space: 106
              Until_Condition: None
               Until_Log_File: 
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File: 
           Master_SSL_CA_Path: 
              Master_SSL_Cert: 
            Master_SSL_Cipher: 
               Master_SSL_Key: 
        Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error: 
               Last_SQL_Errno: 0
               Last_SQL_Error: 

Однако, похоже, что репликация на подчиненном устройстве не происходит, когда мастер претерпевает изменения.

На мастера. ПОКАЗАТЬ МАСТЕР СТАТУС

+------------------+----------+--------------+-------------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB        |
+------------------+----------+--------------+-------------------------+
| mysql-bin.000001 |   639495 |              | mysql,informationschema |
+------------------+----------+--------------+-------------------------+

на подчиненном ПОКАЗАТЬ ПРОЦЕСС

+-----+-------------+-----------+------+---------+-------+-----------------------------------------------------------------------+------------------+
| Id  | User        | Host      | db   | Command | Time  | State                                                                 | Info             |
+-----+-------------+-----------+------+---------+-------+-----------------------------------------------------------------------+------------------+
| 174 | system user |           | NULL | Connect | 25777 | Waiting for master to send event                                      | NULL             |
| 175 | system user |           | NULL | Connect | 25777 | Has read all relay log; waiting for the slave I/O thread to update it | NULL             |
| 199 | root        | localhost | NULL | Query   |     0 | NULL                                                                  | show processlist |
+-----+-------------+-----------+------+---------+-------+-----------------------------------------------------------------------+------------------+
3 rows in set (0.00 sec)

Я что-то пропустил

Вывод, который вы представили, очень запутанный. С одной стороны, мастер показывает:

mysql-bin.000001   639495 

Slave PROCESSLISTуказывает, что репликация работает (поток ввода-вывода подключен к мастеру, поток SQL ожидает).

Раб SHOW SLAVE STATUSснова утверждает, что все хорошо, но позиция хозяина есть 106.

Все эти выходы выдаются примерно в одно и то же время? Если нет, то они не ценны.

Я бы проверил следующее:

• Очевидное: 109.123.100.58действительно ли твой хозяин?
• Есть ли SHOW PROCESSLISTв главном списке соединение, установленное подчиненным replicaпользователем?
• У вас есть разные server-idнастройки для главного и подчиненного?
• У вас есть какие-либо replicate-do-*или replicate-ignore-*настройки в вашем mysql.cnfфайле?

Лучше, чем использовать binlog-ignore-db, это использовать подчиненную фильтрацию. Я застрял в подобной ситуации, да, мне потребовался целый день, чтобы понять:

Я пропустил что-то большое !!!

Разница между

--replicate-do-db=
--replicate-do-table=

На рабской стороне. А также

--replicate-do-table='mydb.%'

не работал для меня на -До стол. Я должен был использовать

--replicate-do-db='mydb'

Я думаю, это сработало бы для подстановочного знака

--replicate-wild-do-table='mydb.%'

... Теперь, чтобы выяснить, как копировать одну и ту же таблицу из нескольких мастеров. Хорошо, я понял это, MySQL не поддерживает это изначально; MariaDB 10 делает.

У меня также была другая проблема: мой пароль был длиннее 32 символов. Бу!

Я тоже сталкивался с этой проблемой. Коренная причина была в хозяине server_id=0. MariaDB имеет специальное поведение, для server_id=0которого не позволит репликации работать.

Идентификатор_сервера должен быть уникальным для каждого сервера в группе репликации. Если оставить значение 0, по умолчанию, до MariaDB 10.2.1, ведомое не будет подключаться к ведущему, а ведущее будет отклонять все подчиненные подключения.

Когда я начал индексирование на основе 1, все работало нормально.

Вы не сказали ведомому, какую БД реплицировать: переменная Replicate_Do_DB пуста.

Попробуйте добавить строку

replicate-do-db = name_of_db (где "name_of_db" - это имя базы данных для репликации)

в вашем my.cnf (на ведомом устройстве) и перезапустите подчиненный сервер.

РЕДАКТИРОВАТЬ: я не думаю, что мой ответ является правильным решением, в то же время ;-)

Возможно, посмотрите на эту страницу вместо этого: http://dev.mysql.com/doc/refman/5.1/en/replication-problems.html