前言

MySQL的主從復(fù)制(replication)關(guān)系，不太嚴(yán)謹(jǐn)?shù)慕蟹ㄊ恰巴健被蛘摺爸鲝耐健薄?shí)際上在早期，MySQL的主從并不能實(shí)現(xiàn)真正的“同步”(sync)，而是“異步”的(async)。

MySQL主從復(fù)制它可以有多種模式，最經(jīng)典的也是最早出現(xiàn)的異步復(fù)制(async replication)，從5.5版本開始有了半同步復(fù)制(semi-sync replication)，到了5.7又有了增強(qiáng)半同步。本文要討論的延遲從庫(kù)，也是在5.6之后才有的功能，在這之前需要用percona pt-slave-delay 工具來(lái)變相實(shí)現(xiàn)。

另外，從5.6版本開始增加了并行復(fù)制，不過(guò)這時(shí)還是基于schema的并行模式（slave-parallel-type=DATABASE），效率非常差，意義不大。到了5.7，才實(shí)現(xiàn)了真正的并行復(fù)制（slave-parallel-type=LOGICAL_CLOCK），復(fù)制效率提升很多；還有新增了多源復(fù)制，很方便的就能實(shí)現(xiàn)多主一從的架構(gòu)。

了解完MySQL復(fù)制的簡(jiǎn)史，我們切入主題。

MySQL延遲從庫(kù)的好處主要有幾點(diǎn)：

1、誤刪除時(shí)，能更快恢復(fù)數(shù)據(jù)。

有時(shí)候手抖了，把線上數(shù)據(jù)給誤刪除了，或者誤刪除庫(kù)、表、其他對(duì)象，或不加WHERE條件的更新、刪除，都可以讓延遲從庫(kù)在誤操作前的時(shí)間點(diǎn)停下，然后進(jìn)行恢復(fù)。

2、把延遲從庫(kù)作為專用的備份節(jié)點(diǎn)。雖然有一定的延遲，但并不影響利用該節(jié)點(diǎn)作為備份角色，也不影響生產(chǎn)節(jié)點(diǎn)數(shù)據(jù)庫(kù)庫(kù)。

3、還可以把延遲從庫(kù)當(dāng)做一些問(wèn)題、案例研究的對(duì)象。個(gè)別時(shí)候，可能有些binlog event在普通從庫(kù)上會(huì)有問(wèn)題（例如早期版本中無(wú)主鍵會(huì)導(dǎo)致從庫(kù)更新非常慢的經(jīng)典問(wèn)題），這時(shí)就有時(shí)間在延遲從庫(kù)上慢慢琢磨研究了。

啟用延遲從庫(kù)的方法也挺簡(jiǎn)單的，下面是在MySQL 8.0的做法：

#直接用 CHANGE MASTER TO 設(shè)置，后面的N單位是秒數(shù)
CHANGE MASTER TO MASTER_DELAY = N

當(dāng)發(fā)生誤操作需要讓延遲從庫(kù)在某個(gè)位置上停下來(lái)時(shí)，用下面的命令：

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上多個(gè)并行線程之前沒有延遲差距了就停下
#因?yàn)槎嗑€程復(fù)制，不同線程的復(fù)制進(jìn)度不一樣，因此有差距
| SQL_AFTER_MTS_GAPS }

P.S，從5.7起，修改 MASTER_DELAY 選項(xiàng)可以在線立即生效，而無(wú)需重啟 slave 線程。

至于具體 MASTER_DELAY 設(shè)置多少合適，要估算如果發(fā)生誤操作時(shí)，DBA平均能到現(xiàn)場(chǎng)的時(shí)間，一般建議1小時(shí)左右。

總結(jié)

以上就是這篇文章的全部?jī)?nèi)容了，希望本文的內(nèi)容對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，謝謝大家對(duì)腳本之家的支持。