主從延遲復制數據恢復測試

2024-09-12 20:30:14

字體：大中小

來源：轉載

供稿：網友

　　寫在前面：

　　設想一下，你的線上環境使用了主從復制架構，如果不小心執行了，如：drop database db1、drop table tb1，或者說delete，update不加where條件的更新，當問題發生的時候，你是不是希望還有補救的機會？希望Slave主機不要重復Master主機的執行情況？可不可以將這個有害的SQL跳過后，繼續進行復制？答案是：可以的。主從延遲復制就是實現這個功能的

　　環境準備：

　　    搭建好主從架構（筆者采用的傳統的復制方式）

　　    設置好主從延遲變量（如：CHANGE MASTER TO master_delay=180）

　　    創建好測試表（在下面詳細說明）

　　如果執行了drop database db1或drop table tb1有害SQL：（drop database和drop table恢復方式相同，只是影響范圍不同而已）

　　測試表：
　　CREATE TABLE `edusoho_e`.`t1` (
　　 `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
　　 `xname` varchar(20) NOT NULL DEFAULT '',
　　 `address` char(20) NOT NULL DEFAULT '',
　　 `sex` tinyint(1) NOT NULL DEFAULT '1',
　　 `hobby` varchar(30) NOT NULL DEFAULT '',
　　 `age` tinyint(2) DEFAULT '18',
　　 PRIMARY KEY (`id`),
　　 KEY `idx_name` (`xname`)
　　) ENGINE=InnoDB DEFAULT CHARSET=utf8

　　CREATE TABLE `bbs`.`myhash_0` (
　　 `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
　　 `c1` int(10) NOT NULL DEFAULT '0',
　　 `c2` int(10) unsigned DEFAULT NULL,
　　 `c5` int(10) unsigned NOT NULL DEFAULT '0',
　　 `c3` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
　　 `c4` varchar(200) NOT NULL DEFAULT '',
　　 PRIMARY KEY (`id`),
　　 KEY `idx_c1` (`c1`),
　　 KEY `idx_c2` (`c2`)
　　) ENGINE=InnoDB DEFAULT CHARSET=utf8

　　Master主機在正常的變更數據：

　　INSERT INTO `edusoho_e`.`t1` (`xname`, `address`, `hobby`) VALUES ('lzb', '石家莊', 'MySQL');
　　INSERT INTO `edusoho_e`.`t1` (`xname`, `address`, `hobby`) VALUES ('Python', '北京', '游戲');
　　INSERT INTO `bbs`.`myhash_0`(c1,c2,c5,c3,c4) VALUES(2,3,4,NOW(),5);
　　UPDATE `bbs`.`myhash_0` SET id=2 WHERE id=5;

　　上面的正常數據變更還沒有執行完，此時Master上突然間執行了某個有害SQL：

　　DROP DATABASE `bbs`;

　　發現問題后，馬上停止Slave復制：

　　mysql> stop slave;

　　而此時Master主機上其他庫是正常的：

　　INSERT INTO `edusoho_e`.`t1` (`xname`, `address`, `hobby`) VALUES ('PHP', '深圳', '學習');

　　分析：

　　drop語句發生的時候，drop語句之前的數據可能還沒完全同步至Slave主機（這很有可能，尤其是你的數據量大的情況下），所以，需要分析Master主機的binlog，找到drop語句發生的position，使Slave主機同步至drop語句之前，然后跳過drop語句，使Slave繼續同步Master的其他數據

　　分析Master的binlog：

　　mysqlbinlog -v --base64-output=decode mysql-bin.000001 | grep -i -C 10 --color 'drop'
　　###   @3=2
　　###   @4=3
　　###   @5=1556612931
　　###   @6=''
　　# at 1053
　　#190430 16:28:51 server id 2 end_log_pos 1084 CRC32 0x7644c8d2     Xid = 2068
　　COMMIT/*!*/;
　　# at 1084
　　#190430 16:28:51 server id 2 end_log_pos 1180 CRC32 0x8fd4727e     Query   thread_id=11    exec_time=0 error_code=0
　　SET TIMESTAMP=1556612931/*!*/;
　　DROP DATABASE `bbs`
　　/*!*/;
　　# at 1180
　　#190430 16:28:52 server id 2 end_log_pos 1262 CRC32 0xcfe6ddb1     Query   thread_id=11    exec_time=0 error_code=0
　　SET TIMESTAMP=1556612932/*!*/;
　　BEGIN
　　/*!*/;
　　# at 1262
　　#190430 16:28:52 server id 2 end_log_pos 1323 CRC32 0x539e7626     Table_map: `edusoho_e`.`t1` mapped to number 312
　　# at 1323
　　#190430 16:28:52 server id 2 end_log_pos 1383 CRC32 0xd286a3c0     Write_rows: table id 312 flags: STMT_END_F

