MySQL relay log поврежден, как это исправить? Попробовал но не получилось

Реле MySQL v5.1.61 было повреждено, когда машина внезапно выключилась. Я пытался это исправить, но это не сработало.
- Как мне это исправить? Я сделал что-то неправильно?

Насколько я прочитал, поврежденные журналы ретрансляции MySQL легко исправить:

change master to master_log_file='<Relay_Master_Log_File>',
                 master_log_pos=<Exec_Master_Log_Pos>;

где Relay_Master_Log_Fileи Exec_Master_Log_Posперечислены:
mysql> show slave status;

Однако, когда я сделал change master status ..., я получил ошибку нарушения первичного ключа. Как это возможно? Вышеописанная процедура неправильна или, например, отсутствует +1?

_{(На данный момент я просто повторно импортировал --master-data mysqldump из ведущего устройства в ведомое устройство, и это решило проблему. Однако в будущем это может быть неуместно.)}

Вот подробности о моей конкретной проблеме:

mysql> show slave status \G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: the-master-host
                  Master_User: replication
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000021
          Read_Master_Log_Pos: 33639968
               Relay_Log_File: mysql-relay-bin.000271
                Relay_Log_Pos: 2031587
        Relay_Master_Log_File: mysql-bin.000020
             Slave_IO_Running: Yes
            Slave_SQL_Running: No
              Replicate_Do_DB: the_database
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 1594
                   Last_Error: Relay log read failure: Could not parse relay log event entry. The possible reasons are: the master's binary log is corrupted (you can check this by running 'mysqlbinlog' on the binary log), the slave's relay log is corrupted (you can check this by running 'mysqlbinlog' on the relay log), a network problem, or a bug in the master's or slave's MySQL code. If you want to check the master's binary log or slave's relay log, you will be able to know their names by issuing 'SHOW SLAVE STATUS' on this slave.
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 66395191
              Relay_Log_Space: 36559177
              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: 1594
               Last_SQL_Error: Relay log read failure: Could not parse relay log event entry. The possible reasons are: the master's binary log is corrupted (you can check this by running 'mysqlbinlog' on the binary log), the slave's relay log is corrupted (you can check this by running 'mysqlbinlog' on the relay log), a network problem, or a bug in the master's or slave's MySQL code. If you want to check the master's binary log or slave's relay log, you will be able to know their names by issuing 'SHOW SLAVE STATUS' on this slave.

И вот что я сделал:

mysql> stop slave;
mysql> reset slave;
mysql> change master to master_host='the-master-host', master_user='replication', master_password='the-password', master_log_file='mysql-bin.000020', master_log_pos=66395191;
mysql> start slave;

И вот что произошло, ошибка ПК:

131122 15:17:29 [Note] Slave I/O thread: connected to master 'replication@the-master-host:3306',replication started in log 'mysql-bin.000020' at position 66395191
131122 15:17:29 [ERROR] Slave SQL: Error 'Duplicate entry '71373' for key 'PRIMARY'' on query. Default database: 'the_database'. Query: 'insert into ...  values ...', Error_code: 1062
131122 15:17:29 [Warning] Slave: Data truncated for column 'date' at row 1 Error_code: 1265
131122 15:17:29 [Warning] Slave: Duplicate entry '71373' for key 'PRIMARY' Error_code: 1062

