關(guān)于不同的MySQL復(fù)制解決方案概述

我在解決方案團(tuán)隊(duì)工作多年，發(fā)現(xiàn)數(shù)據(jù)庫(kù)復(fù)制總是被誤解，甚至有些人根本完全不理解，所以本文將來(lái)回顧一下MySQL環(huán)境中的復(fù)制概念，并且澄清一些大家對(duì)于復(fù)制的誤解。

什么是復(fù)制?

復(fù)制：保證信息被復(fù)制并有目的地填充到另一個(gè)環(huán)境中，而不是僅存儲(chǔ)在一個(gè)位置(基于源環(huán)境的事務(wù))。如果更白話一點(diǎn)來(lái)說(shuō)就是在您的基礎(chǔ)架構(gòu)上使用輔助服務(wù)器來(lái)讀取或使用其他管理解決方案。

下圖展示了MySQL復(fù)制環(huán)境的示例。

如果我們把范圍縮小到MySQL中，那么在復(fù)制時(shí)我們有幾種選擇呢?

標(biāo)準(zhǔn)異步復(fù)制

異步復(fù)制意味著事務(wù)完全在本地環(huán)境中完成，并且不受復(fù)制從屬本身的影響。完成更改后，主服務(wù)器將使用數(shù)據(jù)修改或?qū)嶋H語(yǔ)句(基于行的復(fù)制或基于語(yǔ)句的復(fù)制之間的差異會(huì)在之后講)填充二進(jìn)制日志。此轉(zhuǎn)儲(chǔ)線程讀取二進(jìn)制日志并將其發(fā)送到從IO線程。從站使用其IO線程將其置于自己的預(yù)處理隊(duì)列(稱為中繼日志)中。從站使用SQL線程執(zhí)行從站數(shù)據(jù)庫(kù)上的每個(gè)更改。

半同步復(fù)制

半同步復(fù)制意味著從設(shè)備和主設(shè)備相互通信以保證事務(wù)的正確傳輸。主設(shè)備僅填充binlog并繼續(xù)其會(huì)話，其中一個(gè)從設(shè)備確認(rèn)事務(wù)已正確放置在從設(shè)備的中繼日志中。

半同步復(fù)制可確保正確復(fù)制事務(wù)，但不保證實(shí)際發(fā)生從設(shè)備上的提交。

需要注意的是，半同步復(fù)制可確保主服務(wù)器等待繼續(xù)處理特定會(huì)話中的事務(wù)，直到至少有一個(gè)從服務(wù)器確認(rèn)接收到事務(wù)(或達(dá)到超時(shí))。這與異步復(fù)制不同，因?yàn)榘胪皆试S額外的數(shù)據(jù)完整性。

請(qǐng)記住，半同步復(fù)制會(huì)影響性能，因?yàn)樗枰却齺?lái)自從站的實(shí)際ACK的往返。

組復(fù)制

這是MySQL Community Edition 5.7中引入的新概念，并且在MySQL 5.7.17中進(jìn)行了GA。這是一個(gè)用于虛擬同步復(fù)制的新插件。

每當(dāng)在節(jié)點(diǎn)上執(zhí)行事務(wù)時(shí)，插件都會(huì)嘗試與其他節(jié)點(diǎn)達(dá)成共識(shí)，然后再將其返回給客戶端。 雖然與標(biāo)準(zhǔn)MySQL復(fù)制相比，該解決方案是完全不同的概念，但它基于使用binlog生成和處理日志事件。

以下是組復(fù)制的示例體系結(jié)構(gòu)。

如果對(duì)Group Replication感興趣，請(qǐng)參考以下文章：

http://mysqlhighavailability.com/mysql-group-replication-its-in-5-7-17-ga/

http://mysqlhighavailability.com/performance-evaluation-mysql-5-7-group-replication/

Percona XtraDB Cluster/ Galera Cluster

另一種允許將信息復(fù)制到其他節(jié)點(diǎn)的解決方案是Percona XtraDB Cluster。此解決方案?jìng)?cè)重于提供一致性，使用認(rèn)證過程來(lái)保證事務(wù)避免沖突并正確執(zhí)行。在這種情況下，我們討論的是集群解決方案，每個(gè)環(huán)境都受相同數(shù)據(jù)的約束，并且節(jié)點(diǎn)之間存在通信以保證一致性。

Percona XtraDB Cluster有多個(gè)組件：

• Percona Server for MySQL

• Percona XtraBackup用于執(zhí)行正在運(yùn)行的集群的快照(正在恢復(fù)或添加節(jié)點(diǎn))。

• wsrep patches/Galera Library