　　查看詳細的binlog信息：

　　mysql> show binlog events in 'mysql-bin.000001' from 1053 limit 10;

　　跳過有害SQL，繼續進行復制：

　　1、查看當前執行到的positon

　　mysql> show slave status/G;
　　Exec_Master_Log_Pos: 120

　　2、暫時將同步延遲關閉，使Slave立馬同步Master的數據

　　mysql> change master to master_delay=0;

　　3、同步數據至drop語句發生之前

　　mysql> start slave until master_log_file='mysql-bin.000001',master_log_pos=1084 user='repliter' password='123456';

　　4、再次查看執行到的position

　　mysql> show slave status/G;

　　Exec_Master_Log_Pos: 1084 （drop語句之前的數據已經同步過來了，去Slave相應的數據表驗證下，但是drop語句之后的數據還沒有同步過來）

　　現在跳過有害SQL之后，繼續Master的數據復制：

　　mysql> stop slave;

　　mysql> change master to master_log_pos=1262 [master_delay=180];（可加可不加）

　　mysql> start slave user='repliter' password='123456';

　　mysql> show slave status/G;
　　Exec_Master_Log_Pos: 1414

　　去驗證drop語句之后的數據過去了沒
　　就這樣有害SQL被跳過了，保留了一份Slave還未被刪除的數據備份，之后是做主從切換，還是把數據導回到Master就根據你自己的情況了

　　筆者這里演示下，將Slave的同名數據庫導回到Master的過程（如果數據量很大的話，建議做主從切換，因為導回的成本也許比切換的成本大的多，自行評估，個人建議）

　　1、首先，將Slave的庫導成SQL文件，這里為bbs_new.sql（一定要有包含創建庫的語句，要是忘記了，你就自己創建）

　　2、給導入SQL文件更改權限
　　chown mysql.mysql bbs_new.sql

　　3、mysql -uroot -p bbs -e "SET @@session.sql_log_bin=0;source /root/bbs_new.sql;"   （一定要加sql_log_bin=0，不然你懂得）

　　至此，drop database語句，成功跳過！

　　如果執行了delete from table（不加where條件）或truncate table有害SQL：

　　Master主機在正常的變更數據：

　　INSERT INTO `edusoho_e`.`t1` (`xname`, `address`, `hobby`,age) VALUES ('Games', '海南', '就是玩',28);
　　UPDATE `edusoho_e`.`t1` SET xname='劉備' WHERE id=5;

　　上面的正常數據變更還沒有執行完，此時Master上突然間執行了某個有害SQL：

　　DELETE FROM `edusoho_e`.`t1`;

　　因為是delete全表數據，表結構仍在，依據會有新數據產生和變更：

　　INSERT INTO `edusoho_e`.`t1` (`xname`, `address`, `hobby`) VALUES ('曹操', '魏國', '三國');
　　UPDATE `edusoho_e`.`t1` SET age=40 WHERE xname='曹操';
　　DELETE FROM `edusoho_e`.`t1` WHERE xname='lzb';   #刪除一條不存在的數據（不會產生日志）
　　UPDATE `edusoho_e`.`t1` SET xname='孫權' WHERE xname='Python';    #更新一條不存在的數據（不會產生日志）

　　發現問題后，馬上停止Slave復制：

　　mysql> stop slave;

　　分析：

　　此時，Master主機上其他數據庫、表也是不受影響的。delete全表語句發生的時候，delete全表語句之前的數據可能還沒完全同步至Slave主機（這很有可能，尤其是你的數據量大的情況下），所以，需要分析Master主機的binlog，找到delete全表語句發生的position，使Slave主機同步至delete全表語句之前，然后跳過delete全表語句，使Slave繼續同步Master的其他數據

　　在Master主機上根據時間分析binlog（因為筆者使用的是ROW格式，所以，會有很多條的delete語句，在delete全表語句之前，極有可能有正常的delete語句，你將分不清哪個才是該跳過的有害SQL，所以，問題發生的時候，一定要盡可能的知道發生的時間，對binlog進行分析才能更加有效）

