MySQL數(shù)據(jù)庫的主從復(fù)制方案，和使用scp/rsync等命令進(jìn)行的文件級別復(fù)制類似，都是數(shù)據(jù)的遠(yuǎn)程傳輸，只不過MySQL的主從復(fù)制是其自帶的功能，無需借助第三方工具，而且，MySQL的主從復(fù)制并不是數(shù)據(jù)庫磁盤上的文件直接拷貝，而是通過邏輯的binlog日志復(fù)制到要同步的服務(wù)器本地，然后由本地的線程讀取日志里面的SQL語句重新應(yīng)用到MySQL數(shù)據(jù)庫中。

1.1.1 MySQL主從復(fù)制介紹

MySQL數(shù)據(jù)庫支持單向、雙向、鏈?zhǔn)郊壜?lián)、環(huán)狀等不同業(yè)務(wù)場景的復(fù)制。在復(fù)制過程中，一臺服務(wù)器充當(dāng)主服務(wù)器（Master），接收來自用戶的內(nèi)容更新，而一個或多個其他的服務(wù)器充當(dāng)從服務(wù)器（Slave），接收來自主服務(wù)器binlog文件的日志內(nèi)容，解析出SQL重新更新到從服務(wù)器，使得主從服務(wù)器數(shù)據(jù)達(dá)到一致。

如果設(shè)置了鏈?zhǔn)郊壜?lián)復(fù)制，那么，從（slave）服務(wù)器本身除了充當(dāng)從服務(wù)器外，也會同時充當(dāng)其下面從服務(wù)器的主服務(wù)器。鏈?zhǔn)郊墢?fù)制類似A→B→C的復(fù)制形式。

1.1.2 MySQL主從復(fù)制的企業(yè)應(yīng)用場景

MySQL主從復(fù)制集群功能使得MySQL數(shù)據(jù)庫支持大規(guī)模高并發(fā)讀寫稱為可能，同時有效地保護(hù)了物理服務(wù)器宕機(jī)場景的數(shù)據(jù)備份。

應(yīng)用場景1：從服務(wù)器作為主服務(wù)器的實時數(shù)據(jù)備份

主從服務(wù)器架構(gòu)的設(shè)置，可以大大加強(qiáng)MySQL數(shù)據(jù)庫架構(gòu)的健壯性。例如：當(dāng)主服務(wù)器出現(xiàn)問題時，我們可以人工或設(shè)置自動切換到從服務(wù)器繼續(xù)提供服務(wù)，此時從服務(wù)器的數(shù)據(jù)和宕機(jī)時的主數(shù)據(jù)庫幾乎是一致的。

這類似NFS存儲數(shù)據(jù)通過inotify+rsync同步到備份的NFS服務(wù)器，只不過MySQL的復(fù)制方案是其自帶的工具。

利用MySQL的復(fù)制功能做備份時，在硬件故障、軟件故障的場景下，該數(shù)據(jù)備份是有效的，但對于人為地執(zhí)行drop、delete等語句刪除數(shù)據(jù)的情況，從庫的備份功能就沒有用了，因為從服務(wù)器也會執(zhí)行刪除的語句。

應(yīng)用場景2：主從服務(wù)器實時讀寫分離，從服務(wù)器實現(xiàn)負(fù)載均衡

主從服務(wù)器架構(gòu)可通過程序（PHP、Java等）或代理軟件（mysql-proxy、Amoeba）實現(xiàn)對用戶（客戶端）的請求讀寫分離，即讓從服務(wù)器僅僅處理用戶的select查詢請求，降低用戶查詢響應(yīng)時間及讀寫同時在主服務(wù)器上帶來的訪問壓力。對于更新的數(shù)據(jù)（例如update、insert、delete語句）仍然交給主服務(wù)器處理，確保主服務(wù)器和從服務(wù)器保持實時同步。

應(yīng)用場景3：把多個從服務(wù)器根據(jù)業(yè)務(wù)重要性進(jìn)行拆分訪問

可以把幾個不同的從服務(wù)器，根據(jù)公司的業(yè)務(wù)進(jìn)行拆分。例如：有為外部用戶提供查詢服務(wù)的從服務(wù)器，有內(nèi)部DBA用來數(shù)據(jù)備份的從服務(wù)器，還有為公司內(nèi)部人員提供訪問的后臺、腳本、日志分析及供開發(fā)人員查詢使用的從服務(wù)器。這樣的拆分除了減輕主服務(wù)器的壓力外，還可以使數(shù)據(jù)庫對外部用戶瀏覽、內(nèi)部用戶業(yè)務(wù)處理及DBA人員的備份等互不影響。具體可以用下圖說明：

