Mysql подчинен после синхронизации после сбоя

Question

У нас есть «1 мастер, 1 подчиненный» MySQL. У нас был внезапный перерыв в работе, который уничтожил раба. После того, как машину назад, я обнаружил, что раб был синхронизирован с мастером:

mysql> show slave status\G 
*************************** 1. row *************************** 
       Slave_IO_State: Waiting for master to send event 
        Master_Host: 10.0.0.1 
        Master_User: slave 
        Master_Port: 3306 
       Connect_Retry: 60 
       Master_Log_File: mysql-log.001576 
      Read_Master_Log_Pos: 412565824 
       Relay_Log_File: mysqld-relay-bin.002671 
       Relay_Log_Pos: 6930 
     Relay_Master_Log_File: mysql-log.001573 
      Slave_IO_Running: Yes 
      Slave_SQL_Running: No 
       Replicate_Do_DB: 
      Replicate_Ignore_DB: 
      Replicate_Do_Table: 
     Replicate_Ignore_Table: blah.table2 
     Replicate_Wild_Do_Table: 
    Replicate_Wild_Ignore_Table: 
        Last_Errno: 1032 
        Last_Error: Could not execute Update_rows event on table blah.info; Can't find record in 'info', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log mysql-log.001573, end_log_pos 689031225 
       Skip_Counter: 0 
      Exec_Master_Log_Pos: 689030864 
       Relay_Log_Space: 2944772417 
       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 
Master_SSL_Verify_Server_Cert: No 
       Last_IO_Errno: 0 
       Last_IO_Error: 
       Last_SQL_Errno: 1032 
       Last_SQL_Error: Could not execute Update_rows event on table blah.info; Can't find record in 'info', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log mysql-log.001573, end_log_pos 689031225 
    Replicate_Ignore_Server_Ids: 
      Master_Server_Id: 1 
1 row in set (0.00 sec) 

Мы используем Двоичный формат «ROW», поэтому, когда я пытаюсь использовать mysqlbinlog смотреть на я не вижу ничего полезного. Я не хочу просто устанавливать счетчик пропусков, потому что я думаю, что это еще больше не синхронизировало бы мой стол.

Есть ли что-нибудь, что я могу сделать на подчиненном устройстве, которое по существу «откидывается назад» к заданному моменту времени, где я мог бы затем сбросить номер основного журнала, пометку и т. Д.? Если нет, есть ли что-нибудь, что я могу сделать, чтобы вернуться к синхронизации?

Answer 1

Обычно можно восстановить из-за небольших расхождений с использованием pt-table-checksum и pt-table-sync.

Мне кажется, что ваш раб потерял свое место в двоичной логической последовательности, когда он сработает. Ведомое непрерывно записывает свое последнее обработанное событие binlog в datadir /relay-log.info, но этот файл использует буферизованные записи, поэтому он может потерять данные при сбое.

Именно поэтому Percona Server создал функцию crash-resistant replication для хранения одной и той же ведомой информации в таблице InnoDB для восстановления после этого сценария.

MySQL 5.6 реализовал similar feature: вы можете установить relay_log_info_repository=TABLE, чтобы ведомое устройство сохраняло свое состояние в аварийном режиме.

---

Re ваш комментарий:

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

Отъезд How to setup a slave for replication in 6 simple steps with Percona Xtrabackup.