　　mysqlbinlog -v --base64-output=decode mysql-bin.000001 | grep -i -C 10 --color 'delete from'（筆者自己測試，生產環境一定要加時間篩選）

　　COMMIT/*!*/;
　　# at 622
　　#190505 8:34:35 server id 2 end_log_pos 704 CRC32 0xd237cd1f Query thread_id=3 exec_time=0 error_code=0
　　SET TIMESTAMP=1557016475/*!*/;
　　BEGIN
　　/*!*/;
　　# at 704
　　#190505 8:34:35 server id 2 end_log_pos 765 CRC32 0x9335b52a Table_map: `edusoho_e`.`t1` mapped to number 281
　　# at 765
　　#190505 8:34:35 server id 2 end_log_pos 913 CRC32 0xb6da4487 Delete_rows: table id 281 flags: STMT_END_F
　　### DELETE FROM `edusoho_e`.`t1`
　　### WHERE
　　###   @1=1
　　###   @2='lzb'
　　###   @3='石家莊'
　　###   @4=1
　　###   @5='MySQL'
　　###   @6=18
　　### DELETE FROM `edusoho_e`.`t1`
　　### WHERE
　　###   @1=3
　　###   @2='Python'
　　###   @3='北京'
　　###   @4=1
　　###   @5='游戲'
　　###   @6=18
　　### DELETE FROM `edusoho_e`.`t1`
　　### WHERE
　　###   @1=5
　　###   @2='劉備'
　　###   @3='深圳'
　　###   @4=1
　　###   @5='學習'
　　###   @6=18
　　### DELETE FROM `edusoho_e`.`t1`
　　### WHERE
　　###   @1=7
　　###   @2='Games'
　　###   @3='海南'
　　###   @4=1
　　###   @5='就是玩'
　　###   @6=28
　　# at 913
　　#190505 8:34:35 server id 2 end_log_pos 944 CRC32 0x215741c7 Xid = 605
　　COMMIT/*!*/;

　　查看詳細的binlog信息：

　　mysql> show binlog events in 'mysql-bin.000001';（線上的binlog很大，一定要加from做篩選）
　　+------------------+------+-------------+-----------+-------------+---------------------------------------+
　　| Log_name         | Pos | Event_type | Server_id | End_log_pos | Info                                  |
　　+------------------+------+-------------+-----------+-------------+---------------------------------------+
　　| mysql-bin.000001 |    4 | Format_desc |         2 |         120 | Server ver: 5.6.16-log, Binlog ver: 4 |
　　| mysql-bin.000001 | 120 | Query       |         2 |         202 | BEGIN                                 |
　　| mysql-bin.000001 | 202 | Table_map   |         2 |         263 | table_id: 281 (edusoho_e.t1)          |
　　| mysql-bin.000001 | 263 | Write_rows |         2 |         328 | table_id: 281 flags: STMT_END_F       |
　　| mysql-bin.000001 | 328 | Xid         |         2 |         359 | COMMIT /* xid=587 */                  |
　　| mysql-bin.000001 | 359 | Query       |         2 |         441 | BEGIN                                 |
　　| mysql-bin.000001 | 441 | Table_map   |         2 |         502 | table_id: 281 (edusoho_e.t1)          |
　　| mysql-bin.000001 | 502 | Update_rows |         2 |         591 | table_id: 281 flags: STMT_END_F       |
　　| mysql-bin.000001 | 591 | Xid         |         2 |         622 | COMMIT /* xid=596 */                  |
　　| mysql-bin.000001 | 622 | Query       |         2 |         704 | BEGIN                                 |
　　| mysql-bin.000001 | 704 | Table_map   |         2 |         765 | table_id: 281 (edusoho_e.t1)          |
　　| mysql-bin.000001 | 765 | Delete_rows |         2 |         913 | table_id: 281 flags: STMT_END_F       |
　　| mysql-bin.000001 | 913 | Xid         |         2 |         944 | COMMIT /* xid=605 */                  |
　　| mysql-bin.000001 | 944 | Query       |         2 |        1026 | BEGIN                                 |
　　| mysql-bin.000001 | 1026 | Table_map   |         2 |        1087 | table_id: 281 (edusoho_e.t1)          |
　　| mysql-bin.000001 | 1087 | Write_rows |         2 |        1150 | table_id: 281 flags: STMT_END_F       |
　　| mysql-bin.000001 | 1150 | Xid         |         2 |        1181 | COMMIT /* xid=614 */                  |
　　| mysql-bin.000001 | 1181 | Query       |         2 |        1263 | BEGIN                                 |
　　| mysql-bin.000001 | 1263 | Table_map   |         2 |        1324 | table_id: 281 (edusoho_e.t1)          |
　　| mysql-bin.000001 | 1324 | Update_rows |         2 |        1416 | table_id: 281 flags: STMT_END_F       |
　　| mysql-bin.000001 | 1416 | Xid         |         2 |        1447 | COMMIT /* xid=623 */                  |
　　+------------------+------+-------------+-----------+-------------+---------------------------------------+

