從本篇文章開始我們將向讀者介紹mysql的各種服務(wù)集群的搭建方式。大致的討論思路是從最簡的MySQL主從方案開始介紹，通過這種方案的不足延伸出更復(fù)雜的集群方案，并介紹后者是如何針對這些不足進(jìn)行改進(jìn)的。

我們講解的版本還是依據(jù)目前在生產(chǎn)環(huán)境上使用最多的version 5.6進(jìn)行，其中一些特性在Version 5.7和最新的Version 8.0中有所改進(jìn)，但這不影響讀者通過文章去理解構(gòu)建MySQL集群的技術(shù)思路，甚至可以將這種機(jī)制延續(xù)到MariaDB。例如馬上要提到的MySQL自帶的日志復(fù)制機(jī)制（Replicaion機(jī)制）。

MySQL自帶的日志復(fù)制機(jī)制稱為MySQL-Replicaion。從MySQL很早的 Version 5.1版本就有Replicaion技術(shù)，發(fā)展到現(xiàn)有版本該技術(shù)已經(jīng)非常成熟，通過它的支持技術(shù)人員可以做出多種MySQL集群結(jié)構(gòu)。當(dāng)然，后文我們還會(huì)介紹一些由第三方軟件/組件支持的MySQL集群方案。

2-1、MySQL-Replicaion基本工作原理

Replicaion機(jī)制從技術(shù)層面講，存在兩種基本角色：Master和Salve。Master節(jié)點(diǎn)負(fù)責(zé)在Replicaion機(jī)制中，向一個(gè)或者多個(gè)目標(biāo)輸出數(shù)據(jù)，而Salve節(jié)點(diǎn)負(fù)責(zé)在Replicaion機(jī)制中接受Master節(jié)點(diǎn)傳來的數(shù)據(jù)。在實(shí)際業(yè)務(wù)環(huán)境下，Master節(jié)點(diǎn)和Salve節(jié)點(diǎn)還分別有另外一個(gè)名字：Write節(jié)點(diǎn)和Read節(jié)點(diǎn)——是的，利用Replicaion機(jī)制我們可以搭建以讀寫分離為目標(biāo)的MySQL集群服務(wù)。但是為了保證讀者在閱讀文章內(nèi)容時(shí)不會(huì)產(chǎn)生歧義，在本文（和后續(xù)文章）中我們都將使用Master節(jié)點(diǎn)和Salve節(jié)點(diǎn)這樣的稱呼。Replicaion機(jī)制依靠MySQL服務(wù)的二進(jìn)制日志同步數(shù)據(jù)：

如上圖所示，Salve在啟動(dòng)后會(huì)建立一個(gè)和Master節(jié)點(diǎn)的網(wǎng)絡(luò)連接，當(dāng)Master節(jié)點(diǎn)的二進(jìn)制日志發(fā)生變化后，一個(gè)或者多個(gè)MySQL Salve服務(wù)節(jié)點(diǎn)就會(huì)通過網(wǎng)絡(luò)接監(jiān)聽到這些變化日志。接著Salve節(jié)點(diǎn)會(huì)首先在本地將這些變化寫入中繼日志文件（Relay Log），這樣做是為了盡量避免MySQL服務(wù)在出現(xiàn)異常時(shí)同步數(shù)據(jù)失敗，其原理和之前介紹過的InnoDB Log的工作原理相似。當(dāng)中繼日志文件發(fā)生完成記錄后，MySQL Salve服務(wù)會(huì)將這些變化反映到對應(yīng)的數(shù)據(jù)表中，完成一次數(shù)據(jù)同步過程。最后Salve會(huì)更新重做日志文件中的更新點(diǎn)（Position），并準(zhǔn)備下一次Replicaion操作。

在這個(gè)過程中多個(gè)要素都可以進(jìn)行配置，例如可以通過sync_binlog參數(shù)配置Master節(jié)點(diǎn)上數(shù)據(jù)操作次數(shù)和日志寫入次數(shù)配比關(guān)系、可以通過binlog_format參數(shù)配置日志數(shù)據(jù)的信息結(jié)構(gòu)、可以通過sync_relay_log參數(shù)配置Salve節(jié)點(diǎn)上系統(tǒng)接收日志數(shù)據(jù)與寫入中繼日志文件次數(shù)的配比關(guān)系。這些參數(shù)和其它一些在示例中使用的參數(shù)會(huì)在本文后續(xù)小節(jié)進(jìn)行介紹。

