【譯】MySQL復制入門：探索不同類型的MySQL復制解決方案

原文地址：An Introduction to MySQL Replication: Exploring Different Types of MySQL Replication Solutions

在這篇博文中，我將深入介紹 MySQL 復制，回答它是什么、如何工作、它的優勢和挑戰，并回顧作為 MySQL 環境（特別是 Percona Server for MySQL）一部分的一些 MySQL 復制概念。最后，我還將澄清人們對復制的一些常見誤解，以及 Percona 可以提供哪些幫助。

什么是 MySQL 復制？

MySQL 復制是將主 MySQL 數據庫中的數據復制并發送到一個或多個輔助數據庫（稱為副本）的過程。
復制確保信息被復制并有目的地填充到另一個環境中，而不是只存儲在一個位置（基于源環境的事務）。
這樣做的目的是將基礎架構上的輔助服務器用于讀取或其他管理解決方案。下圖顯示了一個 MySQL 復制環境示例。
在這里插入圖片描述

MySQL 復制安裝要求

在本節中，我們將介紹實施 MySQL 復制的基本要素：

前提條件和要求：

Primary-Replica 配置：確保有一個主 MySQL 數據庫和一個或多個副本 MySQL 數據庫。
網絡連接：在主服務器和副本服務器之間建立可靠的網絡連接。
MySQL 版本：確保主服務器和副本服務器上的 MySQL 版本與復制兼容。

安裝 MySQL 復制 - 具體步驟：

備份數據：在開始之前，創建主數據庫備份，以防止在設置過程中丟失數據。
配置主服務器：
- 編輯主服務器上的 MySQL 配置文件（my.cnf 或 my.ini），啟用二進制日志記錄。
- 重新啟動 MySQL 服務。
創建復制用戶：
- 登錄主服務器上的 MySQL，創建具有必要權限的專用復制用戶。
記錄二進制日志坐標：
- 記下當前二進制日志文件和主服務器上的位置。
配置復制服務器：
- 在每個副本服務器上，編輯 MySQL 配置文件，將其配置為副本。
- 將 server-id 設置為唯一值。
- 指定主服務器的主機名或 IP 地址。
- 在每個副本上重新啟動 MySQL 服務。
初始化復制：
- 在其中一個副本服務器上運行 CHANGE MASTER TO 命令，指定主服務器的二進制日志文件和位置。
- 啟動副本服務器的復制進程。
驗證復制：
- 使用 SHOW SLAVE STATUS 檢查復制的狀態。確保 "Slave_IO_Running "和 "Slave_SQL_Running "都顯示 “Yes”。
添加更多副本（可選）：
- 如果需要，在其他副本服務器上重復配置步驟。
監控和維護：
- 定期監控復制狀態和日志。
- 執行日常維護和備份，確保數據完整性。
擴展和負載平衡（可選）：
- 如果有多個副本，請實施負載平衡和故障切換機制。

MySQL 復制有哪些潛在優缺點？

MySQL復制可提供高可用性、負載平衡和數據冗余，從而提高系統可靠性。它還能實現地理分布式數據庫的災難恢復。不過，考慮潛在的缺點也很重要，包括管理副本的復雜性增加、復制滯后的可能性以及需要監控和維護以確保各副本的一致性和可靠性。

優點

MySQL 復制有很多優點，但其中幾個重點包括：通過將讀取密集型工作負載分布到多個副本、降低主數據庫服務器負載和提高整體性能來增強可擴展性。復制還能在主服務器不可用時切換到副本服務器，從而提高數據庫可用性。
最后，在發生災難的情況下，數據和數據庫可以快速恢復，因為復制提供了地理上分散的數據副本。

缺點

盡管有這么多好處，MySQL 復制也會面臨一些潛在的缺點。一個非常常見的問題是數據一致性，尤其是在寫入活動較多的設置中。副本可能會落后于主服務器，從而影響任何依賴實時數據的應用程序。
另一個問題是單點故障風險。如果主服務器出現故障，整個復制過程就會中斷。實施前面討論的故障轉移機制可以降低這種風險。
在安全性方面，如果沒有正確配置加密和訪問控制，主服務器和副本服務器之間傳輸的數據可能會受到攻擊。

MySQL 復制有哪些不同類型？

您實際上有幾種不同的選擇：

標準異步復制（Standard asynchronous replication）

異步復制意味著事務完全在本地環境中完成，不受復制本身的影響。