Я думаю, что я следовал рекомендованной процедуре (см. Ссылки чуть ниже), тем не менее, произошла ошибка PK :-(? Http://bugs.mysql.com/bug.php?id=26489 , поиск «Обходные пути». Http: //mhbarr.wordpress.com/2013/07/26/mysql-slave-corrupted-relay-log/ /programming//a/14438408

Ошибка: Last_SQL_Errno: 1594 Last_SQL_Error: Ошибка чтения журнала ретрансляции: не удалось проанализировать запись события журнала ретрансляции.

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

• Прежде чем что-либо делать, сделайте резервную копию всех ваших баз данных, журналов, серверов изображений, повторите несколько раз и продолжайте только на свой страх и риск.

Сначала запустите «показать статус ведомого \ G» на ведомом устройстве и обратите внимание:

Master_Log_File: mysql-bin.000026
Read_Master_Log_Pos: 2377104
Relay_Log_File: mysqld-relay-bin.000056
Relay_Log_Pos: 1097303
Relay_Master_Log_File: mysql-bin.000026
Exec_Master_Log_Pos: 1097157

Сначала мы хотим убедиться, что главный файл журнала не поврежден, поэтому перейдите на главный сервер и найдите Relay_Master_Log_File (check / var / log / mysql) и выполните следующую команду:

mysqlbinlog mysql-bin.000026

Журнал будет отображаться, но, надеюсь, вы не увидите сообщений об ошибках. Если вы видите сообщения об ошибках, то главные журналы повреждены, и вам, вероятно, придется заново создать образ.

Затем выполните ту же команду в журнале ведомого реле (часто в / var / lib / mysql)

mysqlbinlog mysqld-relay-bin.000056

Вероятно, вы увидите некоторые ошибки, показывающие повреждение, остановившее репликацию, например:

ERROR: Error in Log_event::read_log_event(): 'read error', data_len: 336, event_type: 2
ERROR: Could not read entry at offset 1097414: Error in log format or read error.
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;
root@db:/var/lib/mysql#

Если вы видите какие-либо ошибки, то на главном журнале все в порядке, а поврежден только журнал реле ведомого. Это хорошая новость, мы можем сбросить настройки раба и сообщить ему подробности мастеров и продолжить работу. Если вы не видите ошибок, прекратите чтение сейчас, у вас другая проблема.

Если в журнале ведомого реле есть ошибки, выполните следующие команды, чтобы сбросить ведомые и поврежденные журналы, повторно подключиться к главному устройству, получить журналы ok и снова начать подчинение. Обратите внимание, что MASTER_LOG_POS - это Exec_Master_Log_Pos, а MASTER_LOG_FILE - это Relay_Master_Log_File( НЕ первый, который соответствует журналам ретрансляции, которые были извлечены и должны быть выброшены) как из первой команды.

mysql> stop slave;
Query OK, 0 rows affected (0.14 sec)

mysql> reset slave all;
Query OK, 0 rows affected (0.43 sec)

mysql>  CHANGE MASTER TO MASTER_HOST='master.host.com', MASTER_USER='masteruser', MASTER_PASSWORD='masterpass', MASTER_LOG_FILE='mysql-bin.000026', MASTER_LOG_POS=1097157;
Query OK, 0 rows affected (0.93 sec)

mysql> start slave;
Query OK, 0 rows affected (0.00 sec)

[Исправление репликации MySQL после того, как журнал реле ведомых был поврежден]

Репликация MySQL на подчиненном (версия 5.XX) остановлена. Slave_IO_Running был помечен как Да, но Slave_SQL_Running как Нет. Простой останов / запуск ведомого не помог, поэтому потребовался дальнейший анализ проблемы. Казалось, что релейный журнал текущего ведомого был поврежден, потому что тестирование с «mysqlbinlog» распечатало ошибку. Таким образом, решение состояло в том, чтобы отбросить текущие блоки журналов реле и указать подчиненное устройство на последнюю позицию главного блока журналов.

Чтобы исправить ошибку, текущие файлы binlog на ведомом устройстве следует отбросить и установить новую позицию. Перед установкой новой позиции binlog важно запомнить значения Relay_Master_Log_File и Exec_Master_Log_Pos с поврежденного подчиненного сервера с помощью команды SHOW SLAVE STATUS \ G :

Relay_Master_Log_File: mysql-bin.002045
Exec_Master_Log_Pos: 103641119

Хорошо, с этими значениями, новая позиция binlog может быть установлена:

# stop slave
mysql> stop slave;

# make slave forget its replication position in the master's binary log
mysql> reset slave;

# change slave to start reading from stopped position
mysql> change master to master_log_file='mysql-bin.002045', master_log_pos=103641119;

# start slave
mysql> start slave;

Просто отметим , что reset slaveприведет к удалению master.info, relay-log.infoи все файлы журнала реле, так что это не нужно , чтобы очистить остатки в /var/lib/mysqlкаталоге.

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

mysql> stop slave;
mysql> reset slave;
mysql> change master to master_host='the-master-host', master_user='replication', master_password='the-password', master_log_file='mysql-bin.000020', master_log_pos=66395191;
mysql> start slave;

Похоже, это должно было исправить это, потому что он удалил поврежденный журнал ретрансляции.

Затем вы получили ошибку PK 1062. Почему?

Существует выдающаяся ошибка ( http://bugs.mysql.com/bug.php?id=60847 ), которая все еще активна в MySQL 5.5

Хотя ошибка связана с использованием mysql --single-транзакции --flush-logs, существует и связанная с этим особенность.

Я видел эту причуду на некоторых серверах EC2, работающих как ведомые для клиента только на прошлой неделе в MySQL 5.5.15

На Master была странная многострочная расширенная INSERT, где каждый вставляемый кортеж был SELECT. Произошло то, что LAST_INSERT_ID в журнале ретрансляции, который формирует следующее автоматическое приращение для назначения, уже использовался на ведомом устройстве из-за многострочных вставок заранее.

Сериализованная вставка в релейном журнале выглядела как

INSERT INTO tablname (column,column) VALUES (value,value,...)

Список столбцов не включает числовой первичный ключ. Когда возвращается ошибка 1062, я использую тот же запрос, на котором она не выполнена, запускаю запрос вручную. Это не ударил 1062 ошибки. Затем я выполнил обычные команды пропустить подчиненный:

STOP SLAVE;
SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1;
START SLAVE;
SET @sleepnumber = SLEEP(3);
SHOW SLAVE STATUS\G

Затем репликация настигла.

Я бы посоветовал вам правильно сериализовать ваши INSERT на Master, потому что подобной ошибочной ситуации на самом деле вполне можно избежать.

Вы сделали это совершенно правильно (как уже говорили другие).

Единственная проблема связана с файлом master.info (содержит информацию о позиции в mysql-bin.log мастера), поскольку этот файл не синхронизируется с диском после обработки каждого запроса.

Таким образом, ваша информация о позициях в основном журнале устарела, и вы обрабатываете уже обработанные запросы, которые необходимо пропустить SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1;.

К сожалению, если вы используете такие запросы, как UPDATE table SET counter=counter+1 WHERE id = 12345и binlog_format=STATEMENTваши базы данных могут быть не синхронизированы, я думаю.

Вы можете указать серверу MySQL синхронизировать master.info после каждого события, установив переменную sync_master_info, но это, вероятно, будет иметь огромные последствия для производительности.