MySQL 主從復制（Master-Slave Replication）是一種數(shù)據(jù)復制技術(shù)，用于在多個數(shù)據(jù)庫服務器之間的數(shù)據(jù)同步。在主從復制架構(gòu)中，一個服務器被設置為主服務器（Master），充當數(shù)據(jù)源，其他服務器被設置為從服務器（Slave），用來復制主服務器的數(shù)據(jù)。

1.主從復制優(yōu)點

主從復制的主要優(yōu)點有以下幾個：

• 高可用性：通過將主數(shù)據(jù)庫的數(shù)據(jù)復制到一個或多個從數(shù)據(jù)庫，可以在主數(shù)據(jù)庫故障時快速切換到從數(shù)據(jù)庫，以實現(xiàn)系統(tǒng)的高可用性和容錯能力，從而保證系統(tǒng)的持續(xù)可用性。
• 提高整體性能和吞吐量：通過將讀請求分散到多個從服務器上進行處理，從而減輕了主服務器的負載壓力，提高數(shù)據(jù)庫系統(tǒng)的整體性能和吞吐量。主服務器主要負責寫操作，而從服務器主要負責讀操作，從而分擔了主服務器的壓力。
• 數(shù)據(jù)備份和恢復：通過主從同步，可以將主服務器上的數(shù)據(jù)異步復制到從服務器上，從而實現(xiàn)數(shù)據(jù)備份和災難恢復的需求。在應對意外數(shù)據(jù)丟失、災難恢復或誤操作時，可以使用從服務器作為數(shù)據(jù)的備份源來進行數(shù)據(jù)恢復。

2.如何實現(xiàn)主從復制？

（1）配置并重啟主服務器

在主服務器的配置文件（my.cnf）中添加以下參數(shù)：

“

[mysqld] server-id = 1 # 設置服務器 ID，每個主服務器和從服務器都必須有唯一的 ID 

log_bin = /var/log/mysql/mysql-bin.log # 開啟二進制日志，記錄數(shù)據(jù)修改操作

”

以上配置完成之后，重啟 MySQL 服務器，因為重啟了 MySQL 服務才能讓配置生效。

（2）創(chuàng)建用于主從復制的用戶

登錄到主服務器上，執(zhí)行以下命令：

CREATE USER 'repl'@'%' IDENTIFIED BY 'password';    -- 替換為實際的用戶名和密碼
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';

（3）查看主服務器狀態(tài)

在 MySQL 主服務器中，執(zhí)行以下命令，記錄下 File 和 Position 的值，后續(xù)用于配置從服務器：

SHOW MASTER STATUS;

（4）配置并重啟從服務器

在從服務器的配置文件（my.cnf）中添加以下參數(shù)：

“

[mysqld] server-id = 2 # 設置服務器 ID，每個主服務器和從服務器都必須有唯一的 ID

”

重啟從服務器，讓以上配置生效。

（5）在從服務器上設置主服務器信息

登錄到從服務器的 MySQL 中，執(zhí)行以下命令（將 MASTER_HOST、MASTER_USER、MASTER_PASSWORD、MASTER_LOG_FILE 和 MASTER_LOG_POS 替換為對應的值）：

CHANGE MASTER TO MASTER_HOST='master_ip', MASTER_USER='repl', 
MASTER_PASSWORD='password', MASTER_LOG_FILE='binlog_file', 
MASTER_LOG_POS=log_file_position;

（6）啟動從服務器的復制進程

執(zhí)行以下命令啟動從服務器的復制進程：

START SLAVE;

（7）檢查從服務器的復制狀態(tài)

執(zhí)行以下命令，確保 Slave_IO_Running 和 Slave_SQL_Running 的值都為 "YES"：

SHOW SLAVE STATUS \G;

3.主從復制原理

MySQL 數(shù)據(jù)庫的主從復制主要是基于 Binary Log（二進制文件，簡稱 bin log）實現(xiàn)的，它的實現(xiàn)流程如下：

它的主要執(zhí)行流程如下：

• 主數(shù)據(jù)庫接收到一個寫操作（如 INSERT、UPDATE、DELETE）時，會將這個操作記錄到二進制日志（Binary Log）中，將數(shù)據(jù)修改的操作按順序記錄下來。
• 從數(shù)據(jù)庫 IO 線程會自動連接主服務，從二進制中讀取同步數(shù)據(jù)，記錄到中繼日志（Relay Log）中。
• 從數(shù)據(jù)庫的 SQL 線程會定期從中繼日志中獲取同步數(shù)據(jù)，寫入到從數(shù)據(jù)庫中。