在完成更改后，主線程會將數據修改或實際語句填充到二進制日志中（基于行的復制和基于語句的復制之間的區別–稍后詳述）。轉儲線程讀取二進制日志，并將其發送給副本 IO 線程。副本使用其 IO 線程將其放入自己的預處理隊列（稱為中繼日志）。

副本使用 SQL 線程執行副本數據庫中的每次更改。
在這里插入圖片描述

半同步復制（Semi-synchronous replication）

半同步復制是指副本和主服務器之間相互通信，以保證事務的正確傳輸。只有當其中一個副本確認事務已正確放入副本的一個中繼日志時，主服務器才會填充 binlog 并繼續其會話。

半同步復制能保證事務被正確復制，但不能保證在副本上的提交實際發生。
在這里插入圖片描述
需要注意的是，半同步復制確保主服務器等待繼續處理特定會話中的事務，直到至少有一個副本 ACK 了事務接收（或超時）。這與異步復制不同，半同步復制允許額外的數據完整性。

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

組復制（Group Replication）

這一新概念在 MySQL 社區版 5.7 中引入，并在 MySQL 5.7.17 中得到認可。它是一個用于虛擬同步復制的全新插件。
每當在一個節點上執行事務時，插件都會嘗試與其他節點達成共識，然后再將完成的事務返回給客戶端。雖然該解決方案與標準的 MySQL 復制概念完全不同，但它基于使用 binlog 生成和處理日志事件。

以下是組復制的架構示例。
在這里插入圖片描述

Percona XtraDB Cluster / Galera Cluster

另一種可將信息復制到其他節點的解決方案是 Percona XtraDB Cluster。該解決方案專注于提供一致性，還使用認證流程來保證事務避免沖突并正確執行。

在這種情況下，我們談論的是集群解決方案。每個環境都使用相同的數據，節點之間通過通信來保證一致性。

Percona XtraDB Cluster 有多個組件：

用于 MySQL 的 Percona 服務器
Percona XtraBackup，用于執行運行集群的快照（如果要恢復或添加節點）。
wsrep 修補程序/Galera 庫

該解決方案實際上是同步的，可與組復制（Group Replication）相媲美。不過，它還具有使用多主復制的功能。Percona XtraDB Cluster 等解決方案是提高數據庫基礎架構可用性的組成部分。
在這里插入圖片描述
通過我們的電子書了解如何優化數據庫安裝配置以實現高可用性，Percona Distribution for PostgreSQL: High Availability With Streaming Replication

基于行的復制與基于語句的復制（Row-Based Replication Vs. Statement-Based Replication）

基于語句的復制

在基于語句的復制中，SQL 查詢本身被寫入二進制日志。例如，副本會執行完全相同的 INSERT/UPDATE/DELETE 語句。

這種系統有很多優缺點：

由于實際語句記錄在二進制日志中，因此審計數據庫更加容易
通過線路傳輸的數據更少
非確定性查詢（即那些其結果可能因多種因素而變化的查詢）可在副本環境中造成實際破壞
使用基于語句的復制（基于 SELECT 的 INSERT）進行某些查詢時，可能會出現性能劣勢
由于 SQL 的優化和執行，基于語句的復制速度較慢

基于行的復制

基于行的復制是從 MySQL 5.7.7 開始的默認選擇，它有很多優點。行更改會記錄在二進制日志中，而且不需要上下文信息。這消除了非確定性查詢的影響。

其他一些優勢包括

包含少量行更改的高并發查詢的性能提升
顯著提高數據一致性

當然，也有一些缺點：

如果有修改大量行的查詢，網絡流量會大大增加
更難審核數據庫中的更改
在某些情況下，基于行的復制可能比基于語句的復制更慢

處理故障和確保高可用性

確保 MySQL 復制的高可用性對于不間斷的數據庫訪問非常重要，有幾種策略可用于實現這一目標。其中一種方法是實施故障轉移（failover）機制。故障切換可確保在主 MySQL 服務器因硬件故障或其他問題而不可用時，系統無縫切換到備用副本。設置故障轉移機制可以使用負載平衡器或代理服務器來完成，它們會持續監控主服務器的健康狀況。一旦發現問題，這些工具就會自動將流量重定向到備用副本。

半同步復制是另一種在高可用性 MySQL 設置中確保數據一致性的重要技術。這種方法要求在主服務器上提交事務之前，至少要有一個副本確認，從而確保數據更改在主服務器上確認之前，安全地復制到至少一個副本。這就降低了主服務器發生故障時數據丟失的風險。通過優先考慮數據一致性而不是原始性能，半同步復制為防止數據差異提供了一個額外的保護層，使其成為對保持數據完整性至關重要的高可用性配置中的一項重要功能。