MySQL - ведомый поток SQL не применяет изменения

У меня есть реплика master/slave с 5 ведомыми и 1 master. Ведущий - mysql 5.1.37, а ведомые - 5.5.8.

Два дня назад один из рабов перестал работать. В "show slave status" я вижу, что поток IO и поток SQL работают. Поток ввода-вывода генерирует файлы релейного журнала, но поток SQL не применяет изменения... "Секунды позади мастера" показывают "0", хотя я знаю, что это далеко позади (Проверка binlog, используя mysqlbinlog).

Все остальные рабы работают нормально.

Не знаю, что искать (нет ошибок в файле журнала mysql и нет ошибок в системных журналах...)

любой совет? См. Ниже вывод статуса ведомого

mysql> show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: master-db
                  Master_User: replication
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.020839
          Read_Master_Log_Pos: 56173153
               Relay_Log_File: research-relay-bin.000002
                Relay_Log_Pos: 252
        Relay_Master_Log_File: mysql-bin.020828
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB: db1,db2,db3,db4
          Replicate_Ignore_DB: db5,db6
           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: 975734937
              Relay_Log_Space: 10714389571
              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:
  Replicate_Ignore_Server_Ids:
             Master_Server_Id: 300
Источник

1 ответ

Есть некоторые причуды, на которые нужно обратить внимание в MySQL Replication

1) Использование replicate-do-db и replicate-ignore-db одновременно

На странице есть блок-схема, показывающая порядок обработки. Лично я не использую replicate-do-db и replicate-ignore-db одновременно. Я использую один или другой. Если другие рабы не имеют такой же проблемы, исключите это.

2) ЗАГРУЗКА ДАННЫХ INFILE

То, как MySQL Replication справляется с этим, ужасно. Всякий раз, когда ЗАГРУЗКА ДАННЫХ INFILE выполняется в Мастере, весь входной файл помещается в двоичные журналы Мастера. Подчиненный собирает во входном файле в своих журналах реле. Ведомое устройство повторно материализует файл данных в папке / tmp, а затем выполняет LOAD DATA INFILE на ведомом устройстве. Это не считается задержкой репликации во время этого процесса. Как администратор БД MySQL, я знаю, что это работает, но это безвкусно!!!

3) Разрыв связи подчиненного потока ввода-вывода

Иногда из-за изменений брандмауэра, сетевой маршрутизации или некоторых других сетевых аномалий поток подчиненного ввода-вывода может просто перестать получать записи для заполнения своих журналов ретрансляции. Вы также можете проверить, что поток ведомого ввода-вывода виден в списке процессов мастера. Чтобы убедиться, что поток ввода-вывода вашего ведомого устройства жив, просто выполните следующие действия для всех ведомых устройств:

SHOW SLAVE STATUS\G

Следите за Relay_Log_Space. Это должно расти. Если он перестает расти, MySQL может просто зависнуть без ошибки по другой безумной причине, что приводит к предложению № 4.

4) Раб находится вне дискового пространства

Я написал пост о том, как MySQL зависает при выполнении операции MyISAM. MySQL использует таблицы MyISAM в качестве временных таблиц. Проверьте ваш каталог таблиц tmp по умолчанию (переменная tmpdir в MySQL)

Я надеюсь, что эти предложения помогут!!!

Источник
Другие вопросы по тегам