關于不同的MySQL復制解決方案概述

我在解決方案團隊工作多年，發現數據庫復制總是被誤解，甚至有些人根本完全不理解，所以本文將來回顧一下MySQL環境中的復制概念，并且澄清一些大家對于復制的誤解。

什么是復制?

復制：保證信息被復制并有目的地填充到另一個環境中，而不是僅存儲在一個位置(基于源環境的事務)。如果更白話一點來說就是在您的基礎架構上使用輔助服務器來讀取或使用其他管理解決方案。

下圖展示了MySQL復制環境的示例。

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

標準異步復制

異步復制意味著事務完全在本地環境中完成，并且不受復制從屬本身的影響。完成更改后，主服務器將使用數據修改或實際語句(基于行的復制或基于語句的復制之間的差異會在之后講)填充二進制日志。此轉儲線程讀取二進制日志并將其發送到從IO線程。從站使用其IO線程將其置于自己的預處理隊列(稱為中繼日志)中。從站使用SQL線程執行從站數據庫上的每個更改。

半同步復制

半同步復制意味著從設備和主設備相互通信以保證事務的正確傳輸。主設備僅填充binlog并繼續其會話，其中一個從設備確認事務已正確放置在從設備的中繼日志中。

半同步復制可確保正確復制事務，但不保證實際發生從設備上的提交。

需要注意的是，半同步復制可確保主服務器等待繼續處理特定會話中的事務，直到至少有一個從服務器確認接收到事務(或達到超時)。這與異步復制不同，因為半同步允許額外的數據完整性。

請記住，半同步復制會影響性能，因為它需要等待來自從站的實際ACK的往返。

組復制

這是MySQL Community Edition 5.7中引入的新概念，并且在MySQL 5.7.17中進行了GA。這是一個用于虛擬同步復制的新插件。

每當在節點上執行事務時，插件都會嘗試與其他節點達成共識，然后再將其返回給客戶端。 雖然與標準MySQL復制相比，該解決方案是完全不同的概念，但它基于使用binlog生成和處理日志事件。

以下是組復制的示例體系結構。

如果對Group Replication感興趣，請參考以下文章：

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

另一種允許將信息復制到其他節點的解決方案是Percona XtraDB Cluster。此解決方案側重于提供一致性，使用認證過程來保證事務避免沖突并正確執行。在這種情況下，我們討論的是集群解決方案，每個環境都受相同數據的約束，并且節點之間存在通信以保證一致性。

Percona XtraDB Cluster有多個組件：

• Percona Server for MySQL

• Percona XtraBackup用于執行正在運行的集群的快照(正在恢復或添加節點)。

• wsrep patches/Galera Library

該解決方案幾乎是同步的，可與組復制相媲美。但是，它還具有使用多主復制的功能。像Percona XtraDB Cluster這樣的解決方案是提高數據庫基礎架構可用性的一個組件。

基于行的復制與基于語句的復制

使用基于語句的復制，SQL查詢本身將寫入二進制日志。例如，從站執行完全相同的INSERT / UPDATE / DELETE語句。

該方法有很多優缺點：

• 由于實際語句記錄在二進制日志中，因此審核數據庫要容易得多

• 通過線路傳輸的數據更少

• 非確定性查詢可能會在從屬環境中造成實際破壞

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

• 由于SQL優化和執行，基于語句的復制速度較慢

基于行的復制是自MySQL 5.7.7以來的默認選擇，具有許多優點。行更改記錄在二進制日志中，并且不需要上下文信息，消除了非確定性查詢的影響。

其它優點包括：

• 包含少量行更改的高并發查詢的性能改進

• 顯著的數據一致性改進

其缺點包括：

• 如果有修改大量行的查詢，那么網絡流量可能會大得多

• 審核數據庫的更改更加困難

• 在某些情況下，基于行的復制可能比基于語句的復制慢

關于復制的誤解

復制是集群

標準異步復制不是同步集群。請記住，標準和半同步復制不保證環境服務于同一數據集。使用Percona XtraDB Cluster時，每個服務器實際上需要分別處理每個更改。如果不是，則從群集中刪除受影響的節點。異步復制不具有此故障安全性，在不一致的情況下，仍然可以接受讀操作。

從理論上講，環境應具有可比性。但是，有許多參數會影響數據傳輸的效率和一致性。只要使用異步復制，就無法保證事務正確發生。使用者可以通過增強配置的持久性來避免這種情況，但這會帶來性能損失。

使用pt - table - checksum工具驗證主服務器和從服務器的一致性 。

有復制就不需要備份了

沒錯，復制是一個很好的解決方案，可以獲得數據集的可訪問副本(例如報告問題，讀取查詢，生成備份)。但其并不能替代備份解決方案。通過異地備份，可以在發生重大災難、用戶錯誤或其他原因時可以重建環境。有些人使用 delayed slaves ，但它也不能取代適當的災難恢復程序。

有復制，所以環境將負載平衡事務

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

復制會顯著減慢速度

復制對主服務器的性能影響很小。 Peter Zaitsev在一篇文章中曾討論過從服務器對主服務器的潛在影響。請記住，寫入二進制日志可能會影響性能，尤其是當您有許多小事務，然后被多個從服務器轉儲和接收時。

當然，除此之外還有許多其他參數都可能會影響實際主從設置的性能。