2-2、MySQL一主多從搭建方式

介紹完MySQL Replicaion機(jī)制的基本工作方式后，我們緊接著就來快速搭建由一個(gè)Master節(jié)點(diǎn)和一個(gè)Salve節(jié)點(diǎn)構(gòu)成的MySQL集群。讀者可以從這個(gè)一主一從的MySQL集群方案擴(kuò)展出任何一主多從的集群方案：

這個(gè)實(shí)例我們使用Version 5.6版本進(jìn)行設(shè)置，當(dāng)然version 5.7版本的安裝也是類似的。另外，在linux 操作系統(tǒng)上（Centos 5.6/5.7/6.X）安裝MySQL服務(wù)和進(jìn)行基本設(shè)置的過程，由于篇幅和文章定位原因這里就不再進(jìn)行贅述。我們將分別在如下ip的Linux操作安裝集群的Master節(jié)點(diǎn)和Salve節(jié)點(diǎn)：

MySQL Master服務(wù)：192.168.61.140

MySQL Salve服務(wù)：192.168.61.141

2-2-1、設(shè)置Master服務(wù)器

首先需要更改MySQL Master服務(wù)my.cnf主配置文件的信息，主要目的是開啟Master節(jié)點(diǎn)上的二進(jìn)制日志功能（注意這里說的日志并不是InnoDB引擎日志）。

# my.cnf文件中沒有涉及Replicaion機(jī)制的配置信息，就不在這里列出了......# 開啟日志log_bin

# 以下這些參數(shù)會(huì)在后文進(jìn)行說明

sync_binlog=1

binlog_format=mixed

binlog-do-db=qiang

binlog_checksum=CRC32

binlog_cache_size=2M

max_binlog_cache_size=1G

max_binlog_size=100M

# 必須為這個(gè)MySQL服務(wù)節(jié)點(diǎn)設(shè)置一個(gè)集群中唯一的 server id信息

server_id=140

......

在Master節(jié)點(diǎn)的設(shè)置中，有很多參數(shù)可以對日志的生成、存儲(chǔ)、傳輸過程進(jìn)行控制。具體可以參見MySQL官網(wǎng)中的介紹：http://dev.mysql.com/doc/refman/5.7/en/replication-options-binary-log.html。這里我們主要對以上配置示例中出現(xiàn)的參數(shù)進(jìn)行概要介紹：

sync_binlog：該參數(shù)可以設(shè)置為1到N的任何值。該參數(shù)表示MySQL服務(wù)在成功完成多少次不可分割的數(shù)據(jù)操作后（例如InnoDB引擎下的事務(wù)操作），才進(jìn)行一次二進(jìn)制日志文件的寫入操作。設(shè)置成1時(shí)，寫入日志文件的次數(shù)是最頻繁的，也會(huì)造成一定的I/O性能消耗，但同時(shí)這樣的設(shè)置值也是最安全的。

binlog_format：該參數(shù)可以有三種設(shè)置值：row、statement和mixed。row代表二進(jìn)制日志中記錄數(shù)據(jù)表每一行經(jīng)過寫操作后被修改的最終值。各個(gè)參與同步的Salve節(jié)點(diǎn)，也會(huì)參照這個(gè)最終值，將自己數(shù)據(jù)表上的數(shù)據(jù)進(jìn)行修改；statement形式是在日志中記錄數(shù)據(jù)操作過程，而非最終的執(zhí)行結(jié)果。各個(gè)參與同步的Salve節(jié)點(diǎn)會(huì)解析這個(gè)過程，并形成最終記錄；mixed設(shè)置值，是以上兩種記錄方式的混合體，MySQL服務(wù)會(huì)自動(dòng)選擇當(dāng)前運(yùn)行狀態(tài)下最適合的日志記錄方式。

binlog-do-db：該參數(shù)用于設(shè)置MySQL Master節(jié)點(diǎn)上需要進(jìn)行Replicaion操作的數(shù)據(jù)庫名稱。

binlog_checksum：該參數(shù)用于設(shè)置Master節(jié)點(diǎn)和Salve節(jié)點(diǎn)在進(jìn)行日志文件數(shù)據(jù)同步時(shí)，所使用的日志數(shù)據(jù)校驗(yàn)方式。這個(gè)參數(shù)是在version 5.6版本開始才支持的新配置功能，默認(rèn)值就是CRC32。如果MySQL集群中有MySQL 節(jié)點(diǎn)使用的是version 5.5或更早的版本，請?jiān)O(shè)置該參數(shù)的值為none。