該解決方案幾乎是同步的，可與組復(fù)制相媲美。但是，它還具有使用多主復(fù)制的功能。像Percona XtraDB Cluster這樣的解決方案是提高數(shù)據(jù)庫(kù)基礎(chǔ)架構(gòu)可用性的一個(gè)組件。

基于行的復(fù)制與基于語(yǔ)句的復(fù)制

使用基于語(yǔ)句的復(fù)制，SQL查詢本身將寫入二進(jìn)制日志。例如，從站執(zhí)行完全相同的INSERT / UPDATE / DELETE語(yǔ)句。

該方法有很多優(yōu)缺點(diǎn)：

• 由于實(shí)際語(yǔ)句記錄在二進(jìn)制日志中，因此審核數(shù)據(jù)庫(kù)要容易得多

• 通過線路傳輸?shù)臄?shù)據(jù)更少

• 非確定性查詢可能會(huì)在從屬環(huán)境中造成實(shí)際破壞

• 某些查詢存在性能劣勢(shì)，例如基于SELECT的INSERT

• 由于SQL優(yōu)化和執(zhí)行，基于語(yǔ)句的復(fù)制速度較慢

基于行的復(fù)制是自MySQL 5.7.7以來(lái)的默認(rèn)選擇，具有許多優(yōu)點(diǎn)。行更改記錄在二進(jìn)制日志中，并且不需要上下文信息，消除了非確定性查詢的影響。

其它優(yōu)點(diǎn)包括：

• 包含少量行更改的高并發(fā)查詢的性能改進(jìn)

• 顯著的數(shù)據(jù)一致性改進(jìn)

其缺點(diǎn)包括：

• 如果有修改大量行的查詢，那么網(wǎng)絡(luò)流量可能會(huì)大得多

• 審核數(shù)據(jù)庫(kù)的更改更加困難

• 在某些情況下，基于行的復(fù)制可能比基于語(yǔ)句的復(fù)制慢

關(guān)于復(fù)制的誤解

復(fù)制是集群

標(biāo)準(zhǔn)異步復(fù)制不是同步集群。請(qǐng)記住，標(biāo)準(zhǔn)和半同步復(fù)制不保證環(huán)境服務(wù)于同一數(shù)據(jù)集。使用Percona XtraDB Cluster時(shí)，每個(gè)服務(wù)器實(shí)際上需要分別處理每個(gè)更改。如果不是，則從群集中刪除受影響的節(jié)點(diǎn)。異步復(fù)制不具有此故障安全性，在不一致的情況下，仍然可以接受讀操作。

從理論上講，環(huán)境應(yīng)具有可比性。但是，有許多參數(shù)會(huì)影響數(shù)據(jù)傳輸?shù)男屎鸵恢滦?。只要使用異步?fù)制，就無(wú)法保證事務(wù)正確發(fā)生。使用者可以通過增強(qiáng)配置的持久性來(lái)避免這種情況，但這會(huì)帶來(lái)性能損失。

使用pt - table - checksum工具驗(yàn)證主服務(wù)器和從服務(wù)器的一致性 。

有復(fù)制就不需要備份了

沒錯(cuò)，復(fù)制是一個(gè)很好的解決方案，可以獲得數(shù)據(jù)集的可訪問副本(例如報(bào)告問題，讀取查詢，生成備份)。但其并不能替代備份解決方案。通過異地備份，可以在發(fā)生重大災(zāi)難、用戶錯(cuò)誤或其他原因時(shí)可以重建環(huán)境。有些人使用 delayed slaves ，但它也不能取代適當(dāng)?shù)臑?zāi)難恢復(fù)程序。

有復(fù)制，所以環(huán)境將負(fù)載平衡事務(wù)

雖然通過使用相同數(shù)據(jù)集運(yùn)行輔助實(shí)例可能會(huì)提高環(huán)境的可用性，但仍可能需要將讀取查詢指向從屬服務(wù)器，而將寫查詢指向主服務(wù)器。你可以使用代理工具或在自己的應(yīng)用程序中定義此功能。

復(fù)制會(huì)顯著減慢速度

復(fù)制對(duì)主服務(wù)器的性能影響很小。 Peter Zaitsev在一篇文章中曾討論過從服務(wù)器對(duì)主服務(wù)器的潛在影響。請(qǐng)記住，寫入二進(jìn)制日志可能會(huì)影響性能，尤其是當(dāng)您有許多小事務(wù)，然后被多個(gè)從服務(wù)器轉(zhuǎn)儲(chǔ)和接收時(shí)。

當(dāng)然，除此之外還有許多其他參數(shù)都可能會(huì)影響實(shí)際主從設(shè)置的性能。