　　跳過有害SQL，繼續進行復制：

　　1、暫時將同步延遲關閉，使Slave立馬同步Master的數據

　　mysql> change master to master_delay=0;

　　2、同步數據至drop語句發生之前

　　mysql> start slave until master_log_file='mysql-bin.000001',master_log_pos=622 user='repliter' password='123456';

　　3、再次查看執行到的position

　　mysql> show slave status/G;

　　Exec_Master_Log_Pos: 622 （delete全表語句之前的數據已經同步過來了，去Slave相應的數據表驗證下，但是delete全表語句之后的數據還沒有同步過來）

　　現在跳過有害SQL之后，繼續Master的數據復制：

　　mysql> stop slave;

　　mysql> change master to master_log_pos=1026 [master_delay=180];（可加可不加）

　　mysql> start slave user='repliter' password='123456';

　　mysql> show slave status/G;
　　Exec_Master_Log_Pos: 1447

　　去驗證delete全表語句之后的數據過去了沒
　　就這樣有害SQL被跳過了，保留了一份Slave還未被刪除的數據備份，之后是做主從切換，還是把數據導回到Master就根據你自己的情況了

　　筆者這里演示下，將Slave的同名數據庫導回到Master的過程（如果數據量很大的話，建議做主從切換，因為導回的成本也許比切換的成本大的多）

　　如果你的數據表數據量較小，可以在上述until語句執行完之后，將Master的數據表加上全局寫鎖，然后將Slave主機上的數據同步過去，因為數據表小，對業務影響也不會太大

　　將Master主機上的數據表加上寫鎖：（如果你知道你的數據表pk值不會被插入，而是依靠自增生成，那么你可能需要先將表清空，導入舊數據后，再導入新數據，這樣才能保證數據的一致性）

　　LOCK TABLE `edusoho_e`.`t1` WRITE;

　　然后再Slave主機上把until語句之前的數據導出來：

　　INSERT INTO `t1` VALUES (1,'lzb','石家莊',1,'MySQL',18),(3,'Python','北京',1,'游戲',18),(5,'劉備','深圳',1,'學習',18),(7,'Games','海南',1,'就是玩',28);

　　切換到Master：

　　mysql> show master status/G;
　　*************************** 1. row ***************************
　　             File: mysql-bin.000001
　　         Position: 1447

　　SET @@session.sql_log_bin=0; （一定要做，具體原因應該都知道）

　　把數據導回去（如果是SQL文件，則執行source導入）

　　INSERT INTO `t1` VALUES (1,'lzb','石家莊',1,'MySQL',18),(3,'Python','北京',1,'游戲',18),(5,'劉備','深圳',1,'學習',18),(7,'Games','海南',1,'就是玩',28);

　　mysql> show master status/G;
　　*************************** 1. row ***************************
　　             File: mysql-bin.000001
　　         Position: 1447

　　釋放鎖：

　　UNLOCK TABLES;

　　至此，delete 全表語句，成功跳過！

　　如果執行了update table（不加限制條件）有害SQL：

