前言

MySQL的主從複製(replication)關係，不太嚴謹的叫法是“同步”或者“主從同步”。實際上在早期，MySQL的主從並不能實現真正的“同步”(sync)，而是“非同步”的(async)。

MySQL主從複製它可以有多種模式，最經典的也是最早出現的非同步複製(async replication)，從5.5版本開始有了半同步複製(semi-sync replication)，到了5.7又有了增強半同步。本文要討論的延遲從庫，也是在5.6之後才有的功能，在這之前需要用percona pt-slave-delay 工具來變相實現。

另外，從5.6版本開始增加了並行複製，不過這時還是基於schema的並行模式（slave-parallel-type=DATABASE），效率非常差，意義不大。到了5.7，才實現了真正的並行複製（slave-parallel-type=LOGICAL_CLOCK），複製效率提升很多；還有新增了多源複製，很方便的就能實現多主一從的架構。

瞭解完MySQL複製的簡史，我們切入主題。

MySQL延遲從庫的好處主要有幾點：

1、誤刪除時，能更快恢復資料。

有時候手抖了，把線上資料給誤刪除了，或者誤刪除庫、表、其他物件，或不加WHERE條件的更新、刪除，都可以讓延遲從庫在誤操作前的時間點停下，然後進行恢復。

2、把延遲從庫作為專用的備份節點。雖然有一定的延遲，但並不影響利用該節點作為備份角色，也不影響生產節點資料庫庫。

3、還可以把延遲從庫當做一些問題、案例研究的物件。個別時候，可能有些binlog event在普通從庫上會有問題（例如早期版本中無主鍵會導致從庫更新非常慢的經典問題），這時就有時間在延遲從庫上慢慢琢磨研究了。

啟用延遲從庫的方法也挺簡單的，下面是在MySQL 8.0的做法：

#直接用 CHANGE MASTER TO 設定，後面的N單位是秒數
CHANGE MASTER TO MASTER_DELAY = N

當發生誤操作需要讓延遲從庫在某個位置上停下來時，用下面的命令：

START SLAVE
UNTIL {
#1、直到指定的GTID位置停下
{SQL_BEFORE_GTIDS | SQL_AFTER_GTIDS} = gtid_set

#2、直到指定的binlog位置停下
| MASTER_LOG_FILE = ‘log_name',MASTER_LOG_POS = log_pos

#3、直到指定的relay log位置停下
| RELAY_LOG_FILE = ‘log_name',RELAY_LOG_POS = log_pos

#4、直到slave上多個並行執行緒之前沒有延遲差距了就停下
#因為多執行緒複製，不同執行緒的複製進度不一樣，因此有差距
| SQL_AFTER_MTS_GAPS }

P.S，從5.7起，修改 MASTER_DELAY 選項可以線上立即生效，而無需重啟 slave 執行緒。

至於具體 MASTER_DELAY 設定多少合適，要估算如果發生誤操作時，DBA平均能到現場的時間，一般建議1小時左右。

總結

以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值，謝謝大家對我們的支援。