binlog_cache_size：該參數(shù)設(shè)置Master節(jié)點(diǎn)上為每個(gè)客戶端連接會(huì)話（session）所使用的，在事務(wù)過程中臨時(shí)存儲(chǔ)日志數(shù)據(jù)的緩存大小。如果沒有使用支持事務(wù)的引擎，可以忽略這個(gè)值的設(shè)置。但是一般來說我們都會(huì)使用InnoDB引擎，所以該值最好設(shè)置成1M——2M，如果經(jīng)常會(huì)執(zhí)行較復(fù)雜的事務(wù)，則可以適當(dāng)加大為3M——4M。

max_binlog_cache_size：該值表示整個(gè)MySQL服務(wù)中，能夠使用的binlog_cache區(qū)域的最大值。該值不以session為單位，而是對全局進(jìn)行設(shè)置。

max_binlog_size ： 該參數(shù)設(shè)置單個(gè)binlog文件的最大大小。MySQL服務(wù)為了避免binlog日志出錯(cuò)或者Salve同步失敗，會(huì)在兩種情況下創(chuàng)建新的binlog文件：一種情況是MySQL服務(wù)重啟后，另一種情況是binlog文件的大小達(dá)到一個(gè)設(shè)定的閥值（默認(rèn)為1GB）。max_binlog_size參數(shù)就是設(shè)置這個(gè)閥值的。

完成my.cnf文件的更改后，重啟Linux MySql服務(wù)新的配置就生效了。接下來需要在Master節(jié)點(diǎn)中設(shè)置可供連接的Salve節(jié)點(diǎn)信息，包括進(jìn)行Replicaion同步的用戶和密碼信息：

# 只用MySQL客戶端，都可以進(jìn)行設(shè)置：# 這里我們直接使用root賬號進(jìn)行同步，但是生產(chǎn)環(huán)境下不建議這樣使用> grant replication slave on *.* to root@192.168.61.141 identified by ’123456’

# 通過以下命令，可以查看設(shè)置完成后的Master節(jié)點(diǎn)工作狀態(tài)

> show master status;

+----------------+----------+--------------+------------------+-------------------+

| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |

+----------------+----------+--------------+------------------+-------------------+

| kp2-bin.000002 | 404 | qiang | | |

+----------------+----------+--------------+------------------+-------------------+

以上master節(jié)點(diǎn)狀態(tài)的描述中，F(xiàn)ile屬性說明了當(dāng)前二進(jìn)制日志文件的名稱，它的默認(rèn)位置在Linux操作系統(tǒng)下的var/lib/mysql目錄下。Position屬性說明了當(dāng)前已完成日志同步的數(shù)據(jù)點(diǎn)在日志文件中的位置。Binlog_Do_DB屬性是我們之前設(shè)置的，需要進(jìn)行Replicaion操作的數(shù)據(jù)庫名稱，Binlog_Ignore_DB屬性就是明確忽略的，不需要進(jìn)行Replicaion操作的數(shù)據(jù)庫名稱。

2-2-2、設(shè)置Salve服務(wù)器

完成MySQL Master服務(wù)的配置后，我們來看看Salve節(jié)點(diǎn)該如何進(jìn)行設(shè)置。這里我們只演示一個(gè)Salve節(jié)點(diǎn)的設(shè)置，如果您還要在集群中增加新的Salve節(jié)點(diǎn)，那么配置過程都是類似的。無非是要注意在Master節(jié)點(diǎn)上增加新的Salve節(jié)點(diǎn)描述信息。

首先我們還是需要設(shè)置Salve節(jié)點(diǎn)的my.cnf文件：

# my.cnf文件中沒有涉及Replicaion機(jī)制的配置信息，就不在這里列出了......# 開啟日志log-bin

sync_relay_log=1

# 必須為這個(gè)MySQL服務(wù)節(jié)點(diǎn)設(shè)置一個(gè)集群中唯一的server id信息

server_id=140

......

在MySQL官方文檔中也詳細(xì)描述了中繼日志的各種控制參數(shù)，這里我們只使用了sync_relay_log參數(shù)。這個(gè)參數(shù)說明了Salve節(jié)點(diǎn)在成功接受到多少次Master同步日志信息后，才刷入中繼日志文件。這個(gè)參數(shù)可以設(shè)置為1到N的任意一個(gè)值，當(dāng)然設(shè)置為1的情況下雖然會(huì)消耗一些性能，但對于日志數(shù)據(jù)來說卻是最安全的。

