大家好，我是君哥。今天來聊一聊 MySQL 主從架構(gòu)。

MySQL Replication 是 MySQL 官方提供的主從同步方案，用于將 MySQL 主庫(kù)的數(shù)據(jù)同步到從庫(kù)中，從庫(kù)可以供應(yīng)用程序讀取數(shù)據(jù)。

1.簡(jiǎn)介

Replication 是目前 MySQL 使用最多的災(zāi)備方案，主要有 3 個(gè)作用：

• 讀寫分離，寫主庫(kù)讀從庫(kù)。這樣大大降低主庫(kù)的負(fù)載，即使主庫(kù)出現(xiàn)類似鎖表之類的情況，也不影響應(yīng)用讀取數(shù)據(jù)。
• 實(shí)現(xiàn)災(zāi)備，當(dāng)主庫(kù)發(fā)生故障時(shí)，可以方便地把從庫(kù)切換成主庫(kù)，實(shí)現(xiàn)高可用（HA）。
• 水平擴(kuò)展，當(dāng)應(yīng)用訪問量導(dǎo)致數(shù)據(jù)庫(kù) I/O 高時(shí)，可以通過水平擴(kuò)展的方式將降低單機(jī)負(fù)載，降低磁盤 I/O。

下面是一個(gè) MySQL Replication 的案例。

圖片

在上面的例子中，有一個(gè)主庫(kù)，三個(gè)從庫(kù)，通過 Replication，主庫(kù)生成 events 的 binlog 發(fā)給 slave，Slave 將收到的 binlog 拷貝到 relaylog，然后解析 relaylog 中的命令進(jìn)行執(zhí)行，實(shí)現(xiàn)主從數(shù)據(jù)同步。

2.同步原理

MySQL 通過 binlog 實(shí)現(xiàn)同步過程中，會(huì)用到 3 個(gè)線程：

• IO thread: 從庫(kù)執(zhí)行 START SLAVE 語(yǔ)句時(shí)，會(huì)創(chuàng)建一個(gè) IO thread，負(fù)責(zé)連接主節(jié)點(diǎn)，請(qǐng)求更新的 binlog，接收到 binlog 后寫入 relaylog；
• dump thread：主庫(kù)接收到從庫(kù)的 binlog 請(qǐng)求后，創(chuàng)建一個(gè) dump thread，把 binlog 同步給從庫(kù)；
• sql thread：讀取 relaylog，解析 relaylog 的命令并執(zhí)行，將數(shù)據(jù)落庫(kù)。

整個(gè)同步流程如下：

圖片

• 在從庫(kù)上執(zhí)行 change master 命令，設(shè)置要連接主庫(kù)的用戶名、密碼、ip、端口以及請(qǐng)求同步的 binlog 中的位置，這個(gè)位置包含文件名和binlog offset；
• 從庫(kù)執(zhí)行 start slave 命令，這時(shí)會(huì)啟動(dòng)上面的 IO thread 和 sql thread，其中 IO thread 負(fù)責(zé)跟主庫(kù)建立連接；
• 主庫(kù)收到從庫(kù)的連接請(qǐng)求后，校驗(yàn)用戶名密碼；
• 主庫(kù)校驗(yàn)通過后創(chuàng)建 dump thread，按照從庫(kù)請(qǐng)求 binlog 的 offset 將 binlog 發(fā)給從庫(kù)；
• 從庫(kù)收到主庫(kù)發(fā)送的 binlog 后，將日志寫入 relaylog；
• sql thread 讀取 relaylog，解析出命令后執(zhí)行。

3.優(yōu)缺點(diǎn)

前面講到，主從同步有讀寫分離、實(shí)現(xiàn)災(zāi)備、水平擴(kuò)展等優(yōu)點(diǎn)。那主從同步有哪些缺點(diǎn)呢？最大的缺點(diǎn)就是主從延遲。

導(dǎo)致主從延遲的主要原因如下：

