本文將回顧MySQL復(fù)制概念和MySQL幾種復(fù)制方案，同時也會澄清一些關(guān)于復(fù)制問題的誤解。
MySQL復(fù)制是什么?
復(fù)制能夠保護(hù)信息得到備份，并且備份會不同于原數(shù)據(jù)，備份會被保存到另一個環(huán)境。即主備數(shù)據(jù)不在同一臺服務(wù)器。下圖是MySQL復(fù)制示意圖：
MySQL有 哪 些復(fù)制方案?
復(fù)制如此重要，那么在MySQL中我們有哪些選擇呢？
1. 異步復(fù)制
異步復(fù)制意味著本地環(huán)境操作完成，事務(wù)就完成 ，不會受到slave復(fù)制是否完成的影響。
當(dāng)改變被提交后，master就會把數(shù)據(jù)修改信息放到binlog中（也可能把實際的statement放到binlog中，這是row-based復(fù)制和statement-based復(fù)制的不同，后面會講到）。dump線程讀取binlog日志然后將其發(fā)送到slave，slave接受并保存到待處理隊列中（被稱為relay-log），slave會執(zhí)行每一個在master上的改變：
2. 半同步復(fù)制
半同步復(fù)制（Semi-synchronous replication）意味著master和slave彼此通訊確保事務(wù)的正確轉(zhuǎn)移。 當(dāng)改變發(fā)生時，master需要等待slave已經(jīng)將日志保存到relay-log中并向master回復(fù)確認(rèn)master才能提交事務(wù) 。 半同步復(fù)制可以保證事務(wù)被正確的復(fù)制，但不能保證在slave上一定發(fā)生：
需要注意的是，半同步復(fù)制的話，master需要等待至少有一個slave服務(wù)器確認(rèn)接收到事務(wù)并保存了relay-log（或達(dá)到超時）才能繼續(xù)處理同一個SESSION中的當(dāng)前事務(wù)，至于具體多少個slave確認(rèn)，可以通過參數(shù)rpl_semi_sync_master_wait_slave_count進(jìn)行配置，這個值有效范圍是1～1024之間，而且這個值可以動態(tài)更新。舉個栗子：
假設(shè)rpl_semi_sync_master_wait_slave_count被設(shè)置為2，并且有兩個slave，分別是： slave1和slave2。
1. T1等待兩個slave的ack；
2. master收到slave1的ack；
3. 此時加入一個slave3，并將rpl_semi_sync_master_wait_slave_count改為3；
4. master收到 sl av e2的ack ；
5. master收到 sl av e3的ack；
6. master喚醒等待中的事務(wù)，并準(zhǔn)備提交；
記住半同步復(fù)制會影響性能，因為它需要等待來自slave的確認(rèn)（ack）。但是，它也能減少slave上由于故障導(dǎo)致數(shù)據(jù)丟失的風(fēng)險。
3. 組復(fù)制
組（Group）復(fù)制是MySQL5.7版本新介紹的概念，在5.7.17發(fā)布了GA，而且以插件模式提供。
任意一個數(shù)據(jù)庫節(jié)點(diǎn)無論什么時候執(zhí)行一個事務(wù)，組復(fù)制插件在向客戶端響應(yīng)它已經(jīng)完成事務(wù)前，會嘗試得到其他數(shù)據(jù)庫節(jié)點(diǎn)的同意。組復(fù)制示意圖如下：
4. Percona XtraDB Cluster / Galera Cluster
再介紹一個把master數(shù)據(jù)復(fù)制到其他節(jié)點(diǎn)的解決方案，就是Percona XtraDB Cluster，簡稱PXC。這個解決方案把重心放在一致性上，并且通過使用一個認(rèn)證過程來保證事務(wù)避免沖突和執(zhí)行的正確性。在這個集群方案的數(shù)據(jù)庫環(huán)境下， 每個節(jié)點(diǎn)的數(shù)據(jù)都是相同的，節(jié)點(diǎn)之間會依賴galera提供的廣播機(jī)制來保證一致性 。
以一條SQL為例，某節(jié)點(diǎn)接收SQL請求后，在commit之前，由wsrep API 調(diào)用galera庫進(jìn)行集群內(nèi)廣播，所有其他節(jié)點(diǎn)驗證成功后事務(wù)在集群所有節(jié)點(diǎn)進(jìn)行提交，反之rollback。PXC保證整個集群所有數(shù)據(jù)的強(qiáng)一致性，滿足CAP理論中的CA，即 Consistency 和 Availability。
Percona XtraDB Cluster 有很多組件：
- Percona Server for MySQL（MySQL的Percona分支）；
- Percona XtraBackup （主要用于集群的快照備份）；
- wsrep patches / Galera Library；
該解決方案幾乎是同步的，可與組復(fù)制相媲美。但是，它還具有使用多主復(fù)制的能力。Percona XtraDB Cluster這樣的組件能很好的提高數(shù)據(jù)庫基礎(chǔ)架構(gòu)可用性：
Row-Based VS. Statement-Based
討論MySQL復(fù)制，就不得不提Row-Based復(fù)制和Statement-Based復(fù)制。 因為它們是兩種不同復(fù)制方案的實現(xiàn)原理。
對于statement-based 復(fù)制（被翻譯為基于語句復(fù)制），執(zhí)行的SQL本身會被寫入binlog中，例如完全相同的 INSERT/UPDATE/DELETE 語句會被在slave上執(zhí)行。它的優(yōu)缺點(diǎn)如下：
- 審計數(shù)據(jù)庫會更容易，因為實際執(zhí)行的SQL語句就被記錄在binlog中；
- 主從之間會有更少的數(shù)據(jù)傳輸；
- binlog日志需要的空間更小；
- 不確定性SQL可能會給slave帶來很大的影響；
- 某些操作（例如insert...select）會有性能劣勢；
- Statement-based復(fù)制會由于SQL優(yōu)化和執(zhí)行變得更慢；
- slave上一些復(fù)雜SQL執(zhí)行時，執(zhí)行計劃評估可能變得糟糕；
- 數(shù)據(jù)一致性問題會有更大的挑戰(zhàn)；
Row-based 復(fù)制（基于行復(fù)制）是從MySQL 5.7.7起默認(rèn)的選擇，它有很多優(yōu)點(diǎn)，改變的行會被記錄在binlog中，因此它不需要上下文信息。它的其他優(yōu)點(diǎn)如下：:
- 每一個改變都能被復(fù)制，所以是最安全的復(fù)制方式；
- 對于包含不是很多行改變的高并發(fā)操作，性能有一定的提升；
- 顯著的改善了數(shù)據(jù)一致性；
當(dāng)然，也有缺點(diǎn)：
- 網(wǎng)絡(luò)流量顯著變大，尤其當(dāng)操作很多行記錄的時候，可能打爆網(wǎng)絡(luò)；
- 對于影響很多行的操作，Row-based就會很吃力，不擅長；
- 數(shù)據(jù)庫操作審計變得更加困難，因為binlog中不記錄SQL，取而代之的是記錄變更的數(shù)據(jù)；
- Row-based相比statement-based在一些場景下會更慢；
關(guān)于復(fù)制的誤解
誤解1: 復(fù)制就是集群
標(biāo)準(zhǔn)的異步復(fù)制不是集群，記住不管是標(biāo)準(zhǔn)的異步復(fù)制還是半同步復(fù)制，都不能保證環(huán)境服務(wù)于同一數(shù)據(jù)集。 而使用集群（例如Percona XtraDB Cluster）時，這是不同的，任意一個請求打到任意一臺服務(wù)器上其結(jié)果都一樣。如果不是，則會從群集中刪除受影響的節(jié)點(diǎn)。異步復(fù)制沒有這樣的保障，即使某個slave節(jié)點(diǎn)與master處于不一致狀態(tài)時仍然會接受操作請求。
誤解2: 復(fù)制作為手動故障轉(zhuǎn)移方案
理論上來說，兩個環(huán)境之間是有可比性的。然而，有許多參數(shù)能影響性能和數(shù)據(jù)一致性。只要你使用了異步復(fù)制，在master上發(fā)生的事務(wù)正確性就無法在slave上得到保障。當(dāng)然，你可以通過增強(qiáng)持久化的配置來改善這點(diǎn)，但是它相應(yīng)的會帶來一定的性能損耗，性能和可靠之間總需要做一定的取舍。
誤解3: 我有復(fù)制，所以不用備份
復(fù)制是為了對數(shù)據(jù)集有一個可訪問的副本的解決方案，通過把讀請求打到復(fù)制節(jié)點(diǎn)，能減輕master的壓力。但是復(fù)制不是備份。備份一般是指離線備份，它的作用是數(shù)據(jù)庫所在環(huán)境發(fā)生災(zāi)難性的破壞不可恢復(fù)時，還能通過備份恢復(fù)數(shù)據(jù)庫。對數(shù)據(jù)庫進(jìn)行離線備份是非常重要和有意義的事情！
誤解4: 因為有復(fù)制，所以數(shù)據(jù)庫能負(fù)載均衡事務(wù)請求
給master增加一個slave盡管可以改善系統(tǒng)的可用性，但是你仍然需要自己做幾件事情：把讀請求打到slave上，把寫請求打到master上。有很多代理工具可以完成這樣的事情，當(dāng)然你可以自己動手造輪子！