　　測試表：
　　CREATE TABLE `orders` (
　　 `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
　　 `xname` varchar(10) NOT NULL DEFAULT '' COMMENT '用戶名稱',
　　 `chongzhi` int(11) NOT NULL DEFAULT '0' COMMENT '充值金額',
　　 `amount` int(11) NOT NULL DEFAULT '0' COMMENT '剩余金額',
　　 PRIMARY KEY (`id`)
　　) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='用戶訂單表'

　　正常的Master數據變更：
　　INSERT INTO `edusoho_e`.`orders`(xname,chongzhi,amount) VALUES('鄭千次',10000,100);
　　INSERT INTO `edusoho_e`.`orders`(xname,chongzhi,amount) VALUES('孫悟空',200,600);
　　INSERT INTO `edusoho_e`.`orders`(xname,chongzhi,amount) VALUES('柯南',666,888);
　　INSERT INTO `edusoho_e`.`orders`(xname,chongzhi,amount) VALUES('我',1,0);
　　UPDATE `edusoho_e`.`orders` SET chongzhi=chongzhi+1000 WHERE id=3;
　　UPDATE `edusoho_e`.`orders` SET amount=amount-200 WHERE id=5;
　　UPDATE `edusoho_e`.`orders` SET amount=amount-100;

　　此時，線上有一張用戶訂單表，執行了一條不加WHERE條件的UPDATE語句：

　　UPDATE `edusoho_e`.`orders` SET chongzhi=chongzhi+1000;

　　執行過后，用戶很高興，因為沒充錢，白得了1000塊；但是你的老板，絕對恨不得揍死你，為了不被揍，所以，你得趕緊恢復你的數據

　　發現問題后，馬上停止Slave復制：

　　mysql> stop slave;

　　分析：

　　發現問題之后，馬上對Master加寫鎖，因為此時數據雖然存在，但是已經是錯誤的數據；然后確定有害SQL的position，然后跳過它，繼續Master的復制

　　LOCK TABLE `edusoho_e`.`orders` WRITE;

　　在Master主機上根據時間分析binlog（因為筆者使用的是ROW格式，所以，會有很多條的update語句，如果在update不加限制條件語句之前，也有正常的update語句，你將分不清哪個才是該跳過的有害SQL，所以，問題發生的時候，一定要盡可能的知道發生的時間，對binlog進行分析才能更加有效）

　　分析Master日志，找到執行的問題SQL發生的position：
　　mysqlbinlog -v --base64-output=decode mysql-bin.000001 | grep -i -C 10 --color 'update'
　　COMMIT/*!*/;
　　# at 3554
　　#190505 10:04:20 server id 2 end_log_pos 3636 CRC32 0xd95ad4e9   Query thread_id=3 exec_time=0 error_code=0
　　SET TIMESTAMP=1557021860/*!*/;
　　BEGIN
　　/*!*/;
　　# at 3636
　　#190505 10:04:20 server id 2 end_log_pos 3695 CRC32 0xa8208a81   Table_map: `edusoho_e`.`orders` mapped to number 282
　　# at 3695
　　#190505 10:04:20 server id 2 end_log_pos 3897 CRC32 0xdb6fe2c1   Update_rows: table id 282 flags: STMT_END_F
　　### UPDATE `edusoho_e`.`orders`
　　### WHERE
　　###   @1=1
　　###   @2='鄭千次'
　　###   @3=10000
　　###   @4=100
　　### SET
　　###   @1=1
　　###   @2='鄭千次'
　　###   @3=11000
　　###   @4=100
　　### UPDATE `edusoho_e`.`orders`
　　### WHERE
　　###   @1=3
　　###   @2='孫悟空'
　　###   @3=1200
　　###   @4=600
　　### SET
　　###   @1=3
　　###   @2='孫悟空'
　　###   @3=2200
　　###   @4=600
　　### UPDATE `edusoho_e`.`orders`
　　### WHERE
　　###   @1=5
　　###   @2='柯南'
　　###   @3=666
　　###   @4=688
　　### SET
　　###   @1=5
　　###   @2='柯南'
　　###   @3=1666
　　###   @4=688
　　### UPDATE `edusoho_e`.`orders`
　　### WHERE
　　###   @1=7
　　###   @2='我'
　　###   @3=1
　　###   @4=0
　　### SET
　　###   @1=7
　　###   @2='我'
　　###   @3=1001
　　###   @4=0

　　mysql> show binlog events in 'mysql-bin.000001' from 3554;
　　+------------------+------+-------------+-----------+-------------+----------------------------------+
　　| 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 參數特性，進行數據恢復做的測試，并沒有經過任何的實戰檢測。一方面，僅為廣大同行做個參考；另一方面，記錄筆者自己的心得和針對問題解決的思路做個總結，當問題真正發生的時候，有個方向可以進行參考，而不至于手忙腳亂，不知所措，所以，對其中有誤之處和理解不到位的地方，望請下方留言指正，不勝感激！

（編輯：武林網）

上一篇：MGR客戶端failover方式

下一篇：Mydumper安裝報錯處理