Salve的設(shè)置相對簡單，接下來我們需要在Salve端開啟相應(yīng)的同步功能。主要是指定用于同步的Master服務(wù)地址、用戶和密碼信息：

# 請注意這里設(shè)置的用戶名和密碼信息要和Master上的設(shè)置一致# 另外master log file所指定的文件名也必須和Master上使用的日志文件名一致> change master to master_host=’192.168.61.140’,master_user=’root’,master_password=’123456’, master_log_file=’kp2-bin.000002’,master_log_pos=120;

# 啟動(dòng)Savle同步

> start slave;

# 然后我們就可以使用以下命令查看salve節(jié)點(diǎn)的同步狀態(tài)

> show slave status;

*************************** 1. row ***************************

Slave_IO_State: Waiting for master to send event

Master_Host: 192.168.61.140

Master_User: root

Master_Port: 3306

Connect_Retry: 60

Master_Log_File: kp2-bin.000002

Read_Master_Log_Pos: 404

Relay_Log_File: vm2-relay-bin.000002

Relay_Log_Pos: 565

Relay_Master_Log_File: kp2-bin.000002

Slave_IO_Running: Yes

Slave_SQL_Running: Yes

......

Master_Server_Id: 140

Master_UUID: 19632f72-9a90-11e6-82bd-000c290973df

Master_Info_File: /var/lib/mysql/master.info

SQL_Delay: 0

SQL_Remaining_Delay: NULL

Slave_SQL_Running_State: Slave has read all relay log;

waiting for the slave I/O thread to update it

Master_Retry_Count: 86400

......

Auto_Position: 0

完成以上過程，一主一從的MySQL集群就配置完成了。

2-3、一主多從方案的使用建議

一主多從的MySQL集群方案，已經(jīng)可以解決大部分系統(tǒng)結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)的性能要求。特別是那種數(shù)據(jù)查詢頻率/次數(shù)遠(yuǎn)遠(yuǎn)大于數(shù)據(jù)寫入頻率/次數(shù)的業(yè)務(wù)場景，例如電商系統(tǒng)的商品模塊、物流系統(tǒng)的車輛/司機(jī)信息模塊、電信CRM系統(tǒng)的客戶信息模塊、監(jiān)控系統(tǒng)中保存的基本日志數(shù)據(jù)。但是這種架構(gòu)方案并不能解決所有的問題，而且方案本身有一些明顯的問題（后文詳細(xì)討論），所以在這里本文需要為各位將要使用類似MySQL集群方案的讀者提供一些使用建議。

Master單節(jié)點(diǎn)性能應(yīng)該足夠強(qiáng)大，且只負(fù)責(zé)數(shù)據(jù)寫入操作：一主多從的MySQL集群方式主要針對讀密集型業(yè)務(wù)系統(tǒng)，其主要目標(biāo)是將MySQL服務(wù)的讀寫壓力進(jìn)行分離。所以Master節(jié)點(diǎn)需要集中精力處理業(yè)務(wù)的寫操作請求，這也就意味著業(yè)務(wù)系統(tǒng)所有的寫操作壓力都集中到了這一個(gè)節(jié)點(diǎn)上（write業(yè)務(wù)操作）。我們暫且不去分析這個(gè)現(xiàn)象可能導(dǎo)致的問題（后續(xù)內(nèi)容會(huì)提到這種做法的問題），但這至少要求Master節(jié)點(diǎn)的性能足夠強(qiáng)大。這里的性能不單單指通過MySQL InnoDB引擎提供的各種配置（一般我們使用InnoDB引擎），并結(jié)合業(yè)務(wù)特點(diǎn)所盡可能榨取的性能，最根本的還需要提升Master節(jié)點(diǎn)的硬件性能。

使用固態(tài)硬盤作為MySQL服務(wù)的塊存儲(chǔ)基礎(chǔ)，并使用RAID 10磁盤陣列作為硬件層構(gòu)建方案——這是生產(chǎn)環(huán)境下單個(gè)MySQL服務(wù)節(jié)點(diǎn)的基本組成邏輯，當(dāng)然讀者可以視自己生產(chǎn)環(huán)境下的的實(shí)際容量和性能要求進(jìn)行必要的調(diào)整：

