關於不同的MySQL複製解決方案概述

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

什麼是複製?

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

下圖展示了MySQL複製環境的示例。

如果我們把範圍縮小到MySQL中，那麼在複製時我們有幾種選擇呢?

標準非同步複製

非同步複製意味著事務完全在本地環境中完成，並且不受複製從屬本身的影響。完成更改後，主伺服器將使用資料修改或實際語句(基於行的複製或基於語句的複製之間的差異會在之後講)填充二進位制日誌。此轉儲執行緒讀取二進位制日誌並將其傳送到從IO執行緒。從站使用其IO執行緒將其置於自己的預處理佇列(稱為中繼日誌)中。從站使用SQL執行緒執行從站資料庫上的每個更改。

半同步複製

半同步複製意味著從裝置和主裝置相互通訊以保證事務的正確傳輸。主裝置僅填充binlog並繼續其會話，其中一個從裝置確認事務已正確放置在從裝置的中繼日誌中。

半同步複製可確保正確複製事務，但不保證實際發生從裝置上的提交。

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

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

組複製

這是MySQL Community Edition 5.7中引入的新概念，並且在MySQL 5.7.17中進行了GA。這是一個用於虛擬同步複製的新外掛。

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

以下是組複製的示例體系結構。

如果對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在一篇文章中曾討論過從伺服器對主伺服器的潛在影響。請記住，寫入二進位制日誌可能會影響效能，尤其是當您有許多小事務，然後被多個從伺服器轉儲和接收時。

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