4.Bin Log 日志格式

Binary Log 二級制日志，它總共有以下三種格式（不同的日志格式?jīng)Q定了不同的主從同步效果）：

• STATEMENT 格式（語句模式，出現(xiàn)在 MySQL 5.1 之前）：在這種格式下，binlog 記錄的是執(zhí)行的 SQL 語句的文本。

1. 優(yōu)點：日志文件通常較小，復制效率較高。
2. 缺點：在某些情況下，由于數(shù)據(jù)庫環(huán)境的差異（如表結(jié)構(gòu)、字符集等），在從服務器上重放這些 SQL 語句可能會導致不一致的結(jié)果。例如，獲取當前時間的函數(shù)或存儲過程等，可能會導致數(shù)據(jù)不一致。

• ROW 格式（行模式，誕生于 MySQL 5.1）：在這種格式下，binlog 記錄的是每一行數(shù)據(jù)更改的具體內(nèi)容。

3. 優(yōu)點：能夠精確地記錄數(shù)據(jù)的變化，避免了 STATEMENT 格式中的環(huán)境依賴問題，提供了更強的一致性保證。
4. 缺點：日志文件可能會比 STATEMENT 格式大，因為記錄了每一行的詳細變化。此外，ROW 格式的日志在進行大量數(shù)據(jù)更新時可能會導致更高的 I/O 開銷。

• MIXED 格式（混合模式）：在這種格式下，binlog 可以根據(jù)具體的 SQL 語句和操作自動選擇使用 STATEMENT 或 ROW 格式。

5. 優(yōu)點：結(jié)合了 STATEMENT 和 ROW 格式的優(yōu)點，能夠在保證一致性的同時盡可能地優(yōu)化日志大小和復制性能。
6. 缺點：由于混合使用了兩種格式，可能需要更復雜的管理和監(jiān)控。在某些特定情況下，MIXED 格式可能無法達到最優(yōu)的性能或一致性。

5.主從復制模式

MySQL 中主要有以下兩種主從復制的模式，分別是異步復制和半同步復制。

• 異步復制：MySQL 主從復制中最常見和默認的模式。在異步復制模式中，主服務器將數(shù)據(jù)修改操作記錄到二進制日志（Binary Log）中，并將日志傳輸給從服務器。從服務器接收到二進制日志后，會異步地應用這些日志進行數(shù)據(jù)復制。

1. 優(yōu)點：它的優(yōu)點是及時響應給使用者，主服務器不會受到從服務器的影響而等待確認，可以提高主服務器的性能。
2. 缺點：由于是異步復制，可能存在數(shù)據(jù)傳輸?shù)难舆t，且從服務器上的復制過程是不可靠的。如果主服務器故障，尚未應用到從服務器的數(shù)據(jù)可能會丟失。

• 半同步復制：半同步復制是 MySQL 主從復制中的一種增強模式。在半同步復制模式中，主服務器將數(shù)據(jù)修改操作記錄到二進制日志，并等待至少一個從服務器確認已接收到并應用了這些日志后才繼續(xù)執(zhí)行后續(xù)操作。

3. 優(yōu)點：可以提供更高的數(shù)據(jù)一致性和可靠性，確保至少一個從服務器與主服務器保持同步。如果主服務器故障，已經(jīng)確認接收并應用到從服務器的數(shù)據(jù)不會丟失。
4. 缺點：由于半同步復制需要等待從服務器的確認，因此相對于異步復制，會增加一定的延遲，可能會影響主服務器的性能。

如果對數(shù)據(jù)一致性和可靠性要求較高，可以考慮使用半同步復制；如果對延遲和主服務器性能要求較高，可以繼續(xù)使用異步復制，根據(jù)實際需求調(diào)整復制模式。

小結(jié)

MySQL 主從復制用于多個數(shù)據(jù)庫服務器之間的數(shù)據(jù)同步，它可以提供高可用性、提高數(shù)據(jù)庫整體性能和吞吐量，以及可以進行數(shù)據(jù)備份和數(shù)據(jù)庫恢復。MySQL 主從復制是通過 bin log 實現(xiàn)的，主服務寫入操作會同時添加到 bin log 中，而從數(shù)據(jù)庫定期拉取主數(shù)據(jù)庫的 bin log，然后將拉取的數(shù)據(jù)存放到自己的 relay log 中，之后再由單獨 SQL 線程將數(shù)據(jù)寫入到從數(shù)據(jù)庫中，此時 MySQL 的主從同步就完成了。