共計(jì) 2595 個(gè)字符，預(yù)計(jì)需要花費(fèi) 7 分鐘才能閱讀完成。
這篇文章將為大家詳細(xì)講解有關(guān) MySQL 中怎么實(shí)現(xiàn)異步復(fù)制，文章內(nèi)容質(zhì)量較高，因此丸趣 TV 小編分享給大家做個(gè)參考，希望大家閱讀完這篇文章后對相關(guān)知識有一定的了解。
一、MYSQL 復(fù)制架構(gòu)衍生史
在 2000 年，MySQL 3.23.15 版本引入了 Replication。Replication 作為一種準(zhǔn)實(shí)時(shí)同步方式，得到廣泛應(yīng)用。這個(gè)時(shí)候的 Replicaton 的實(shí)現(xiàn)涉及到兩個(gè)線程，一個(gè)在 Master，一個(gè)在 Slave。Slave 的 I / O 和 SQL 功能是作為一個(gè)線程，從 Master 獲取到 event 后直接 apply，沒有 relay log。這種方式使得讀取 event 的速度會(huì)被 Slave replay 速度拖慢，當(dāng)主備存在較大延遲時(shí)候，會(huì)導(dǎo)致大量 binary log 沒有備份到 Slave 端。
在 2002 年，MySQL 4.0.2 版本將 Slave 端 event 讀取和執(zhí)行獨(dú)立成兩個(gè)線程(IO 線程和 SQL 線程)，同時(shí)引入了 relay log。IO 線程讀取 event 后寫入 relay log，SQL 線程從 relay log 中讀取 event 然后執(zhí)行。這樣即使 SQL 線程執(zhí)行慢，Master 的 binary log 也會(huì)盡可能的同步到 Slave。當(dāng) Master 宕機(jī)，切換到 Slave，不會(huì)出現(xiàn)大量數(shù)據(jù)丟失。
在 2010 年 MySQL 5.5 版本之前，一直采用的是這種異步復(fù)制的方式。主庫的事務(wù)執(zhí)行不會(huì)管備庫的同步進(jìn)度，如果備庫落后，主庫不幸 crash，那么就會(huì)導(dǎo)致數(shù)據(jù)丟失。于是在 MySQL 在 5.5 中就順其自然地引入了半同步復(fù)制，主庫在應(yīng)答客戶端提交的事務(wù)前需要保證至少一個(gè)從庫接收并寫到 relay log 中。
在 2016 年，MySQL 在 5.7.17 中引入了一個(gè)全新的技術(shù)，稱之為 InnoDB Group Replication。目前官方 MySQL 5.7.17 基于 Group replication 的全同步技術(shù)已經(jīng)問世，全同步技術(shù)帶來了更多的數(shù)據(jù)一致性保障。
下圖對應(yīng) MySQL 幾種復(fù)制類型，分別是異步、半同步、全同步
二、異步復(fù)制(Asynchronous replication)
1. 邏輯上
MySQL 默認(rèn)的復(fù)制即是異步的，主庫在執(zhí)行完客戶端提交的事務(wù)后會(huì)立即將結(jié)果返給給客戶端，并不關(guān)心從庫是否已經(jīng)接收并處理，這樣就會(huì)有一個(gè)問題，主如果 crash 掉了，此時(shí)主上已經(jīng)提交的事務(wù)可能并沒有傳到從庫上，如果此時(shí)，強(qiáng)行將從提升為主，可能導(dǎo)致新主上的數(shù)據(jù)不完整。
2. 技術(shù)上
主庫將事務(wù) Binlog 事件寫入到 Binlog 文件中，此時(shí)主庫只會(huì)通知一下 Dump 線程發(fā)送這些新的 Binlog，然后主庫就會(huì)繼續(xù)處理提交操作，而此時(shí)不會(huì)保證這些 Binlog 傳到任何一個(gè)從庫節(jié)點(diǎn)上。
3. 原理圖
(1) 在 Slave 服務(wù)器上執(zhí)行 sart slave 命令開啟主從復(fù)制開關(guān)，開始進(jìn)行主從復(fù)制。
(2) 此時(shí)，Slave 服務(wù)器的 IO 線程會(huì)通過在 master 上已經(jīng)授權(quán)的復(fù)制用戶權(quán)限請求連接 master 服務(wù)器，并請求從執(zhí)行 binlog 日志文件的指定位置 (日志文件名和位置就是在配置主從復(fù)制服務(wù)時(shí)執(zhí)行 change master 命令指定的) 之后開始發(fā)送 binlog 日志內(nèi)容
(3) Master 服務(wù)器接收到來自 Slave 服務(wù)器的 IO 線程的請求后，其上負(fù)責(zé)復(fù)制的 IO 線程會(huì)根據(jù) Slave 服務(wù)器的 IO 線程請求的信息分批讀取指定 binlog 日志文件指定位置之后的 binlog 日志信息，然后返回給 Slave 端的 IO 線程。返回的信息中除了 binlog 日志內(nèi)容外，還有在 Master 服務(wù)器端記錄的 IO 線程。返回的信息中除了 binlog 中的下一個(gè)指定更新位置。
(4) 當(dāng) Slave 服務(wù)器的 IO 線程獲取到 Master 服務(wù)器上 IO 線程發(fā)送的日志內(nèi)容、日志文件及位置點(diǎn)后，會(huì)將 binlog 日志內(nèi)容依次寫到 Slave 端自身的 Relay Log(即中繼日志)文件 (Mysql-relay-bin.xxx) 的最末端，并將新的 binlog 文件名和位置記錄到 master-info 文件中，以便下一次讀取 master 端新 binlog 日志時(shí)能告訴 Master 服務(wù)器從新 binlog 日志的指定文件及位置開始讀取新的 binlog 日志內(nèi)容
(5) Slave 服務(wù)器端的 SQL 線程會(huì)實(shí)時(shí)檢測本地 Relay Log 中 IO 線程新增的日志內(nèi)容，然后及時(shí)把 Relay LOG 文件中的內(nèi)容解析成 sql 語句，并在自身 Slave 服務(wù)器上按解析 SQL 語句的位置順序執(zhí)行應(yīng)用這樣 sql 語句，并在 relay-log.info 中記錄當(dāng)前應(yīng)用中繼日志的文件名和位置點(diǎn)
三、全同步復(fù)制(Fully synchronous replication)
1. 邏輯上
指當(dāng)主庫執(zhí)行完一個(gè)事務(wù)，所有的從庫都執(zhí)行了該事務(wù)才返回給客戶端。因?yàn)樾枰却袕膸靾?zhí)行完該事務(wù)才能返回，所以全同步復(fù)制的性能必然會(huì)收到嚴(yán)重的影響。
2. 技術(shù)上
當(dāng)主庫提交事務(wù)之后，所有的從庫節(jié)點(diǎn)必須收到、APPLY 并且提交這些事務(wù)，然后主庫線程才能繼續(xù)做后續(xù)操作。但缺點(diǎn)是，主庫完成一個(gè)事務(wù)的時(shí)間會(huì)被拉長，性能降低。
3. 原理圖
四、半同步復(fù)制(Semisynchronous replication)
1. 邏輯上
是介于全同步復(fù)制與全異步復(fù)制之間的一種，主庫只需要等待至少一個(gè)從庫節(jié)點(diǎn)收到并且 Flush Binlog 到 Relay Log 文件即可，主庫不需要等待所有從庫給主庫反饋。同時(shí)，這里只是一個(gè)收到的反饋，而不是已經(jīng)完全完成并且提交的反饋，如此，節(jié)省了很多時(shí)間。
2. 技術(shù)上
介于異步復(fù)制和全同步復(fù)制之間，主庫在執(zhí)行完客戶端提交的事務(wù)后不是立刻返回給客戶端，而是等待至少一個(gè)從庫接收到并寫到 relay log 中才返回給客戶端。相對于異步復(fù)制，半同步復(fù)制提高了數(shù)據(jù)的安全性，同時(shí)它也造成了一定程度的延遲，這個(gè)延遲最少是一個(gè) TCP/IP 往返的時(shí)間。所以，半同步復(fù)制最好在低延時(shí)的網(wǎng)絡(luò)中使用。
3. 原理圖
master 將每個(gè)事務(wù)寫入 binlog(sync_binlog=1)，傳遞到 slave 刷新到磁盤(sync_relay=1)，同時(shí)主庫提交事務(wù)(commit)。master 等待 slave 反饋收到 relay log，只有收到 ACK 后 master 才將 commit OK 結(jié)果反饋給客戶端。
關(guān)于 MySQL 中怎么實(shí)現(xiàn)異步復(fù)制就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學(xué)到更多知識。如果覺得文章不錯(cuò)，可以把它分享出去讓更多的人看到。