2.1 實現(xiàn)MySQL主從讀寫分離的方案

（1）通過程序?qū)崿F(xiàn)讀寫分離（性能和效率***，推薦）

PHP和Java程序都可以通過設(shè)置多個連接文件輕松地實現(xiàn)對數(shù)據(jù)庫的讀寫分離，即當(dāng)語句關(guān)鍵字為select時，就去連接讀庫的連接文件，若為update、insert、delete時，則連接寫庫的連接文件。

通過程序?qū)崿F(xiàn)讀寫分離的缺點(diǎn)就是需要開發(fā)人員對程序進(jìn)行改造，使其對下層透明，但這種方式更容易開發(fā)和實現(xiàn)，適合互聯(lián)網(wǎng)業(yè)務(wù)場景。

（2）通過開源軟件實現(xiàn)讀寫分離

MySQL-proxy、Amoda、Mycat、Altas等代理軟件也可以實現(xiàn)讀寫分離功能，這些軟件的穩(wěn)定性和功能一般，不建議生產(chǎn)使用。絕大多數(shù)公司常用的還是應(yīng)用端開發(fā)程序?qū)崿F(xiàn)讀寫分離。

（3）大型門戶獨(dú)立開發(fā)DAL層綜合軟件

百度、阿里等大型門戶都有開發(fā)牛人，會花大力氣開發(fā)適合自己業(yè)務(wù)的讀寫分離、負(fù)載均衡、監(jiān)控報警、自動擴(kuò)容，自動收縮等一系列功能的DAL層軟件。

3.1 MySQL主從復(fù)制原理介紹

MySQL的主從復(fù)制是一個異步的復(fù)制過程（雖然一般情況下感覺是實時的），數(shù)據(jù)將將從一個MySQL數(shù)據(jù)庫（我們稱之為Master）復(fù)制到另一個MySQL數(shù)據(jù)庫（我們稱之為Slave），在Master于Slave之間實現(xiàn)整個主從復(fù)制的過程是由三個線程參與完成的。其中有兩個線程（SQL和IO線程）在Slave端，另外一個線程（I/O線程）在Master端。

要實現(xiàn)MySQL的主從復(fù)制，首先必須打開Master端的Binlog記錄功能，否則就無法實現(xiàn)。因為整個復(fù)制過程實際上就是Slave從Master端獲取BInlog日志，然后再在Slave上以相同順序執(zhí)行獲取的binlog日志中記錄的各種SQL操作。

要打開MySQL的BInlog記錄功能，可通過在MySQL的配置文件my.cnf中的mysqld模塊增加“log-bin”參數(shù)選項來實現(xiàn)，具體信息如下：

 

[mysqld]  
log-bin 

 

3.2 MySQL主從復(fù)制原理過程詳細(xì)描述

下面簡單描述下MySQL Replication的復(fù)制原理過程。

1）在Slave服務(wù)器上執(zhí)行start slave命令開啟主從復(fù)制開關(guān)，主從復(fù)制開始進(jìn)行。

2）此時，Slave服務(wù)器的I/O線程會通過在Master上己經(jīng)授權(quán)的復(fù)制用戶權(quán)限請求連接Master服務(wù)器，并請求從指定Binlog日志文件的指定位罝（日志文件名和位置就是在配罝主從復(fù)制服務(wù)時執(zhí)行change master命令指定的）之后開始發(fā)送Binlog日志內(nèi)容。

3）Master服務(wù)器接收到來自Slave服務(wù)器的I/O線程的請求后，其上負(fù)責(zé)復(fù)制的I/O線程會根據(jù)Slave服務(wù)器的I/O線程請求的信息分批讀取指定Binlog日志文件指定位置之后的Binlog日志信息，然后返回給Slave端的I/O線程。返回的信息中除了Binlog日志內(nèi)容外，還有在Master服務(wù)器端記錄的新的Binlog文件名稱以及在新的Binlog中的下一個 指定更新位置。