應(yīng)使用一個(gè)獨(dú)立的Salve節(jié)點(diǎn)作為備用的Master節(jié)點(diǎn)，雖然這種方式不可作為異地多活方案的基礎(chǔ)但可作為本地高可用方案的實(shí)現(xiàn)基礎(chǔ)。當(dāng)然，為了防止由于日志錯(cuò)誤導(dǎo)致的備份失敗，這個(gè)備份的Salve節(jié)點(diǎn)也可以采用MySQL Replicaion機(jī)制以外的第三方同步機(jī)制，例如：Rsync、DRBD。Rsync是筆者在工作實(shí)踐中經(jīng)常使用的，進(jìn)行MySQL數(shù)據(jù)增量同步的方式，而DRBD的差異塊同步方式是互聯(lián)網(wǎng)上能夠找到最多資料的方式：

在后續(xù)的文章中，我們還會(huì)專門討論針對Master節(jié)點(diǎn)的集群調(diào)整方案，并且建議讀者如何使用適合系統(tǒng)自身業(yè)務(wù)的高可用方案。例如使用Keepalived / Heartbeat進(jìn)行主備Master節(jié)點(diǎn)的切換：

復(fù)雜的統(tǒng)計(jì)查詢需要專門的Salve節(jié)點(diǎn)進(jìn)行支持。參與生產(chǎn)環(huán)境實(shí)時(shí)業(yè)務(wù)處理的任何MySQL服務(wù)節(jié)點(diǎn)，在這些服務(wù)節(jié)點(diǎn)上所運(yùn)行的SQL查詢應(yīng)該盡可能簡單，并且需要使用索引對檢索進(jìn)行支持。特別是數(shù)據(jù)量非常大的數(shù)據(jù)表，必須保證所有的檢索操作都有索引提供支持，否則Table Full Scan的檢索過濾方式不但會(huì)拖慢檢索操作本身，還可能會(huì)明顯拖慢其它的事務(wù)操作。通過MySQL提供的執(zhí)行計(jì)劃功能，技術(shù)人員能夠很方便實(shí)現(xiàn)以上的要求。如果您的業(yè)務(wù)系統(tǒng)存在復(fù)雜的業(yè)務(wù)查詢要求，例如周期性的財(cái)務(wù)流水報(bào)表，周期性的業(yè)務(wù)分組統(tǒng)計(jì)報(bào)表等，那么您最好專門準(zhǔn)備一個(gè)（或多個(gè)）脫離實(shí)時(shí)業(yè)務(wù)的Salve節(jié)點(diǎn)，完成這個(gè)工作。

但是這種MySQL集群方案也存在很多問題需要進(jìn)一步改進(jìn)。在后續(xù)的文章中，我們會(huì)依次討論MySQL集群中還存在的以下問題：

面向上層系統(tǒng)的問題：在MySQL一主多從集群中，存在過個(gè)服務(wù)節(jié)點(diǎn)。那么當(dāng)上層業(yè)務(wù)系統(tǒng)進(jìn)行數(shù)據(jù)庫操作時(shí)（無論是寫操作還是讀操作），是否需要明確知道這些具體的服務(wù)節(jié)點(diǎn)，并進(jìn)行連接呢？要知道，當(dāng)上層業(yè)務(wù)系統(tǒng)需要控制的要素變得原來越多時(shí)，需要業(yè)務(wù)系統(tǒng)開發(fā)人員投入的維護(hù)精力就會(huì)呈幾何級增長。

高可用層面的問題：在MySQL一主多從集群中，雖然存在多個(gè)Salve節(jié)點(diǎn)（read業(yè)務(wù)性質(zhì)節(jié)點(diǎn)），但是一般只存在一個(gè)Master節(jié)點(diǎn)（write業(yè)務(wù)性質(zhì)節(jié)點(diǎn)）。某一個(gè)（或多個(gè)）Salve節(jié)點(diǎn)崩潰了，不會(huì)對整個(gè)集群造成太大影響（但可能影響上層業(yè)務(wù)系統(tǒng)的某一個(gè)子系統(tǒng)）。那么MySQL集群的短板在于只有一個(gè)Master節(jié)點(diǎn)——一旦它崩潰了，整個(gè)集群就基本上無法正常工作。所以我們必須想一些辦法改變這個(gè)潛在風(fēng)險(xiǎn)。

來自：http://www.uml.org.cn/sjjm/201611072.asp