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

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

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

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

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

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

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

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

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

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

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é)點上的二進制日志功能（注意這里說的日志并不是InnoDB引擎日志）。

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

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

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

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

server_id=140

......

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

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

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

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

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

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

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

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

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

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

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

> show master status;

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

| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |

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

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

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

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

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

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

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

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

sync_relay_log=1

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

server_id=140

......

在MySQL官方文檔中也詳細描述了中繼日志的各種控制參數(shù)，這里我們只使用了sync_relay_log參數(shù)。這個參數(shù)說明了Salve節(jié)點在成功接受到多少次Master同步日志信息后，才刷入中繼日志文件。這個參數(shù)可以設(shè)置為1到N的任意一個值，當然設(shè)置為1的情況下雖然會消耗一些性能，但對于日志數(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;

# 啟動Savle同步

> start slave;

# 然后我們就可以使用以下命令查看salve節(jié)點的同步狀態(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ù)存儲的性能要求。特別是那種數(shù)據(jù)查詢頻率/次數(shù)遠遠大于數(shù)據(jù)寫入頻率/次數(shù)的業(yè)務(wù)場景，例如電商系統(tǒng)的商品模塊、物流系統(tǒng)的車輛/司機信息模塊、電信CRM系統(tǒng)的客戶信息模塊、監(jiān)控系統(tǒng)中保存的基本日志數(shù)據(jù)。但是這種架構(gòu)方案并不能解決所有的問題，而且方案本身有一些明顯的問題（后文詳細討論），所以在這里本文需要為各位將要使用類似MySQL集群方案的讀者提供一些使用建議。

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

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

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

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

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

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

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

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

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