4）當(dāng)Slave服務(wù)器的I/O線程獲取到Master服務(wù)器上I/O線程發(fā)送的日志內(nèi)容及日志文件及位置點(diǎn)后，會將Binlog日志內(nèi)容依次寫入到Slave端自身的Relay Log（即中繼日志） 文件(MySQL-relay-bin.xxxxxx)的最末端，并將新的Binlog文件名和位置記錄到master-info文件中，以便下一次讀取Master端新Binlog日志時能夠告訴Master服務(wù)器需要從新Binlog 日志的指定文件及位置開始請求新的Binlog日志內(nèi)容。

5）Slave服務(wù)器端的SQL線程會實時地檢測本地Relay Log中I/O線程新增加的日志內(nèi)容，然后及時地把Relay Log文件中的內(nèi)容解析成SQL語句，并在自身Slave服務(wù)器上按解析SQL語句的位置順序執(zhí)行應(yīng)用這些SQL語句，并記錄當(dāng)前應(yīng)用中繼日志的文件名及位置點(diǎn)在relay-log.info中。

經(jīng)過了上面的過程，就可以確保在Master端和Slave端執(zhí)行了同樣的SQL語句。當(dāng)復(fù)制狀態(tài)正常的情況下，Master端和Slave端的數(shù)據(jù)是完全一樣的。當(dāng)然，MySQL的復(fù)制機(jī)制也有一些特殊情況，具體請參考官方的說明，大多數(shù)情況下，大家不用擔(dān)心。

下面針對MySQL主從復(fù)制原理的重點(diǎn)小結(jié)

• 主從復(fù)制是異步的邏輯的SQL語句級的復(fù)制

• 復(fù)制時，主庫有一個I/O線程，從庫有兩個線程，I/O和SQL線程。

• 作為復(fù)制的所有MySQL節(jié)點(diǎn)的server-id都不能相同。

• binlog文件只記錄對數(shù)據(jù)庫有更改的SQL語句（來自數(shù)據(jù)庫內(nèi)容的變更），不記錄任何查詢（select，slow）語句。

5.6 SQL多線程寫入

GTID（不用找位置點(diǎn)了）

3.3主從復(fù)制實踐

1、準(zhǔn)備

主庫log_bin

主從server-id不同

2、主庫準(zhǔn)備

mysql -S /data/3306/mysql.sock  
grant replication slave on *.* to 'rep'@'172.16.1.%' identified by 'oldboy123';  
flush privileges; 

3、把數(shù)據(jù)從主庫搞到從庫。

復(fù)制前 讓從和主一致。

mysql -S /data/3306/mysql.sock  
mysql> flush table with read lock; 不能關(guān)窗口  
mysql> show master status;  
+-------------------+----------+  
| File | Position |  
+-------------------+----------+  
| oldboy-bin.000002 | 405 | 

單開窗口

mysqldump -A -B --master-data=2 -S /data/3306/mysql.sock|gzip >/opt/3306.sql.gz 

原窗口

mysql> unlock table; 

從庫恢復(fù)：

gzip -d /opt/3306.sql.gz  
mysql -uroot -poldboy123 -S /data/3307/mysql.sock </opt/3306.sql 

5、指定主機(jī)、用戶、位置點(diǎn)同步

mysql> CHANGE MASTER TO  
MASTER_HOST='172.16.1.51',  
MASTER_PORT=3306,  
MASTER_USER='rep',  
MASTER_PASSWORD='oldboy123',  
MASTER_LOG_FILE='mysql-bin.000001',  
MASTER_LOG_POS=405;  
#查看MASTER_LOG_FILE 使用sed -n 22p /opt/3306.sql#查看主庫  
#從庫 

6、開啟同步開關(guān)，檢查是否同步。

mysql> start slave;  
mysql> show slave statusG  
Slave_IO_Running: Yes  
Slave_SQL_Running: Yes  
Seconds_Behind_Master: 0 

從庫配置信息說明

mysql> CHANGE MASTER TO  
MASTER_HOST='172.16.1.51', #這里是主庫的ip  
MASTER_PORT=3306, #這里是主庫的端口，從庫的端口可以和主庫不同  
MASTER_USER='rep', #這里是主庫上建立的用于復(fù)制的用戶rpo  
MASTER_PASSWORD='oldboy123', ##這里是rep用戶的密碼  
MASTER_LOG_FILE='mysql-bin.000001', ###這里是show master status時查看到的二進(jìn)制日志文件名稱，注意不能多空格  
MASTER_LOG_POS=405; ##這里是show master status時查看到的二進(jìn)制日志文件偏移量，注意不能多空格