說明：本文所述內容都是是基於mysql 5.5.x及mairadb 10.0.x 版本

如果是mysql5.6 及其以上版本可使用：CHANGE MASTER TO MASTER_DELAY = N；N為多少秒，該語句設定從資料庫延時N秒後，再與主資料庫進行資料同步複製。具體介紹詳見 ：ＭySql 5.6 CHANGE MASTER語法 。

       為了資料庫安全，作為dba很多時候都絞盡腦汁進行各種控制權限，各種操作限制，但無論如何不管怎麼控制，如果是dba自己操作特別是drop table ,truncate，delete等難免會出現失誤的時候。也許你說你有備份，但是停機恢復不是什麼公司都能承受的而且恢復起來也很不方便。所以，這裡簡單介紹通過mysql“延遲複製”來為你資料庫實現平滑的邏輯恢復。

1，mysql5.5.x 版本如何實現“延遲複製“

這裡使用的是percona-toolkit-2.2.5-1 工具，如果你還不清楚它，請點選：percona-toolkits 介紹

用例：

/usr/bin/pt-slave-delay --user=${USER_NAME} --password=${PASS_WORD} --port=${PORT} --daemonize --interval=5m --delay=8h --use-master  123.111.222.110（備庫ip）

上述表示每個5分鐘檢查slave是否需要啟動或停止，slave設定比master延遲8小時，binlog點是以master為標準，指令碼以守護程序的方式在後臺執行

延遲效果如圖（1）：

                                                        圖 1

當指令碼檢查複製延遲操過了設定的時間那麼就會啟動sql執行緒進行追趕知道延遲8小時則停止。

注：因為指令碼每隔5分鐘才檢查一次複製情況所以實際延遲其實是8小時5分

追趕主庫期間效果如圖（2）

2，如何使用”延遲複製“進行恢復

a)，主庫操作如下（啟用自動提交模式）：

insert into t values(111);

insert into t values(222);

insert into t values(333);

start transaction;   --開啟一個事務   假如該事務是誤操作 ###

insert into t values(444);   

insert into t values(555);

commit;                --提交事務

insert into t values(666);

檢視binlog日誌：

b)，備庫操作如下

 start slave until master_log_file='mysql-bin.0000012' ,MASTER_LOG_POS = 872;  

告訴mysql複製執行到master binlog 0000012 中end_log_pos為872的位置然後停止

然後檢視：

MariaDB [test]> select * from t;
+------+
| id   |
+------+
|  111 |
|  222 |
|  333 |
+------+

發現按照預期的結果複製

現在需要跳過 444,555兩條記錄 故執行  stop slave ; set global sql_slave_skip_counter=1; start slave;

最後show slave status \G 

說明已經執行到了最後的一個end_log_pos 1294。最後查看錶裡的資料

MariaDB [test]> SELECT * FROM T;
+------+
| id   |
+------+
|  111 |
|  222 |
|  333 |
|  666 |
+------+

ok，成功跳過了記錄為444，555的插入操作。

PS:

關於這裡set global sql_slave_skip_counter=1;需要多解釋一下 很多小夥伴都會想當然的認為該語句是跳過一條語句，這裡其實是的分情況的: 一般來說（自動提交模式）每次執行一條插入或更新或刪除操作，那麼執行上述跳過語句你可以認為是一次跳過一條語句，但是如果是使用start transaction（非自動提交模式）那麼情況就不大一樣了,這個時候的跳過是按照事物進行跳躍的。

參考：