我们有一个“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”的binlog格式,所以当我尝试使用mysqlbinlog来查看有问题的行时,我看不到任何有用的东西。我不想简单地设置跳过计数器,因为我认为这会使我的表更加不同步。
我能在奴隶身上做些什么,基本上会“回滚”到一个给定的时间点,然后我可以重置主日志号码,poition等等?如果没有,我可以做些什么来恢复同步?
答案 0 :(得分: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
,以便奴隶以防撞方式保存其状态。
重新评论:
是的,在理论中,pt-table-sync可以修复任意数量的从属漂移,但它不一定是纠正大差异的最有效方法。在某些时候,废弃过时的从站并使用主站的新备份重新初始化它会更快更有效。
查看How to setup a slave for replication in 6 simple steps with Percona Xtrabackup。