MySQL主從復(fù)制的常見拓?fù)?、原理分析以及如何提高效?/h1>
一、主從復(fù)制搭建方法參考
MySQL5.6 數(shù)據(jù)庫(kù)主從（Master/Slave）同步安裝與配置詳解
二、Mysql 主從復(fù)制的常用拓?fù)浣Y(jié)構(gòu)
2.1、一主一從
是最基礎(chǔ)的復(fù)制結(jié)構(gòu)，用來(lái)分擔(dān)之前單臺(tái)數(shù)據(jù)庫(kù)服務(wù)器的壓力，可以進(jìn)行讀寫分離。
2.2、一主多從
一臺(tái) Slave 承受不住讀請(qǐng)求壓力時(shí)，可以添加多臺(tái)，進(jìn)行負(fù)載均衡，分散讀壓力。
還可以對(duì)多臺(tái) Slave 進(jìn)行分工，服務(wù)于不同的系統(tǒng)，例如一部分 Slave 負(fù)責(zé)網(wǎng)站前臺(tái)的讀請(qǐng)求，另一部分 Slave 負(fù)責(zé)后臺(tái)統(tǒng)計(jì)系統(tǒng)的請(qǐng)求。
因?yàn)椴煌到y(tǒng)的查詢需求不同，對(duì) Slave 分工后，可以創(chuàng)建不同的索引，使其更好的服務(wù)于目標(biāo)系統(tǒng)。
2.3、雙主復(fù)制
Master 存在下線的可能，例如故障或者維護(hù)，需要把 Slave 切換為 Master。
在原來(lái)的 Master 恢復(fù)可用后，由于其數(shù)據(jù)已經(jīng)不是最新的了，不能再做主，需要做為 Slave 添加進(jìn)來(lái)。
那么就需要對(duì)其重新搭建復(fù)制環(huán)境，需要耗費(fèi)一定的工作量。
雙主結(jié)構(gòu)就是用來(lái)解決這個(gè)問(wèn)題的，互相將對(duì)方作為自己的 Master，自己作為對(duì)方的 Slave 來(lái)進(jìn)行復(fù)制，但對(duì)外來(lái)講，還是一個(gè)主和一個(gè)從。
當(dāng) 主Master 下線時(shí)，備Master 切換為 主Master，當(dāng)原來(lái)的 主Master 上線后，因?yàn)樗涗浟俗约寒?dāng)前復(fù)制到對(duì)方的什么位置了，就會(huì)自動(dòng)從之前的位置開始重新復(fù)制，不需要人為地干預(yù)，大大提升了效率。
2.4、級(jí)聯(lián)復(fù)制
當(dāng)直接從屬于 Master 的 Slave 過(guò)多時(shí)，連到 Master 的 Slave IO 線程就比較多，對(duì) Master 的壓力是很大的。
級(jí)聯(lián)結(jié)構(gòu)就是通過(guò)減少直接從屬于 Master 的 Slave 數(shù)量，減輕 Master 的壓力，分散復(fù)制請(qǐng)求，從而提高整體的復(fù)制效率。
2.5、雙主級(jí)聯(lián)
級(jí)聯(lián)復(fù)制結(jié)構(gòu)解決了 Slave 過(guò)多導(dǎo)致的瓶頸問(wèn)題，但還是有單主結(jié)構(gòu)中切換主時(shí)的維護(hù)問(wèn)題。
那么為了解決這個(gè)問(wèn)題，就可以加入上面的雙主結(jié)構(gòu)。
在必要時(shí)，可以再對(duì) Slaves 進(jìn)行分級(jí)。
Mysql 的復(fù)制結(jié)構(gòu)有很多種方式，復(fù)制的最大問(wèn)題是數(shù)據(jù)延時(shí)，選擇復(fù)制結(jié)構(gòu)時(shí)需要根據(jù)自己的具體情況，并評(píng)估好目標(biāo)結(jié)構(gòu)的延時(shí)對(duì)系統(tǒng)的影響。
三、Mysql 主從復(fù)制過(guò)程及原理
3.1、Binary Log 簡(jiǎn)單介紹
因?yàn)锽inlog dump 線程操作的文件是bin-log 日志文件，并且實(shí)現(xiàn)主從復(fù)制在主服務(wù)器上主要依靠bin-log日志文件，所以我們簡(jiǎn)單介紹一下bin-log日志文件。
3.2、原理
MySQL的Replication（英文為復(fù)制）是一個(gè)多MySQL數(shù)據(jù)庫(kù)做主從同步的方案，特點(diǎn)是異步復(fù)制，廣泛用在各種對(duì)MySQL有更高性能、更高可靠性要求的場(chǎng)合。與之對(duì)應(yīng)的是另一個(gè)同步技術(shù)是MySQL Cluster，但因?yàn)镸ySQL Cluster配置比較復(fù)雜，所以使用者較少。
MySQL Replication 就是從服務(wù)器拉取主服務(wù)器上的 二進(jìn)制日志文件，然后再將日志文件解析成相應(yīng)的SQL語(yǔ)句在從服務(wù)器上重新執(zhí)行一遍主服務(wù)器的操作，通過(guò)這種方式來(lái)保證數(shù)據(jù)的一致性。
MySQL的Replication是一個(gè)異步復(fù)制的過(guò)程（mysql5.1.7以上版本分為異步復(fù)制和半同步兩種模式），它是從一個(gè)Mysql instance（instance英文為實(shí)例）(我們稱之為Master)復(fù)制到另一個(gè)Mysql instance(我們稱之slave)。
3.3、三個(gè)線程
在master與slave之間實(shí)現(xiàn)整個(gè)復(fù)制過(guò)程主要由三個(gè)線程來(lái)完成：
1、Slave SQL thread線程，在slave端
2、Slave I/O thread線程，在slave端
3、Binlog dump thread線程(也可稱為IO線程)，在master端
注意：如果一臺(tái)主服務(wù)器配兩臺(tái)從服務(wù)器那主服務(wù)器上就會(huì)有兩個(gè)Binlog dump 線程，而每個(gè)從服務(wù)器上各自有兩個(gè)線程。
要實(shí)現(xiàn)MySQL的Replication，首先必須打開master端的binlog (mysql-bin.xxxxxx)日志功能，否則無(wú)法實(shí)現(xiàn)mysql的主從復(fù)制。因?yàn)閙ysql的整個(gè)主從復(fù)制過(guò)程實(shí)際上就是：slave端從master端獲取binlog日志，然后再在自己身上完全順序的執(zhí)行該日志中所記錄的各種SQL操作。有關(guān)具體如何開啟mysql的binlog日志功能，請(qǐng)大家自己在網(wǎng)上搜。
3.4、主從復(fù)制流程
MySQL主從復(fù)制的基本交互過(guò)程，如下：
1、slave端的IO線程連接上master端，并請(qǐng)求從指定binlog日志文件的指定pos節(jié)點(diǎn)位置(或者從最開始的日志)開始復(fù)制之后的日志內(nèi)容。
2、master端在接收到來(lái)自slave端的IO線程請(qǐng)求后，通知負(fù)責(zé)復(fù)制進(jìn)程的IO線程，根據(jù)slave端IO線程的請(qǐng)求信息，讀取指定binlog日志指定pos節(jié)點(diǎn)位置之后的日志信息，然后返回給slave端的IO線程。該返回信息中除了binlog日志所包含的信息之外，還包括本次返回的信息在master端的binlog文件名以及在該binlog日志中的pos節(jié)點(diǎn)位置。
3、slave端的IO線程在接收到master端IO返回的信息后，將接收到的binlog日志內(nèi)容依次寫入到slave端的relaylog文件(mysql-relay-bin.xxxxxx)的最末端，并將讀取到的master端的binlog文件名和pos節(jié)點(diǎn)位置記錄到master-info（該文件存slave端）文件中，以便在下一次讀取的時(shí)候能夠清楚的告訴master“我需要從哪個(gè)binlog文件的哪個(gè)pos節(jié)點(diǎn)位置開始，請(qǐng)把此節(jié)點(diǎn)以后的日志內(nèi)容發(fā)給我”。
4、slave端的SQL線程在檢測(cè)到relaylog文件中新增內(nèi)容后，會(huì)馬上解析該log文件中的內(nèi)容。然后還原成在master端真實(shí)執(zhí)行的那些SQL語(yǔ)句，并在自身按順豐依次執(zhí)行這些SQL語(yǔ)句。這樣，實(shí)際上就是在master端和slave端執(zhí)行了同樣的SQL語(yǔ)句，所以master端和slave端的數(shù)據(jù)完全一樣的。
以上mysql主從復(fù)制交互過(guò)程比較拗口，理解起來(lái)也比較麻煩，我簡(jiǎn)化了該交互過(guò)程。如下：
1、master在執(zhí)行sql之后，記錄二進(jìn)制log文件（bin-log）。
2、slave連接master，并從master獲取binlog，存于本地relay-log中，然后從上次記住的位置起執(zhí)行SQL語(yǔ)句，一旦遇到錯(cuò)誤則停止同步。
從以上mysql的Replication原理可以看出：
主從間的數(shù)據(jù)庫(kù)不是實(shí)時(shí)同步，就算網(wǎng)絡(luò)連接正常，也存在瞬間主從數(shù)據(jù)不一致的情況。
如果主從的網(wǎng)絡(luò)斷開，則從庫(kù)會(huì)在網(wǎng)絡(luò)恢復(fù)正常后，批量進(jìn)行同步。
如果對(duì)從庫(kù)進(jìn)行修改數(shù)據(jù)，那么如果此時(shí)從庫(kù)正在在執(zhí)行主庫(kù)的bin-log時(shí)，則會(huì)出現(xiàn)錯(cuò)誤而停止同步，這個(gè)是很危險(xiǎn)的操作。所以一般情況下，我們要非常小心的修改從庫(kù)上的數(shù)據(jù)。
一個(gè)衍生的配置是雙主、互為主從配置，只要雙方的修改不沖突，則可以工作良好。
如果需要多主庫(kù)的話，可以用環(huán)形配置，這樣任意一個(gè)節(jié)點(diǎn)的修改都可以同步到所有節(jié)點(diǎn)。
3.5、整體過(guò)程就是：
MySQL 復(fù)制基于主服務(wù)器在二進(jìn)制日志中跟蹤所有對(duì)數(shù)據(jù)庫(kù)的更改(更新、刪除等等)。每個(gè)從服務(wù)器從主服務(wù)器接收主服務(wù)器已經(jīng)記錄到其二進(jìn)制日志的保存的更新，以便從服務(wù)器可以對(duì)其數(shù)據(jù)拷貝執(zhí)行相同的更新。
將主服務(wù)器的數(shù)據(jù)拷貝到從服務(wù)器的一個(gè)途徑是使用LOAD DATA FROM MASTER語(yǔ)句。請(qǐng)注意LOAD DATA FROM MASTER目前只在所有表使用MyISAM存儲(chǔ)引擎的主服務(wù)器上工作。并且，該語(yǔ)句將獲得全局讀鎖定。
MySQL 使用3個(gè)線程來(lái)執(zhí)行復(fù)制功能,其中1個(gè)在主服務(wù)器上，另兩個(gè)在從服務(wù)器上。當(dāng)發(fā)出START SLAVE時(shí)，從服務(wù)器創(chuàng)建一個(gè)I/O線程，以連接主服務(wù)器并讓它發(fā)送記錄在其二進(jìn)制日志中的語(yǔ)句。
主服務(wù)器創(chuàng)建一個(gè)線程，即I/O線程，將二進(jìn)制日志中的內(nèi)容發(fā)送到從服務(wù)器。該線程可以識(shí)別為主服務(wù)器上SHOW PROCESSLIST的輸出中的Binlog Dump線程。
從服務(wù)器I/O線程讀取主服務(wù)器Binlog Dump線程發(fā)送的內(nèi)容并將該數(shù)據(jù)拷貝到從服務(wù)器數(shù)據(jù)目錄中的本地文件中，即中繼日志。
第3個(gè)線程是SQL線程，是從服務(wù)器創(chuàng)建用于讀取中繼日志并執(zhí)行日志中包含的更新。
有多個(gè)從服務(wù)器的主服務(wù)器創(chuàng)建為每個(gè)當(dāng)前連接的從服務(wù)器創(chuàng)建一個(gè)線程；每個(gè)從服務(wù)器有自己的I/O和SQL線程。
四、MySQL支持的復(fù)制類型及其優(yōu)缺點(diǎn)
bin-log 日志文件有兩種格式，一種是Statement-Based，另一種是Row-Based。
（１）：基于語(yǔ)句的復(fù)制（Statement-Based）： 在主服務(wù)器上執(zhí)行的SQL語(yǔ)句，在從服務(wù)器上執(zhí)行同樣的語(yǔ)句。MySQL默認(rèn)采用基于語(yǔ)句的復(fù)制，效率比較高。 一旦發(fā)現(xiàn)沒法精確復(fù)制時(shí)，會(huì)自動(dòng)選著基于行的復(fù)制。
（２）：基于行的復(fù)制（Row-Based）：把改變的內(nèi)容復(fù)制過(guò)去，而不是把命令在從服務(wù)器上執(zhí)行一遍. 從mysql5.0開始支持
（３）：混合類型的復(fù)制: 默認(rèn)采用基于語(yǔ)句的復(fù)制，一旦發(fā)現(xiàn)基于語(yǔ)句的無(wú)法精確的復(fù)制時(shí)，就會(huì)采用基于行的復(fù)制。
4.1、Statement-Based優(yōu)點(diǎn)和缺點(diǎn)分析
優(yōu)點(diǎn)
- bin-log日志包含了描述數(shù)據(jù)庫(kù)操作的事件，但是這些事件包含的情況只是對(duì)數(shù)據(jù)庫(kù)進(jìn)行改變的操作，例如 insert、update、create、delete等操作。相反對(duì)于select、desc等類似的操作并不會(huì)去記錄，并且它記錄的是語(yǔ)句，所以相對(duì)于Row-Based來(lái)說(shuō)這樣會(huì)占用更少的存儲(chǔ)空間。
- 因?yàn)閎in-log日志文件記錄了所有的改變數(shù)據(jù)庫(kù)的語(yǔ)句，所以此文件可以作為以后的數(shù)據(jù)庫(kù)的審核依據(jù)
缺點(diǎn)
- 不安全，并不是所有的改變數(shù)據(jù)的語(yǔ)句都會(huì)被記錄復(fù)制。任何的非確定性的行為都是很難被記錄復(fù)制的。
- 例如：對(duì)于delete 或者update語(yǔ)句，如果使用了limit但是并沒有 order by ，這就屬于非確定性的語(yǔ)句，就不會(huì)被記錄
- 對(duì)于沒有索引條件的update語(yǔ)句，必須鎖定更多的數(shù)據(jù)，降低了數(shù)據(jù)庫(kù)的性能。
- insert……select 語(yǔ)句同樣也需要鎖定大量的數(shù)據(jù)，對(duì)數(shù)據(jù)庫(kù)的性能有所損耗。
- 獲取更詳細(xì)的信息可以參考官方文檔——Statement-Based的優(yōu)點(diǎn)和缺點(diǎn)。
4.2、Row-Based優(yōu)點(diǎn)和缺點(diǎn)分析
優(yōu)點(diǎn)
- 所有的改變都會(huì)被復(fù)制，這是最安全的復(fù)制方式
- 對(duì)于 update、insert……select等語(yǔ)句鎖定更少的行
- 此種方式和大多數(shù)的數(shù)據(jù)庫(kù)系統(tǒng)一樣，所以了解其他的系統(tǒng)的人員可以很容易的轉(zhuǎn)到mysql
缺點(diǎn)
- 使用不方便，我們不能通過(guò)bin-log日志文件查看什么語(yǔ)句執(zhí)行了，也無(wú)從知道在從服務(wù)器上接收到什么語(yǔ)句，我們只能看到什么數(shù)據(jù)改變了
- 因?yàn)橛涗浀氖菙?shù)據(jù)，所以說(shuō)bin-log日志文件占用的存儲(chǔ)空間要比Statement-based大。
- 對(duì)于數(shù)據(jù)量大的操作其花費(fèi)的時(shí)間有更長(zhǎng)
獲取更詳細(xì)的信息可以參考官方文檔——Row-Based的優(yōu)點(diǎn)和缺點(diǎn)
bin-log日志文件默認(rèn)的格式為Statement-Based，如果想改變其格式在開啟服務(wù)的時(shí)候使用—binlog-format選項(xiàng)，其具體命令如下
mysqld_safe –user=msyql –binlog-format=格式 &
四、主服務(wù)器流程分析
4.1、主服務(wù)器線程 Binlog dump thread
Binlog dump 線程是當(dāng)有從服務(wù)器連接的時(shí)候由主服務(wù)器創(chuàng)建，其大致工作過(guò)程經(jīng)歷如下幾個(gè)階段：
首先bin-log日志文件加鎖，然后讀取更新的操作，讀取完畢以后將鎖釋放掉，最后將讀取的記錄發(fā)送給從服務(wù)器。
我們可以使用如下的命令來(lái)查看該線程的信息
- mysql> SHOW PROCESSLIST\G
以我的系統(tǒng)為例，因?yàn)槲疫@系統(tǒng)中是一臺(tái)主服務(wù)器和兩臺(tái)從服務(wù)器，所以會(huì)列出兩條Binlog dump線程的信息
- *************************** 1. row ***************************
- Id: 2
- User: repuser
- Host: 192.168.144.131:41544
- db: NULL
- Command: Binlog Dump
- Time: 54
- State: Master has sent all binlog to slave; waiting for binlog to be updated
- Info: NULL
- *************************** 2. row ***************************
- Id: 3
- User: repuser
- Host: 192.168.144.132:40888
- db: NULL
- Command: Binlog Dump
- Time: 31
- State: Master has sent all binlog to slave; waiting for binlog to be updated
- Info: NULL
上述字段中的state字段會(huì)有以下幾種狀態(tài)：
1. Sending binlog event to slave
表示Binlog dump 線程已經(jīng)讀取完binlog日志中更新的event，現(xiàn)在正在發(fā)送給從服務(wù)器
2. Finished reading one binlog; switching to next binlog
表示Binlog dump 線程已經(jīng)讀取完一個(gè)binlog日志，現(xiàn)在正在打開下一個(gè)binlog日志讀取來(lái)發(fā)送給從服務(wù)器
3. Master has sent all binlog to slave; waiting for binlog to be updated
這就是上面我們看到的state的值，表示Binlog dump 線程已經(jīng)讀取完所有的binlog日志文件，并且將其發(fā)送給了從服務(wù)器?，F(xiàn)在處于空閑狀態(tài)，正在等待讀取有新的操作的binlog日志文件
4. Waiting to finalize termination
這個(gè)狀態(tài)持續(xù)的很短暫，我們幾乎看不到。當(dāng)線程停止的時(shí)候顯示此狀態(tài)。
上述幾個(gè)狀態(tài)就是一次主從復(fù)制過(guò)程中Binlog dump 線程所經(jīng)歷的狀態(tài)，如果我們是在測(cè)試的環(huán)境中，上述1、2、4狀態(tài)我們幾乎是看不到的，因?yàn)樗鼒?zhí)行的很快。
在主從系統(tǒng)中主服務(wù)器上的一個(gè)主要的文件就是bin-log日志，該線程操作的文件也是此日志文件，因此這是我們需要在配置文件my.cnf 中打開bin-log日志的原因，使用此文件來(lái)記錄我們的更新操作。
- [mysqld]
- log-bin = mysql-bin
- server-id = 1
還有一點(diǎn)需要注意，在上面已經(jīng)說(shuō)過(guò)，但是在這里覺得有必要再重復(fù)一遍，就是有多少個(gè)從服務(wù)器連接主服務(wù)器上就有多少個(gè)Binlog dump 線程。
bin-log日志文件管理
對(duì)于bin-log日志文件，其默認(rèn)的名稱為 mysql-bin.xxxxxx。而且還有一個(gè)索引文件mysql-bin.index，其中記錄了當(dāng)前所有的bin-log日志文件。
對(duì)于新的主服務(wù)器只有一個(gè)bin-log日志文件 mysql-bin.000001。此時(shí)所有的操作都有這個(gè)文件來(lái)記錄，如果我們想更換bin-log日志文件，可以使用如下命令
- Mysql>flush logs;
此時(shí)會(huì)創(chuàng)建一個(gè)mysql-bin.000002文件來(lái)記錄以后的操作。除了使用上述命令以外，當(dāng)bin-log日志文件達(dá)到其最大值的時(shí)候也會(huì)產(chǎn)生新的bin-log日志文件
其文件最大值和文件名包括索引文件的名稱可以使用 –max_binlog_size、–log-bin和—log-bin-index 選項(xiàng)來(lái)改變，具體命令如下
mysqld_safe –user=msyql –max_binlog_size=文件長(zhǎng)度 –log-bin=新的日志文件名稱 –log-bin-index=新索引文件名 &
對(duì)于主服務(wù)器來(lái)說(shuō)，總起來(lái)一句話：主服務(wù)器針對(duì)于每一個(gè)從服務(wù)器都創(chuàng)建一個(gè)Binlog dump線程，用來(lái)讀取bin-log日志中更新的操作將其發(fā)送給從服務(wù)器，發(fā)送完畢以后繼續(xù)等待bin-log日志是否有更新。
五、從服務(wù)器流程分析
在主服務(wù)器探究這篇文章中我們提到過(guò)，在一次主從復(fù)制過(guò)程中需要用到三個(gè)線程：Binlog dump 線程、Slave I/O 線程和Slave SQL線程，其中Binlog dump 線程在主服務(wù)器上面，剩下的兩個(gè)線程是在從服務(wù)器上面工作的。
這兩個(gè)線程在從服務(wù)器上面的工作流程如下圖所示：
對(duì)于這兩個(gè)線程隨著從服務(wù)器開啟slave而產(chǎn)生
- mysql> START SLVAE;
使用
- Mysql> SHOW SLAVE STATUS\G
查看這兩個(gè)線程情況
- ……
- Master_Log_File: mysql-bin.000003
- Read_Master_Log_Pos: 1264
- Relay_Log_File: localhost-relay-bin.000002
- Relay_Log_Pos: 878
- Relay_Master_Log_File: mysql-bin.000003
- Slave_IO_Running: Yes
- Slave_SQL_Running: Yes
- ……
上面結(jié)果中的 Slave_IO_Running:Yes和Slave_SQL_Running:Yes表示這兩個(gè)線程正在運(yùn)行。
然后我們?cè)趶姆?wù)器上面使用命令
- mysql> SHOW PROCESSLIAT\G
顯示如下結(jié)果（記為 結(jié)果一）
- *************************** 1. row ***************************
- Id: 22
- User: system user
- Host:
- db: NULL
- Command: Connect
- Time: 4
- State: Waiting for master to send event
- Info: NULL
- *************************** 2. row ***************************
- Id: 23
- User: system user
- Host:
- db: NULL
- Command: Connect
- Time: 4
- State: Slave has read all relay log; waiting for the slave I/O thread to update it
- Info: NULL
從State信息可以看出Id 22是I/O線程，正在等待主服務(wù)器發(fā)送更新的內(nèi)容；Id 23是Slave SQL線程，已經(jīng)讀取了relay log 文件中所有更新的內(nèi)容，正在等待I/O線程更新該文件。
使用命令停止slave機(jī)制
- mysql> STOP SLVAE;
然后我們?cè)俅尾榭磿?huì)發(fā)現(xiàn)結(jié)果如下
- ……
- Master_Log_File: mysql-bin.000003
- Read_Master_Log_Pos: 1264
- Relay_Log_File: localhost-relay-bin.000002
- Relay_Log_Pos: 878
- Relay_Master_Log_File: mysql-bin.000003
- Slave_IO_Running: No
- Slave_SQL_Running: No
- ……
說(shuō)明這兩個(gè)線程已經(jīng)停止了運(yùn)行。此時(shí)再次使用 SHOW PROCESSLIST\G命令，則沒有結(jié)果顯示
5.1、Slave I/O線程
Slave I/O 線程去連接主服務(wù)器的Binlog dump 線程并要求其發(fā)送binlog日志中記錄的更新的操作，然后它將Binlog dump 線程發(fā)送的數(shù)據(jù)拷貝到從服務(wù)器上（也就是本地）的文件relay log中。
當(dāng)然要查看此線程是否運(yùn)行，除了上面介紹的方法，還可以使用
- mysql> SHOW SLAVE LIKE ‘Slave_running’;
這時(shí)如果出現(xiàn)下面的結(jié)果說(shuō)明該線程正在運(yùn)行
- +-----------------+-------------------+
- | Variable_name | Value |
- +-----------------+-------------------+
- | Slave_running | ON |
- +-----------------+-------------------+
在上述結(jié)果一中我們可以看到1.row即是Slave I/O線程的信息，其State: Waiting for master to send event 表示正在等待主服務(wù)器發(fā)送內(nèi)容。當(dāng)然State不止這一個(gè)值，它還有其它的值，下面列出了State的所有的值
1. Waiting for master update
在連接到主服務(wù)器之前的初始狀態(tài)
2. Connecting to master
該線程正在連接主服務(wù)器，當(dāng)然如果我們的網(wǎng)絡(luò)環(huán)境優(yōu)異的話，此狀態(tài)我們幾乎是看不到的
3. Checking master version
這個(gè)狀態(tài)發(fā)生的時(shí)間也非常短暫，該狀態(tài)在該線程和主服務(wù)器建立連接之后發(fā)生。
4. Registering slave on master
在主服務(wù)器上面注冊(cè)從服務(wù)器，每當(dāng)有新的從服務(wù)器連接進(jìn)來(lái)以后都要在主服務(wù)器上面進(jìn)行注冊(cè)
5. Requesting binlog dump
向主服務(wù)器請(qǐng)求binlog日志的拷貝
6. Waiting to reconnect after a failed binlog dump request
如果5中失敗，則該線程進(jìn)入睡眠狀態(tài)，此時(shí)State就是這個(gè)值，等待著去定期重新連接主服務(wù)器，那這個(gè)周期的大小可以通過(guò)CHANGE MASTER TO 來(lái)指定
7. Reconnecting after a failed binlog dump request
去重新連接主服務(wù)器
8. Waiting for master to send event
此值就是我們上述結(jié)果所顯示的，正常情況下我們查看的時(shí)候一般都是這個(gè)值。其具體表示是這個(gè)線程已經(jīng)和主服務(wù)器建立了連接，正在等待主服務(wù)器上的binlog 有更新，如果主服務(wù)器的Binlog dump線程一直是空閑的狀態(tài)的話，那此線程會(huì)等待很長(zhǎng)一段時(shí)間。當(dāng)然也不是一直等待下去，如果時(shí)間達(dá)到了slave_net_timeout規(guī)定的時(shí)間，會(huì)發(fā)生等待超時(shí)的情況，在這種情況下I/O線程會(huì)重新去連接主服務(wù)器
9. Queueing master event to the relay log
該線程已經(jīng)讀取了Binlog dump線程發(fā)送的一個(gè)更新事件并且正在將其拷貝到relay log文件中
10. Waiting to reconnect after a failed master event read
當(dāng)該線程讀取Binlog dump 線程發(fā)送的更新事件失敗時(shí)，該線程進(jìn)入睡眠狀態(tài)等待去重新連接主服務(wù)器，這個(gè)等待的時(shí)間默認(rèn)是60秒，當(dāng)然這個(gè)值也可以通過(guò)CHANGE MASTER TO來(lái)設(shè)置
11. Reconnecting after a failed master event read
該線程去重新連接主服務(wù)器，當(dāng)連接成功以后，那這個(gè)State的值會(huì)改變?yōu)?Waiting for master to send event
12. Waiting for the Slave SQL thread to free enough relay log space
relay log space的大小是通過(guò)relay_log_space_limit來(lái)設(shè)定的，隨著relay logs變得越來(lái)越大所有的大小合起來(lái)會(huì)超過(guò)這個(gè)設(shè)定值。這時(shí)該線程會(huì)等待SQL線程釋放足夠的空間刪除一些relay log文件
13. Waiting for slave mutex on exit
當(dāng)線程停止的時(shí)候會(huì)短暫的出現(xiàn)該情況
以上就是State可能會(huì)出現(xiàn)的值，以及都是在什么情況下出現(xiàn)。
5.2、Slave SQL線程
Slave SQL線程是在從服務(wù)器上面創(chuàng)建的，主要負(fù)責(zé)讀取由Slave I/O寫的relay log文件并執(zhí)行其中的事件。
在上述結(jié)果一中2.row即是Slave SQL線程的信息，同樣有一個(gè)State表示該線程的當(dāng)前狀態(tài)。
下面也列出了State所有可能出現(xiàn)的情況。
1. Waiting for the next event in relay log
該狀態(tài)是讀取relay log之前的初始狀態(tài)
2. Reading event from the relay log
該狀態(tài)表示此線程已經(jīng)在relay log中讀取了一個(gè)事件準(zhǔn)備執(zhí)行
3. Making temp file
該狀態(tài)表示此線程正在執(zhí)行LOAD_DATA_INFILE并且正在創(chuàng)建一個(gè)臨時(shí)文件來(lái)保存從服務(wù)器將要讀取的數(shù)據(jù)
4. Slave has read all relay log; waiting for the slave I/O thread to update it
該線程已經(jīng)處理完了relay log中的所有事件，現(xiàn)在正在等待slave I/O線程更新relay log文件
5. Waiting for slave mutex on exit
當(dāng)線程停止的時(shí)候會(huì)短暫的出現(xiàn)該情況
上面是對(duì)從服務(wù)器上的兩個(gè)線程的簡(jiǎn)單的介紹，在運(yùn)行過(guò)程中我們會(huì)發(fā)現(xiàn)這兩個(gè)線程都離不開的文件就是relay log文件，下面我們簡(jiǎn)單介紹一下relay log文件。
5.3、relay log文件
relay log 和 主服務(wù)器上的bin log很相似，都是一系列的文件，這些文件包括那些包含描述數(shù)據(jù)庫(kù)改變的操作事件的文件和索引文件，這個(gè)索引文件是relay logs文件的名稱集合。
relay log 文件和 bin log文件一樣，也是二進(jìn)制文件，不能直接查看，需要使用mysql自帶工具mysqlbinlog查看。
] # mysqlbinlog mysql安裝路徑/data/relay-log文件
當(dāng)然其索引文件的內(nèi)容我們是可以直接使用 vim查看的。
對(duì)于relay logs 文件的名稱的命名規(guī)則默認(rèn)使用的是 host_name-relay-bin.nnnnnn，以我的系統(tǒng)來(lái)說(shuō)，其文件名默認(rèn)為localhost-relay-bin.000001。對(duì)于索引文件的命名規(guī)則為host_name-relay-bin.index，同樣在我的系統(tǒng)中的名稱為localhost-relay-bin.index。這兩個(gè)名稱是可以通過(guò)—relay-log 和 –relay-log-index來(lái)改變的，其使用方式如下：
mysqld_safe –user=mysql –relay-log=文件名 –relay-log-index=新索引文件名 &
在這里如果改變這兩個(gè)名稱的話，可能會(huì)引起‘不能打開relay log’文件和‘在初始化relay log 過(guò)程中不能發(fā)現(xiàn)目標(biāo)log’等錯(cuò)誤。這也算是mysql設(shè)計(jì)的一個(gè)bug，沒有什么好的解決辦法，如果我們不想使用默認(rèn)的文件名稱的話，唯一的辦法就是我們可以預(yù)料到從服務(wù)器的主機(jī)名稱可能在將來(lái)會(huì)發(fā)生改變，在開始初始化從服務(wù)器的時(shí)候就使用以上兩個(gè)選項(xiàng)指定文件名，這樣就可以使文件名不再依賴于服務(wù)器的主機(jī)名。
對(duì)于這些relay log文件并不是一直在增加的，當(dāng)Slave SQL線程執(zhí)行完一個(gè)relay log文件中所有的事件并且不再需要它的時(shí)候會(huì)把改relay log文件刪除。由于是Slave SQL線程來(lái)做這些事情，所以也沒有什么明確的規(guī)則來(lái)指定如何刪除relay log文件
以上的所有內(nèi)容大概描述了主從復(fù)制系統(tǒng)中從服務(wù)器的主要工作流程。
六、如何提高M(jìn)ysql主從復(fù)制的效率？
MySQL的主從復(fù)制，實(shí)際上就是Master記錄自己的執(zhí)行日志binlog，然后發(fā)送給Slave，Slave解析日志并執(zhí)行，來(lái)實(shí)現(xiàn)數(shù)據(jù)復(fù)制。對(duì)于復(fù)制效率，binlog的大小是非常重要的因素，因?yàn)樗婕傲薎/O和網(wǎng)絡(luò)傳輸
主從復(fù)制涉及到了兩端：master/slave，看下這兩端可以如何優(yōu)化
（1）master 端
master端有2個(gè)參數(shù)可以控制
Binlog_Do_DB : 設(shè)定哪些數(shù)據(jù)庫(kù)需要記錄Binlog
Binlog_Ignore_DB : 設(shè)定哪些數(shù)據(jù)庫(kù)不要記錄Binlog
這兩項(xiàng)很重要，指定必要數(shù)據(jù)庫(kù)，忽略不需要復(fù)制的數(shù)據(jù)庫(kù)，可以減少binlog的大小，提高了I/O效率，加快網(wǎng)絡(luò)傳輸。
但這兩項(xiàng)也同樣比較危險(xiǎn)，需要謹(jǐn)慎使用，因?yàn)榭赡軙?huì)有主從數(shù)據(jù)不一致和復(fù)制出錯(cuò)的風(fēng)險(xiǎn)。
因?yàn)镸ySQL判斷是否須要復(fù)制某個(gè)Event，不是根據(jù)產(chǎn)生該Event的語(yǔ)句所在的數(shù)據(jù)庫(kù)，而是根據(jù)執(zhí)行時(shí)所在的默認(rèn)數(shù)據(jù)庫(kù)，也就是登錄時(shí)指定的數(shù)據(jù)庫(kù)，或運(yùn)行“USE DATABASE”中所指定的數(shù)據(jù)庫(kù)。
如果執(zhí)行語(yǔ)句中明確指定了數(shù)據(jù)庫(kù)名稱，而這個(gè)數(shù)據(jù)庫(kù)是被指定不記錄Binlog的，那么這個(gè)語(yǔ)句在slave中執(zhí)行時(shí)就會(huì)出錯(cuò)。
例如
garbage 庫(kù)是被指定不記錄日志的
product 庫(kù)是指定要記錄日志的
執(zhí)行下面的語(yǔ)句
use product;
delete from garbage.junk;
delete語(yǔ)句會(huì)被發(fā)送給slave，但slave中沒有g(shù)arbage庫(kù)，所以執(zhí)行時(shí)報(bào)錯(cuò)，復(fù)制失敗
（2）slave 端
slave端有6個(gè)參數(shù)可以控制
Replicate_Do_DB : 設(shè)定須要復(fù)制的數(shù)據(jù)庫(kù)，多個(gè)DB用逗號(hào)分隔
Replicate_Ignore_DB : 設(shè)定可以忽略的數(shù)據(jù)庫(kù)
Replicate_Do_Table : 設(shè)定須要復(fù)制的Table
Replicate_Ignore_Table : 設(shè)定可以忽略的Table
Replicate_Wild_Do_Table : 功能同Replicate_Do_Table，但可以帶通配符來(lái)進(jìn)行設(shè)置
Replicate_Wild_Ignore_Table : 功能同Replicate_Ig-nore_Table，可帶通配符設(shè)置
slave端的配置優(yōu)化效果要明顯小于master端的，因?yàn)閙aster端日志都寫完了，日志也傳過(guò)來(lái)了
但這幾個(gè)參數(shù)可以幫助我們減少日志的應(yīng)用量，因?yàn)樵O(shè)置了過(guò)濾，實(shí)際寫入的sql數(shù)量變少了，slave端的復(fù)制也就加快了。
