|
--+----------------------------------+
| Log_name???????? | Pos? | Event_type? | Server_id | End_log_pos | Info???????????????????????????? |
+------------------+------+-------------+-----------+-------------+----------------------------------+
| mysql-bin.000001 | 3554 | Query?????? |???????? 2 |??????? 3636 | BEGIN??????????????????????????? |
| mysql-bin.000001 | 3636 | Table_map?? |???????? 2 |??????? 3695 | table_id: 282 (edusoho_e.orders) |
| mysql-bin.000001 | 3695 | Update_rows |???????? 2 |??????? 3897 | table_id: 282 flags: STMT_END_F? |
| mysql-bin.000001 | 3897 | Xid???????? |???????? 2 |??????? 3928 | COMMIT /* xid=893 */???????????? |
+------------------+------+-------------+-----------+-------------+----------------------------------+
4 rows in set (0.00 sec)
跳过有害SQL，继续进行复制：
1、和问题发生人员沟通，确认update是怎样执行的
在Master上执行：
SET @@session.sql_log_bin=0;（一定要加，不然你懂得）
UPDATE `edusoho_e`.`orders` SET chongzhi=chongzhi-1000;
此时，Master和SLave的数据都恢复了一致，只要Slave跳过有害的UPDATE语句就可以了
2、跳过有害SQL，继续复制
mysql> change master to master_log_pos=3928 [master_delay=180];（可加可不加）
3、start slave user='repliter' password='123456';
4、释放表的写锁
UNLOCK TABLES;
至此，update全表语句，成功跳过！
题外：
本文是笔者根据自己的理解，设想线上可能发生的部分问题后，针对性的利用 master_delay 参数特性，进行数据恢复做的测试，并没有经过任何的实战检测。一方面，仅为广大同行做个参考；另一方面，记录笔者自己的心得和针对问题解决的思路做个总结，当问题真正发生的时候，有个方向可以进行参考，而不至于手忙脚乱，不知所措，所以，对其中有误之处和理解不到位的地方，望请下方留言指正，不胜感激！
|