• 從庫(kù)所在機(jī)器性能差，命令執(zhí)行慢；
• 從庫(kù)查詢壓力大，消耗了大量 CPU 資源，影響了 sql thread 執(zhí)行；
• 主庫(kù)有大事務(wù)（比如大表DDL），這個(gè)事務(wù)里面執(zhí)行的 sql 比較多，一方面主庫(kù)需要等待事務(wù)執(zhí)行完成才能寫入 binlog，另一方面同步到從庫(kù)和在從庫(kù)執(zhí)行都需要花費(fèi)很多時(shí)間，導(dǎo)致主從延遲；
• 數(shù)據(jù)庫(kù)版本低，在 MySQL 5.6 之前，只支持單線程復(fù)制，效率比較低；
• 表上無主鍵，主庫(kù)利用索引更改數(shù)據(jù)，從庫(kù)只能用全表掃描。

要解決主備延遲的問題，可以考慮下面方法：

• 優(yōu)化業(yè)務(wù)邏輯，避免使用大事務(wù)，或者大事務(wù)場(chǎng)景盡量放在業(yè)務(wù)低峰期執(zhí)行；
• 提高從庫(kù)所在機(jī)器的性能；
• 保障網(wǎng)絡(luò)性能，避免網(wǎng)絡(luò)延遲；
• 引入 semi-sync 半同步復(fù)制，配合異步復(fù)制。

主從同步的第二個(gè)缺點(diǎn)就是數(shù)據(jù)丟失。

MySQL 有 3 種主從復(fù)制方式：

• 異步復(fù)制：主庫(kù)執(zhí)行完客戶端提交的事務(wù)后立即將結(jié)果返回給客戶端，不關(guān)心從庫(kù)是否同步完成。這種方式很容易發(fā)生數(shù)據(jù)丟失，比如主庫(kù)的日志還未同步給從庫(kù)就宕機(jī)了，這時(shí)需要在從庫(kù)中選擇一個(gè)作為新主庫(kù)，之前未同步完成的數(shù)據(jù)就丟失了；
• 全同步復(fù)制：主庫(kù)執(zhí)行完客戶端提交的事務(wù)并且等待從庫(kù)也執(zhí)行完成數(shù)據(jù)同步后再把結(jié)果返回給客戶端。這種方式能夠保證不丟失數(shù)據(jù)，但是數(shù)據(jù)庫(kù)的性能會(huì)受到影響；
• 半同步復(fù)制：是介于全同步和異步復(fù)制的一種方式，主庫(kù)至少等待一個(gè)從庫(kù)接收 binlog 并成功寫入到 relaylog 后給客戶端返回結(jié)果。主庫(kù)不需要等待所有從庫(kù)返回 ACK。

MySQL 中默認(rèn)采用異步復(fù)制，這樣很容易導(dǎo)致數(shù)據(jù)丟失。一個(gè)好的方式就是采用 semi-sync 半同步復(fù)制插件。不過 semi-sync 存在一個(gè)問題，主庫(kù)寫數(shù)據(jù)到 binlog 后執(zhí)行 commit，才會(huì)給從庫(kù)同步數(shù)據(jù)。如果從庫(kù)還沒有返回 ACK，主庫(kù)發(fā)生了宕機(jī)，從庫(kù)還沒有寫完 relaylog 就被選擇為主庫(kù)，也會(huì)發(fā)生數(shù)據(jù)丟失。

為了解決這個(gè)問題，MySQL 5.7 引入了增強(qiáng)版半同步復(fù)制。主庫(kù)寫入數(shù)據(jù)到 binlog 后，就給從庫(kù)進(jìn)行同步，直到至少一個(gè)從庫(kù)返回給主庫(kù) ACK，主庫(kù)才會(huì)進(jìn)行 commit 操作。

4.總結(jié)

本文介紹了 MySQL 主從同步方案的優(yōu)缺點(diǎn)，希望能對(duì)你使用和理解 MySQL 有所幫助。