☰

Диагностика проблем репликации Mysql

tag-icon • tag-icon mysql mysql-replication
Диагностика проблем репликации Mysql

У нас есть клиент репликации mysql, работающий на нашем резервном сервере. После сбоя питания на прошлой неделе он перестал реплицироваться. До этого он работал без перебоев в течение нескольких месяцев.

Я пробовал перезапускать и главный, и подчиненный сервер, но это не помогло. Я могу получить доступ к главному серверу с подчиненного сервера, так что проблема не в сети.

Могу ли я еще что-нибудь сделать, чтобы попытаться диагностировать проблему?

mysql> show slave status\G;
*************************** 1. row ***************************
             Slave_IO_State:
                Master_Host: master
                Master_User: username
                Master_Port: 3306
              Connect_Retry: 60
            Master_Log_File: mysql-bin.000060
        Read_Master_Log_Pos: 46277494
             Relay_Log_File: mysqld-relay-bin.000348
              Relay_Log_Pos: 98
      Relay_Master_Log_File: mysql-bin.000060
           Slave_IO_Running: No
          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: 46277494
            Relay_Log_Space: 98
            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: NULL
1 row in set (0.00 sec)

ERROR:
No query specified


mysql> show master status\G;
*************************** 1. row ***************************
            File: mysql-bin.000069
        Position: 851796
    Binlog_Do_DB:
Binlog_Ignore_DB:
1 row in set (0.00 sec)

ERROR:
No query specified

Обновление: Ошибки попадали в daemon.log, а не в mysql.err, что объясняет, почему я не мог их найти. Проблема, похоже, в том, что мастер говорит, что журнал недоступен, что не имеет особого смысла, поскольку этот журнал (и предыдущий) все еще доступны на мастере.

090710  9:17:35 [Note] Slave SQL thread initialized, starting replication in log 'mysql-bin.000060' at position 46277494, relay log './mysqld-relay-bin.000350' position: 98
090710  9:17:35 [Note] Slave I/O thread: connected to master 'username@master:3306',  replication started in log 'mysql-bin.000060' at position 46277494
090710  9:17:35 [ERROR] Error reading packet from server: Client requested master to start replication from impossible position ( server_errno=1236)
090710  9:17:35 [ERROR] Got fatal error 1236: 'Client requested master to start replication from impossible position' from master when reading data from binary log
090710  9:17:35 [Note] Slave I/O thread exiting, read up to log 'mysql-bin.000060', position 46277494

решение1

Добро пожаловать в чудесный мир репликации MySQL. Я сам не сталкивался с вашей конкретной проблемой, но я сталкивался со множеством других странных проблем, и приблизительное решение — просто повторная синхронизация с главным сервером, как будто это совершенно новый подчиненный сервер, и дело с концом.

решение2

Вам следует изучить журнал ошибок ведомого устройства — обычно в нем довольно подробно описано, в чем заключается проблема.

Вам следует привязать журналы ошибок MySQL к вашей системе мониторинга, в противном случае ваши подчиненные серверы потенциально бесполезны.

Кроме того, у вас должен быть монитор, проверяющий состояние ведомого устройства.

И чтобы от этого была хоть какая-то польза, вам также нужно будет время от времени проверять синхронизацию подчиненных устройств, возможно, используя что-то вроде mk-table-checksum; в идеале также привяжите результаты этого в свою систему мониторинга.

решение3

Многие устанавливают skip-slave-start, чтобы убедиться, что все в порядке, если подчиненный сервер перестает реплицироваться, прежде чем запускать его. Попробуйте запустить 'start slave' и посмотрите, изменится ли что-нибудь или что-нибудь зарегистрируется. Кроме того, странно, что процесс SlaveSQL запущен, а SlaveIO — нет. Возможно, что локальные журналы ретрансляции на подчиненном сервере были повреждены, хотядолженбыть сообщено в журналах. Вы можете попробовать остановить Mysql, а затем удалить журналы реле.

решение4

Из приведенного выше отчета я выяснил, что проблема заключается в том, что это поле должно быть установлено на (Slave_IO_Running): да, но в приведенном выше отчете отображается Slave_IO_Running: Нет.

Это вызывает проблему. Если эта переменная показывает «Нет», то поток ввода-вывода был остановлен. поэтому репликации больше нет. Вам придется проверить Last_SQL_Errno и Last_SQL_Err для получения дополнительной информации о причине. Номер ошибки 0 и сообщение пустой строки означают «нет ошибки». Last_SQL_Error появляется в журнале ошибок подчиненного устройства.

Чтобы устранить эту проблему, остановите ведомое устройство.

Затем установите:

mysql> SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;

Это говорит подчиненному серверу пропустить один запрос (который является недопустимым и вызвал остановку репликации). Если вы хотите пропустить два запроса, вы должны использовать SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 2; вместо этого и так далее.

Затем перезапустите подчиненное устройство и проверьте журналы. Надеюсь, это решит проблему...

Связанный контент