參考：
https://blog.csdn.net/hguisu/article/details/7325124
https://www.cnblogs.com/xihuineng/p/10438969.html
https://blog.csdn.net/keil_wang/article/details/88669587
https://zhuanlan.zhihu.com/p/50597960
https://blog.csdn.net/hangxing_2015/article/details/52585855
高性能Mysql主從架構的復制原理及配置詳解
溫習《高性能MySQL》的復制篇.
1 復制概述
Mysql內建的復制功能是構建大型，高性能應用程序的基礎。將Mysql的數據分布到多個系統上去，這種分布的機制，是通過將Mysql的某一台主機的數據復制到其它主機（slaves）上，並重新執行一遍來實現的。復制過程中一個服務器充當主服務器，而一個或多個其它服務器充當從服務器。主服務器將更新寫入二進制日志文件，並維護文件的一個索引以跟蹤日志循環。這些日志可以記錄發送到從服務器的更新。當一個從服務器連接主服務器時，它通知主服務器從服務器在日志中讀取的最后一次成功更新的位置。從服務器接收從那時起發生的任何更新，然后封鎖並等待主服務器通知新的更新。
請注意當你進行復制時，所有對復制中的表的更新必須在主服務器上進行。否則，你必須要小心，以避免用戶對主服務器上的表進行的更新與對從服務器上的表所進行的更新之間的沖突。
1.1 mysql支持的復制類型：
（１）：基於語句的復制： 在主服務器上執行的SQL語句，在從服務器上執行同樣的語句。MySQL默認采用基於語句的復制，效率比較高。
一旦發現沒法精確復制時， 會自動選着基於行的復制。
（２）：基於行的復制：把改變的內容復制過去，而不是把命令在從服務器上執行一遍. 從mysql5.0開始支持
（３）：混合類型的復制: 默認采用基於語句的復制，一旦發現基於語句的無法精確的復制時，就會采用基於行的復制。
1.2 . 復制解決的問題
MySQL復制技術有以下一些特點：
(1) 數據分布 (Data distribution )
(2) 負載平衡(load balancing)
(3) 備份(Backups)
(4) 高可用性和容錯行 High availability and failover
1.3 復制如何工作
整體上來說，復制有3個步驟：
(1) master將改變記錄到二進制日志(binary log)中（這些記錄叫做二進制日志事件，binary log events）；
(2) slave將master的binary log events拷貝到它的中繼日志(relay log)；
(3) slave重做中繼日志中的事件，將改變反映它自己的數據。
下圖描述了復制的過程：
該過程的第一部分就是master記錄二進制日志。在每個事務更新數據完成之前，master在二日志記錄這些改變。MySQL將事務串行的寫入二進制日志，即使事務中的語句都是交叉執行的。在事件寫入二進制日志完成后，master通知存儲引擎提交事務。
下一步就是slave將master的binary log拷貝到它自己的中繼日志。首先，slave開始一個工作線程——I/O線程。I/O線程在master上打開一個普通的連接，然后開始binlog dump process。Binlog dump process從master的二進制日志中讀取事件，如果已經跟上master，它會睡眠並等待master產生新的事件。I/O線程將這些事件寫入中繼日志。
SQL slave thread（SQL從線程）處理該過程的最后一步。SQL線程從中繼日志讀取事件，並重放其中的事件而更新slave的數據，使其與master中的數據一致。只要該線程與I/O線程保持一致，中繼日志通常會位於OS的緩存中，所以中繼日志的開銷很小。
此外，在master中也有一個工作線程：和其它MySQL的連接一樣，slave在master中打開一個連接也會使得master開始一個線程。復制過程有一個很重要的限制——復制在slave上是串行化的，也就是說master上的並行更新操作不能在slave上並行操作。
2 .主從復制配置
有兩台MySQL數據庫服務器Master和slave，Master為主服務器，slave為從服務器，初始狀態時，Master和slave中的數據信息相同，當Master中的數據發生變化時，slave也跟着發生相應的變化，使得master和slave的數據信息同步，達到備份的目的。
要點：
負責在主、從服務器傳輸各種修改動作的媒介是主服務器的二進制變更日志，這個日志記載着需要傳輸給從服務器的各種修改動作。因此，主服務器必須激活二進制日志功能。從服務器必須具備足以讓它連接主服務器並請求主服務器把二進制變更日志傳輸給它的權限。
環境：
Master和slave的MySQL數據庫版本同為5.0.18
IP地址：10.100.0.100
2.1、創建復制帳號
1、在Master的數據庫中建立一個備份帳戶：每個slave使用標准的MySQL用戶名和密碼連接master。進行復制操作的用戶會授予REPLICATION SLAVE權限。用戶名的密碼都會存儲在文本文件master.info中
命令如下：
mysql > GRANT REPLICATION SLAVE,RELOAD,SUPER ON *.*
TO backup@’10.100.0.200’
IDENTIFIED BY ‘1234’;
建立一個帳戶backup，並且只能允許從10.100.0.200這個地址上來登陸，密碼是1234。
(如果因為mysql版本新舊密碼算法不同，可以設置：set password for 'backup'@'10.100.0.200'=old_password('1234')）
2.2、拷貝數據
（假如是你完全新安裝mysql主從服務器，這個一步就不需要。因為新安裝的master和slave有相同的數據）
關停Master服務器，將Master中的數據拷貝到B服務器中，使得Master和slave中的數據同步，並且確保在全部設置操作結束前，禁止在Master和slave服務器中進行寫操作，使得兩數據庫中的數據一定要相同！
2.3、配置master
接下來對master進行配置，包括打開二進制日志，指定唯一的servr ID。例如，在配置文件加入如下值：
server-id=1
log-bin=mysql-bin
server-id：為主服務器A的ID值
log-bin：二進制變更日值
重啟master，運行SHOW MASTER STATUS，輸出如下：
2.4、配置slave
Slave的配置與master類似，你同樣需要重啟slave的MySQL。如下：
log_bin = mysql-bin
server_id = 2
relay_log = mysql-relay-bin
log_slave_updates = 1
read_only = 1
server_id：是必須的，而且唯一。
log_bin：slave沒有必要開啟二進制日志bin_log，但是在一些情況下，必須設置，例如，如果slave為其它slave的master，必須設置bin_log。在這里，我們開啟了二進制日志，而且顯示的命名(默認名稱為hostname，但是，如果hostname改變則會出現問題)。
relay_log：配置中繼日志，log_slave_updates表示slave將復制事件寫進自己的二進制日志(后面會看到它的用處)。
有些人開啟了slave的二進制日志，卻沒有設置log_slave_updates，然后查看slave的數據是否改變，這是一種錯誤的配置。
read_only：盡量使用read_only，它防止改變數據(除了特殊的線程)。但是，read_only並是很實用，特別是那些需要在slave上創建表的應用。
2.5、啟動slave
接下來就是讓slave連接master，並開始重做master二進制日志中的事件。你不應該用配置文件進行該操作，而應該使用CHANGE MASTER TO語句，該語句可以完全取代對配置文件的修改，而且它可以為slave指定不同的master，而不需要停止服務器。如下：
mysql> CHANGE MASTER TO MASTER_HOST='server1',
-> MASTER_USER='repl',
-> MASTER_PASSWORD='p4ssword',
-> MASTER_LOG_FILE='mysql-bin.000001',
-> MASTER_LOG_POS=0;
MASTER_LOG_POS的值為0，因為它是日志的開始位置。
你可以用SHOW SLAVE STATUS語句查看slave的設置是否正確：
mysql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
Slave_IO_State:
Master_Host: server1
Master_User: repl
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000001
Read_Master_Log_Pos: 4
Relay_Log_File: mysql-relay-bin.000001
Relay_Log_Pos: 4
Relay_Master_Log_File: mysql-bin.000001
Slave_IO_Running: No
Slave_SQL_Running: No
...omitted...
Seconds_Behind_Master: NULL
Slave_IO_State, Slave_IO_Running, 和Slave_SQL_Running是No
表明slave還沒有開始復制過程。日志的位置為4而不是0，這是因為0只是日志文件的開始位置，並不是日志位置。實際上，MySQL知道的第一個事件的位置是4。
為了開始復制，你可以運行：
mysql> START SLAVE;
運行SHOW SLAVE STATUS查看輸出結果：
mysql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: server1
Master_User: repl
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000001
Read_Master_Log_Pos: 164
Relay_Log_File: mysql-relay-bin.000001
Relay_Log_Pos: 164
Relay_Master_Log_File: mysql-bin.000001
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
...omitted...
Seconds_Behind_Master: 0
在這里主要是看:
Slave_IO_Running=Yes
Slave_SQL_Running=Yes
slave的I/O和SQL線程都已經開始運行，而且Seconds_Behind_Master不再是NULL。日志的位置增加了，意味着一些事件被獲取並執行了。如果你在master上進行修改，你可以在slave上看到各種日志文件的位置的變化，同樣，你也可以看到數據庫中數據的變化。
你可查看master和slave上線程的狀態。在master上，你可以看到slave的I/O線程創建的連接：
在master上輸入show processlist\G;
| mysql> show processlist \G *************************** 1. row *************************** Id: 1 User: root Host: localhost:2096 db: test Command: Query Time: 0 State: NULL Info: show processlist *************************** 2. row *************************** Id: 2 User: repl Host: localhost:2144 db: NULL Command: Binlog Dump Time: 1838 State: Has sent all binlog to slave; waiting for binlog to be updated Info: NULL 2 rows in set (0.00 sec) |
行2為處理slave的I/O線程的連接。
在slave服務器上運行該語句：
| mysql> show processlist \G *************************** 1. row *************************** Id: 1 User: system user Host: db: NULL Command: Connect Time: 2291 State: Waiting for master to send event Info: NULL *************************** 2. row *************************** Id: 2 User: system user Host: db: NULL Command: Connect Time: 1852 State: Has read all relay log; waiting for the slave I/O thread to update it Info: NULL *************************** 3. row *************************** Id: 5 User: root Host: localhost:2152 db: test Command: Query Time: 0 State: NULL Info: show processlist 3 rows in set (0.00 sec) |
行1為I/O線程狀態，行2為SQL線程狀態。
2.5、添加新slave服務器
假如master已經運行很久了，想對新安裝的slave進行數據同步，甚至它沒有master的數據。
此時，有幾種方法可以使slave從另一個服務開始，例如，從master拷貝數據，從另一個slave克隆，從最近的備份開始一個slave。Slave與master同步時，需要三樣東西：
(1)master的某個時刻的數據快照；
(2)master當前的日志文件、以及生成快照時的字節偏移。這兩個值可以叫做日志文件坐標(log file coordinate)，因為它們確定了一個二進制日志的位置，你可以用SHOW MASTER STATUS命令找到日志文件的坐標；
(3)master的二進制日志文件。
可以通過以下幾中方法來克隆一個slave：
(1) 冷拷貝(cold copy)
停止master，將master的文件拷貝到slave；然后重啟master。缺點很明顯。
(2) 熱拷貝(warm copy)
如果你僅使用MyISAM表，你可以使用mysqlhotcopy拷貝，即使服務器正在運行。
(3) 使用mysqldump
使用mysqldump來得到一個數據快照可分為以下幾步：
<1>鎖表：如果你還沒有鎖表，你應該對表加鎖，防止其它連接修改數據庫，否則，你得到的數據可以是不一致的。如下：
mysql> FLUSH TABLES WITH READ LOCK;
<2>在另一個連接用mysqldump創建一個你想進行復制的數據庫的轉儲：
shell> mysqldump --all-databases --lock-all-tables >dbdump.db
<3>對表釋放鎖。
mysql> UNLOCK TABLES;
3、深入了解復制
已經討論了關於復制的一些基本東西，下面深入討論一下復制。
3.1、基於語句的復制(Statement-Based Replication)
MySQL 5.0及之前的版本僅支持基於語句的復制（也叫做邏輯復制，logical replication），這在數據庫並不常見。master記錄下改變數據的查詢，然后，slave從中繼日志中讀取事件，並執行它，這些SQL語句與master執行的語句一樣。
這種方式的優點就是實現簡單。此外，基於語句的復制的二進制日志可以很好的進行壓縮，而且日志的數據量也較小，占用帶寬少——例如，一個更新GB的數據的查詢僅需要幾十個字節的二進制日志。而mysqlbinlog對於基於語句的日志處理十分方便。
但是，基於語句的復制並不是像它看起來那么簡單，因為一些查詢語句依賴於master的特定條件，例如，master與slave可能有不同的時間。所以，MySQL的二進制日志的格式不僅僅是查詢語句，還包括一些元數據信息，例如，當前的時間戳。即使如此，還是有一些語句，比如，CURRENT USER函數，不能正確的進行復制。此外，存儲過程和觸發器也是一個問題。
另外一個問題就是基於語句的復制必須是串行化的。這要求大量特殊的代碼，配置，例如InnoDB的next-key鎖等。並不是所有的存儲引擎都支持基於語句的復制。
3.2、基於記錄的復制(Row-Based Replication)
MySQL增加基於記錄的復制，在二進制日志中記錄下實際數據的改變，這與其它一些DBMS的實現方式類似。這種方式有優點，也有缺點。優點就是可以對任何語句都能正確工作，一些語句的效率更高。主要的缺點就是二進制日志可能會很大，而且不直觀，所以，你不能使用mysqlbinlog來查看二進制日志。
對於一些語句，基於記錄的復制能夠更有效的工作，如：
mysql> INSERT INTO summary_table(col1, col2, sum_col3)
-> SELECT col1, col2, sum(col3)
-> FROM enormous_table
-> GROUP BY col1, col2;
假設，只有三種唯一的col1和col2的組合，但是，該查詢會掃描原表的許多行，卻僅返回三條記錄。此時，基於記錄的復制效率更高。
另一方面，下面的語句，基於語句的復制更有效：
mysql> UPDATE enormous_table SET col1 = 0;
此時使用基於記錄的復制代價會非常高。由於兩種方式不能對所有情況都能很好的處理，所以，MySQL 5.1支持在基於語句的復制和基於記錄的復制之前動態交換。你可以通過設置session變量binlog_format來進行控制。
3.3、復制相關的文件
除了二進制日志和中繼日志文件外，還有其它一些與復制相關的文件。如下：
(1)mysql-bin.index
服務器一旦開啟二進制日志，會產生一個與二日志文件同名，但是以.index結尾的文件。它用於跟蹤磁盤上存在哪些二進制日志文件。MySQL用它來定位二進制日志文件。它的內容如下(我的機器上)：
(2)mysql-relay-bin.index
該文件的功能與mysql-bin.index類似，但是它是針對中繼日志，而不是二進制日志。內容如下：
.\mysql-02-relay-bin.000017
.\mysql-02-relay-bin.000018
(3)master.info
保存master的相關信息。不要刪除它，否則，slave重啟后不能連接master。內容如下(我的機器上)：
I/O線程更新master.info文件，內容如下(我的機器上)：
| .\mysql-02-relay-bin.000019 254 mysql-01-bin.000010 286 0 52813 |
(4)relay-log.info
包含slave中當前二進制日志和中繼日志的信息。
3.4、發送復制事件到其它slave
當設置log_slave_updates時，你可以讓slave扮演其它slave的master。此時，slave把SQL線程執行的事件寫進行自己的二進制日志(binary log)，然后，它的slave可以獲取這些事件並執行它。如下：
3.5、復制過濾(Replication Filters)
復制過濾可以讓你只復制服務器中的一部分數據，有兩種復制過濾：在master上過濾二進制日志中的事件；在slave上過濾中繼日志中的事件。如下：
4、復制的常用拓撲結構
復制的體系結構有以下一些基本原則：
(1) 每個slave只能有一個master；
(2) 每個slave只能有一個唯一的服務器ID；
(3) 每個master可以有很多slave；
(4) 如果你設置log_slave_updates，slave可以是其它slave的master，從而擴散master的更新。
MySQL不支持多主服務器復制(Multimaster Replication)——即一個slave可以有多個master。但是，通過一些簡單的組合，我們卻可以建立靈活而強大的復制體系結構。
4.1、單一master和多slave
由一個master和一個slave組成復制系統是最簡單的情況。Slave之間並不相互通信，只能與master進行通信。
在實際應用場景中，MySQL復制90%以上都是一個Master復制到一個或者多個Slave的架構模式，主要用於讀壓力比較大的應用的數據庫端廉價擴展解決方案。因為只要Master和Slave的壓力不是太大（尤其是Slave端壓力）的話，異步復制的延時一般都很少很少。尤其是自從Slave端的復制方式改成兩個線程處理之后，更是減小了Slave端的延時問題。而帶來的效益是，對於數據實時性要求不是特別Critical的應用，只需要通過廉價的pcserver來擴展Slave的數量，將讀壓力分散到多台Slave的機器上面，即可通過分散單台數據庫服務器的讀壓力來解決數據庫端的讀性能瓶頸，畢竟在大多數數據庫應用系統中的讀壓力還是要比寫壓力大很多。這在很大程度上解決了目前很多中小型網站的數據庫壓力瓶頸問題，甚至有些大型網站也在使用類似方案解決數據庫瓶頸。
如下：
如果寫操作較少，而讀操作很時，可以采取這種結構。你可以將讀操作分布到其它的slave，從而減小master的壓力。但是，當slave增加到一定數量時，slave對master的負載以及網絡帶寬都會成為一個嚴重的問題。
這種結構雖然簡單，但是，它卻非常靈活，足夠滿足大多數應用需求。一些建議：
(1) 不同的slave扮演不同的作用(例如使用不同的索引，或者不同的存儲引擎)；
(2) 用一個slave作為備用master，只進行復制；
(3) 用一個遠程的slave，用於災難恢復；
大家應該都比較清楚，從一個Master節點可以復制出多個Slave節點，可能有人會想，那一個Slave節點是否可以從多個Master節點上面進行復制呢？至少在目前來看，MySQL是做不到的，以后是否會支持就不清楚了。
MySQL不支持一個Slave節點從多個Master節點來進行復制的架構，主要是為了避免沖突的問題，防止多個數據源之間的數據出現沖突，而造成最后數據的不一致性。不過聽說已經有人開發了相關的patch，讓MySQL支持一個Slave節點從多個Master結點作為數據源來進行復制，這也正是MySQL開源的性質所帶來的好處。
4.2、主動模式的Master-Master(Master-Master in Active-Active Mode)
Master-Master復制的兩台服務器，既是master，又是另一台服務器的slave。這樣，任何一方所做的變更，都會通過復制應用到另外一方的數據庫中。
可能有些讀者朋友會有一個擔心，這樣搭建復制環境之后，難道不會造成兩台MySQL之間的循環復制么？實際上MySQL自己早就想到了這一點，所以在MySQL的BinaryLog中記錄了當前MySQL的server-id，而且這個參數也是我們搭建MySQLReplication的時候必須明確指定，而且Master和Slave的server-id參數值比需要不一致才能使MySQLReplication搭建成功。一旦有了server-id的值之后，MySQL就很容易判斷某個變更是從哪一個MySQLServer最初產生的，所以就很容易避免出現循環復制的情況。而且，如果我們不打開記錄Slave的BinaryLog的選項（--log-slave-update）的時候，MySQL根本就不會記錄復制過程中的變更到BinaryLog中，就更不用擔心可能會出現循環復制的情形了。
如圖：
主動的Master-Master復制有一些特殊的用處。例如，地理上分布的兩個部分都需要自己的可寫的數據副本。這種結構最大的問題就是更新沖突。假設一個表只有一行(一列)的數據，其值為1，如果兩個服務器分別同時執行如下語句：
在第一個服務器上執行：
mysql> UPDATE tbl SET col=col + 1;
在第二個服務器上執行：
mysql> UPDATE tbl SET col=col * 2;
那么結果是多少呢？一台服務器是4，另一個服務器是3，但是，這並不會產生錯誤。
實際上，MySQL並不支持其它一些DBMS支持的多主服務器復制(Multimaster Replication)，這是MySQL的復制功能很大的一個限制(多主服務器的難點在於解決更新沖突)，但是，如果你實在有這種需求，你可以采用MySQL Cluster，以及將Cluster和Replication結合起來，可以建立強大的高性能的數據庫平台。但是，可以通過其它一些方式來模擬這種多主服務器的復制。
4.3、主動-被動模式的Master-Master(Master-Master in Active-Passive Mode)
這是master-master結構變化而來的，它避免了M-M的缺點，實際上，這是一種具有容錯和高可用性的系統。它的不同點在於其中一個服務只能進行只讀操作。如圖：
4.4 級聯復制架構 Master –Slaves - Slaves
在有些應用場景中，可能讀寫壓力差別比較大，讀壓力特別的大，一個Master可能需要上10台甚至更多的Slave才能夠支撐注讀的壓力。這時候，Master就會比較吃力了，因為僅僅連上來的SlaveIO線程就比較多了，這樣寫的壓力稍微大一點的時候，Master端因為復制就會消耗較多的資源，很容易造成復制的延時。
遇到這種情況如何解決呢？這時候我們就可以利用MySQL可以在Slave端記錄復制所產生變更的BinaryLog信息的功能，也就是打開—log-slave-update選項。然后，通過二級（或者是更多級別）復制來減少Master端因為復制所帶來的壓力。也就是說，我們首先通過少數幾台MySQL從Master來進行復制，這幾台機器我們姑且稱之為第一級Slave集群，然后其他的Slave再從第一級Slave集群來進行復制。從第一級Slave進行復制的Slave，我稱之為第二級Slave集群。如果有需要，我們可以繼續往下增加更多層次的復制。這樣，我們很容易就控制了每一台MySQL上面所附屬Slave的數量。這種架構我稱之為Master-Slaves-Slaves架構
這種多層級聯復制的架構，很容易就解決了Master端因為附屬Slave太多而成為瓶頸的風險。下圖展示了多層級聯復制的Replication架構。
當然，如果條件允許，我更傾向於建議大家通過拆分成多個Replication集群來解決
上述瓶頸問題。畢竟Slave並沒有減少寫的量，所有Slave實際上仍然還是應用了所有的數據變更操作，沒有減少任何寫IO。相反，Slave越多，整個集群的寫IO總量也就會越多，我們沒有非常明顯的感覺，僅僅只是因為分散到了多台機器上面，所以不是很容易表現出來。
此外，增加復制的級聯層次，同一個變更傳到最底層的Slave所需要經過的MySQL也會更多，同樣可能造成延時較長的風險。
而如果我們通過分拆集群的方式來解決的話，可能就會要好很多了，當然，分拆集群也需要更復雜的技術和更復雜的應用系統架構。
4.5、帶從服務器的Master-Master結構(Master-Master with Slaves)
這種結構的優點就是提供了冗余。在地理上分布的復制結構，它不存在單一節點故障問題，而且還可以將讀密集型的請求放到slave上。
級聯復制在一定程度上面確實解決了Master因為所附屬的Slave過多而成為瓶頸的問題，但是他並不能解決人工維護和出現異常需要切換后可能存在重新搭建Replication的問題。這樣就很自然的引申出了DualMaster與級聯復制結合的Replication架構，我稱之為Master-Master-Slaves架構
和Master-Slaves-Slaves架構相比，區別僅僅只是將第一級Slave集群換成了一台單獨的Master，作為備用Master，然后再從這個備用的Master進行復制到一個Slave集群。
這種DualMaster與級聯復制結合的架構，最大的好處就是既可以避免主Master的寫入操作不會受到Slave集群的復制所帶來的影響，同時主Master需要切換的時候也基本上不會出現重搭Replication的情況。但是，這個架構也有一個弊端，那就是備用的Master有可能成為瓶頸，因為如果后面的Slave集群比較大的話，備用Master可能會因為過多的SlaveIO線程請求而成為瓶頸。當然，該備用Master不提供任何的讀服務的時候，瓶頸出現的可能性並不是特別高，如果出現瓶頸，也可以在備用Master后面再次進行級聯復制，架設多層Slave集群。當然，級聯復制的級別越多，Slave集群可能出現的數據延時也會更為明顯，所以考慮使用多層級聯復制之前，也需要評估數據延時對應用系統的影響。
5、復制的常見問題
錯誤一：change master導致的：
Last_IO_Error: error connecting to master 'repl1@IP:3306' - retry-time: 60 retries
錯誤二：在沒有解鎖的情況下停止slave進程：
mysql> stop slave;
ERROR 1192 (HY000): Can't execute the given command because you have active locked tables or an active transaction
錯誤三：在沒有停止slave進程的情況下change master
mysql> change master to master_host=‘IP', master_user='USER', master_password='PASSWD', master_log_file='mysql-bin.000001',master_log_pos=106;
ERROR 1198 (HY000): This operation cannot be performed with a running slave; run STOP SLAVE first
錯誤四：A B的server-id相同：
Last_IO_Error: Fatal error: The slave I/O thread stops because master and slave have equal MySQL server ids;
these ids must be different for replication to work (or the --replicate-same-server-id option must be used on
slave but this does not always make sense; please check the manual before using it).
查看server-id
mysql> show variables like 'server_id';
手動修改server-id
mysql> set global server_id=2; #此處的數值和my.cnf里設置的一樣就行
mysql> slave start;
錯誤五：change master之后，查看slave的狀態，發現slave_IO_running 仍為NO
需要注意的是，上述幾個錯誤做完操作之后要重啟mysql進程，slave_IO_running 變為Yes
錯誤六：MySQL主從同步異常Client requested master to start replication from position > file size
字面理解：從庫的讀取binlog的位置大於主庫當前binglog的值
這一般是主庫重啟導致的問題，主庫從參數sync_binlog默認為1000，即主庫的數據是先緩存到1000條后統一fsync到磁盤的binlog文件中。
當主庫重啟的時候，從庫直接讀取主庫接着之前的位點重新拉binlog，但是主庫由於沒有fsync最后的binlog，所以會返回1236 的錯誤。
正常建議配置sync_binlog=1 也就是每個事務都立即寫入到binlog文件中。
1、在從庫檢查slave狀態:
偏移量為4063315
2、在主庫檢查mysql-bin.001574的偏移量位置
mysqlbinlog mysql-bin.001574 > ./mysql-bin.001574.bak
tail -10 ./mysql-bin.001574.bak
mysql-bin.001574文件最后幾行 發現最后偏移量是4059237，從庫偏移量的4063315遠大主庫的偏移量4059237，也就是參數sync_binlog=1000導致的。
3、重新設置salve
mysql> stop slave;
mysql> change master to master_log_file='mysql-bin.001574' ,master_log_pos=4059237;
mysql> start slave;
錯誤8：數據同步異常情況
第一種：在master上刪除一條記錄，而slave上找不到。
Last_Error: Could not execute Delete_rows event on table market_edu.tl_player_task; Can't find record in 'tl_player_task', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log mysql-bin.002094, end_log_pos 286434186
解決方法：由於master要刪除一條記錄，而slave上找不到故報錯，這種情況主上都將其刪除了，那么從機可以直接跳過。
可用命令：stop slave; set global sql_slave_skip_counter=1; start slave;
第二種：主鍵重復。在slave已經有該記錄，又在master上插入了同一條記錄。
Last_SQL_Error: Could not execute Write_rows event on table hcy.t1;
Duplicate entry '2' for key 'PRIMARY',
Error_code: 1062;
handler error HA_ERR_FOUND_DUPP_KEY; the event's master log mysql-bin.000006, end_log_pos 924
解決方法：在slave刪除重復的主鍵
第三種：在master上更新一條記錄，而slave上找不到，丟失了數據。
Last_SQL_Error: Could not execute Update_rows event on table hcy.t1;
Can't find record in 't1',
Error_code: 1032;
handler error HA_ERR_KEY_NOT_FOUND; the event's master log mysql-bin.000010, end_log_pos 263
解決方法：把丟失的數據在slave上填補，然后跳過報錯即可。
insert into t1 values (2,'BTV');
stop slave ;set global sql_slave_skip_counter=1;start slave;
mysql 主從復制原理
- 一主一從
- 主主復制
- 一主多從---擴展系統讀取的性能，因為讀是在從庫讀取的；
- 多主一從---5.7開始支持
- 聯級復制---
- 實時災備，用於故障切換
- 讀寫分離，提供查詢服務
- 備份，避免影響業務
- 主庫開啟binlog日志（設置log-bin參數）
- 主從server-id不同
- 從庫服務器能連通主庫
- 主庫宕機后，數據可能丟失
- 從庫只有一個sql Thread，主庫寫壓力大，復制很可能延時
- 半同步復制---解決數據丟失的問題
- 並行復制----解決從庫復制延遲的問題
- 5.5集成到mysql，以插件的形式存在，需要單獨安裝
- 確保事務提交后binlog至少傳輸到一個從庫
- 不保證從庫應用完這個事務的binlog
- 性能有一定的降低，響應時間會更長
- 如果主庫的一個事務提交成功了，在推送到從庫的過程當中，從庫宕機了或網絡故障，導致從庫並沒有接收到這個事務的Binlog，此時主庫會等待一段時間（這個時間由rpl_semi_sync_master_timeout的毫秒數決定），如果這個時間過后還無法推送到從庫，那MySQL會自動從半同步復制切換為異步復制，當從庫恢復正常連接到主庫后，主庫又會自動切換回半同步復制
- 社區版5.6中新增
- 並行是指從庫多線程apply binlog
- 庫級別並行應用binlog，同一個庫數據更改還是串行的(5.7版並行復制基於事務組)
set global slave_parallel_workers=10;
binlog_do_db=db1 binlog_ignore_db=db1 binlog_ignore_db=db2
replicate_do_db=db1 replicate_ignore_db=db1 replicate_do_table=db1.t1 replicate_wild_do_table=db%.% replicate_wild_ignore_table=db1.%
log_slave_updates B將把A的binlog記錄到自己的binlog日志中
show slave status \G
- 手動處理
- 跳過復制錯誤：set global sql_slave_skip_counter=1
MySQL主從復制
原理：將主服務器的binlog日志復制到從服務器上執行一遍，達到主從數據的一致狀態。
過程：從庫開啟一個I/O線程，向主庫請求Binlog日志。主節點開啟一個binlog dump線程，檢查自己的二進制日志，並發送給從節點；從庫將接收到的數據保存到中繼日志（Relay log）中，另外開啟一個SQL線程，把Relay中的操作在自身機器上執行一遍
優點：
- 作為備用數據庫，並且不影響業務
- 可做讀寫分離，一般是一個寫庫，一個或多個讀庫，分布在不同的服務器上，充分發揮服務器和數據庫的性能，但要保證數據的一致性
擴展：
- SQL線程執行完Relay log中的事件后，會將當前的中繼日志Relay log刪除，避免它占用更多的磁盤空間
- 為保證從庫重啟后，仍然知道從哪里開始復制，從庫默認會創建兩個文件master.info和relay-log.info，分別記錄了從庫的IO線程當前讀取主庫binlog的進度和SQL線程應用Relay-log的進度。可通過show slave status \G命令查看從庫當前復制的狀態
主從復制時的日志格式：
這里的日志格式就是指二進制日志的三種格式：基於語句statement的復制、基於行row的復制、基於語句和行（mix）的復制。其中基於row的復制方式更能保證主從庫數據的一致性，但日志量較大，在設置時考慮磁盤的空間問題
show variables like ‘%binlog%format%’; #查看當前使用的binlog的格式
set binlog_format = ‘row’; #設置格式，這種方法只在當前session生效
set global binlog_format = ‘row’; #在全局下設置binlog格式，會影響所有的Session
復制架構：
1、一主多從架構
在主庫的請求壓力非常大時，可通過配置一主多從復制架構實現讀寫分離，把大量對實時性要求不是很高的請求通過負載均衡分發到多個從庫上去讀取數據，降低主庫的讀取壓力。而且在主庫出現宕機時，可將一個從庫切換為主庫繼續提供服務
2、多級復制架構
因為每個從庫在主庫上都會有一個獨立的Binlog Dump線程來推送binlog日志，所以隨着從庫數量的增加，主庫的IO壓力和網絡壓力也會隨之增加，這時，多級復制架構應運而生。
多級復制架構只是在一主多從的基礎上，再主庫和各個從庫之間增加了一個二級主庫Master2，這個二級主庫僅僅用來將一級主庫推送給它的BInlog日志再推送給各個從庫，以此來減輕一級主庫的推送壓力。
但它的缺點就是Binlog日志要經過兩次復制才能到達從庫，增加了復制的延時。
我們可以通過在二級從庫上應用Blackhol存儲引擎（黑洞引擎）來解決這一問題，降低多級復制的延時。
“黑洞引擎”就是寫入Blackhole表中數據並不會寫到磁盤上，所以這個Blackhole表永遠是個空表，對數據的插入/更新/刪除操作僅在Binlog中記錄，並復制到從庫中去。
3、雙主復制/Dual Master架構
雙主復制架構適用於需要進行主從切換的場景
在只有一個主庫的架構下，當主庫宕機后，將其中一個從庫切換為主庫繼續提供服務。原來的主庫就沒有數據來源了，那么當這個新的主庫接收到新的數據時，原來的主庫卻沒有同步，因此他們的數據差異越來越大，那么原來的主庫就無法成為主從復制環境中的一員了。當原來的主庫恢復正常后，需要重新將其添加進復制環境中去。
那為了避免重復添加主庫的問題，雙主復制應運而生。兩個數據庫互為主從，當主庫宕機恢復后，由於它還是原來從庫（現在主庫）的從機，所以它還是會復制新的主庫上的數據。那么無論主庫的角色怎么切換，原來的主庫都不會脫離復制環境。
復制方式
一、異步復制
在異步復制中，主庫執行完操作后，寫入binlog日志后，就返回客戶端，這一動作就結束了，並不會驗證從庫有沒有收到，完不完整，所以這樣可能會造成數據的不一致。
說到底，復制過程中數據是否一致，主要取決於Binlog日志的安全性與完整性
在MySQL中，有sync_binlog=n這一參數，他的值表示每進行n次事務提交，MySQL就將Binlog刷新到磁盤。如果這個值為1，就代表每提交一次事務（SQL），就將Binlog往磁盤刷新一次，這樣一來，就算數據庫宕機了，那么最多只能損失一次事務的數據。
但是，一旦多個事務並發提交時，由於受sync_binlog的限制，MySQL只能按順序來處理這些請求，另外，高頻率的刷新binlog對IO的影響也很大，進一步影響了數據庫的性能，所以，一般這個值都設為0或者其他值，在數據的安全性和高並發下的性能之間取得一個平衡。
為了更加有效的保護Binlog的安全性和完整性，MySQL5 .5之后引入了半同步復制
二、半同步復制
在異步復制中，我們遇到的一個主要問題就是，在復制過程當中，主庫不會去驗證Binlog有沒有成功復制到從庫，那如果主庫提交一個事務並寫入Binlog中后，當從庫還沒有從主庫得到Binlog時，主庫宕機了或因磁盤損壞等故障導致該事務的Binlog丟失了，那從庫就不會得到這個事務，也就造成了主從數據的不一致。
而半同步復制，當主庫每提交一個事務后，不會立即返回，而是等待其中一個從庫接收到Binlog並成功寫入Relay-log中才返回客戶端，所以這樣就保證了一個事務至少有兩份日志，一份保存在主庫的Binlog，另一份保存在其中一個從庫的Relay-log中，從而保證了數據的安全性和一致性。
另外，在半同步復制時，如果主庫的一個事務提交成功了，在推送到從庫的過程當中，從庫宕機了或網絡故障，導致從庫並沒有接收到這個事務的Binlog，此時主庫會等待一段時間（這個時間由rpl_semi_sync_master_timeout的毫秒數決定），如果這個時間過后還無法推送到從庫，那MySQL會自動從半同步復制切換為異步復制，當從庫恢復正常連接到主庫后，主庫又會自動切換回半同步復制。
半同步復制的“半”體現在，雖然主從庫的Binlog是同步的，但主庫不會等待從庫執行完Relay-log后才返回，而是確認從庫接收到Binlog，達到主從Binlog同步的目的后就返回了，所以從庫的數據對於主庫來說還是有延時的，這個延時就是從庫執行Relay-log的時間。所以只能稱為半同步。
三、全同步復制（Fully synchronous replication）
1、邏輯上
指當主庫執行完一個事務，所有的從庫都執行了該事務才返回給客戶端。因為需要等待所有從庫執行完該事務才能返回，所以全同步復制的性能必然會收到嚴重的影響。
2、技術上
當主庫提交事務之后，所有的從庫節點必須收到、APPLY並且提交這些事務，然后主庫線程才能繼續做后續操作。但缺點是，主庫完成一個事務的時間會被拉長，性能降低。
深度探索MySQL主從復制原理
啟迪雲計算-開發工程師 邸小麗
概要
MySQL Replication (MySQL 主從復制) 是什么？為什么要主從復制以及它的實現原理是什么？
- MySQL 主從復制概念
MySQL 主從復制是指數據可以從一個MySQL數據庫服務器主節點復制到一個或多個從節點。MySQL 默認采用異步復制方式，這樣從節點不用一直訪問主服務器來更新自己的數據，數據的更新可以在遠程連接上進行，從節點可以復制主數據庫中的所有數據庫或者特定的數據庫，或者特定的表。
- MySQL 主從復制主要用途
l 讀寫分離
在開發工作中，有時候會遇見某個sql 語句需要鎖表，導致暫時不能使用讀的服務，這樣就會影響現有業務，使用主從復制，讓主庫負責寫，從庫負責讀，這樣，即使主庫出現了鎖表的情景，通過讀從庫也可以保證業務的正常運作。
l 數據實時備份，當系統中某個節點發生故障時，可以方便的故障切換
l 高可用HA
l 架構擴展
隨着系統中業務訪問量的增大，如果是單機部署數據庫，就會導致I/O訪問頻率過高。有了主從復制，增加多個數據存儲節點，將負載分布在多個從節點上，降低單機磁盤I/O訪問的頻率，提高單個機器的I/O性能。
- MySQL 主從形式
一主一從
一主多從，提高系統的讀性能
一主一從和一主多從是最常見的主從架構，實施起來簡單並且有效，不僅可以實現HA，而且還能讀寫分離，進而提升集群的並發能力。
多主一從 （從5.7開始支持）
多主一從可以將多個mysql數據庫備份到一台存儲性能比較好的服務器上。
雙主復制
雙主復制，也就是互做主從復制，每個master既是master，又是另外一台服務器的slave。這樣任何一方所做的變更，都會通過復制應用到另外一方的數據庫中。
級聯復制
級聯復制模式下，部分slave的數據同步不連接主節點，而是連接從節點。因為如果主節點有太多的從節點，就會損耗一部分性能用於replication，那么我們可以讓3~5個從節點連接主節點，其它從節點作為二級或者三級與從節點連接，這樣不僅可以緩解主節點的壓力，並且對數據一致性沒有負面影響。
- MySQL 主從復制原理
MySQL主從復制涉及到三個線程，一個運行在主節點（log dump thread），其余兩個(I/O thread, SQL thread)運行在從節點，如下圖所示:
l 主節點 binary log dump 線程
當從節點連接主節點時，主節點會創建一個log dump 線程，用於發送bin-log的內容。在讀取bin-log中的操作時，此線程會對主節點上的bin-log加鎖，當讀取完成，甚至在發動給從節點之前，鎖會被釋放。
l 從節點I/O線程
當從節點上執行`start slave`命令之后，從節點會創建一個I/O線程用來連接主節點，請求主庫中更新的bin-log。I/O線程接收到主節點binlog dump 進程發來的更新之后，保存在本地relay-log中。
l 從節點SQL線程
SQL線程負責讀取relay log中的內容，解析成具體的操作並執行，最終保證主從數據的一致性。
對於每一個主從連接，都需要三個進程來完成。當主節點有多個從節點時，主節點會為每一個當前連接的從節點建一個binary log dump 進程，而每個從節點都有自己的I/O進程，SQL進程。從節點用兩個線程將從主庫拉取更新和執行分成獨立的任務，這樣在執行同步數據任務的時候，不會降低讀操作的性能。比如，如果從節點沒有運行，此時I/O進程可以很快從主節點獲取更新，盡管SQL進程還沒有執行。如果在SQL進程執行之前從節點服務停止，至少I/O進程已經從主節點拉取到了最新的變更並且保存在本地relay日志中，當服務再次起來之后，就可以完成數據的同步。
要實施復制，首先必須打開Master 端的binary log（bin-log）功能，否則無法實現。
因為整個復制過程實際上就是Slave 從Master 端獲取該日志然后再在自己身上完全順序的執行日志中所記錄的各種操作。如下圖所示：
復制的基本過程如下：
- 從節點上的I/O 進程連接主節點，並請求從指定日志文件的指定位置（或者從最開始的日志）之后的日志內容；
- 主節點接收到來自從節點的I/O請求后，通過負責復制的I/O進程根據請求信息讀取指定日志指定位置之后的日志信息，返回給從節點。返回信息中除了日志所包含的信息之外，還包括本次返回的信息的bin-log file 的以及bin-log position；從節點的I/O進程接收到內容后，將接收到的日志內容更新到本機的relay log中，並將讀取到的binary log文件名和位置保存到master-info 文件中，以便在下一次讀取的時候能夠清楚的告訴Master“我需要從某個bin-log 的哪個位置開始往后的日志內容，請發給我”；
- Slave 的 SQL線程檢測到relay-log 中新增加了內容后，會將relay-log的內容解析成在祝節點上實際執行過的操作，並在本數據庫中執行。
- MySQL 主從復制模式
MySQL 主從復制默認是異步的模式。MySQL增刪改操作會全部記錄在binary log中，當slave節點連接master時，會主動從master處獲取最新的bin log文件。並把bin log中的sql relay。
l 異步模式（mysql async-mode）
異步模式如下圖所示，這種模式下，主節點不會主動push bin log到從節點，這樣有可能導致failover的情況下，也許從節點沒有即時地將最新的bin log同步到本地。
l 半同步模式(mysql semi-sync)
這種模式下主節點只需要接收到其中一台從節點的返回信息，就會commit；否則需要等待直到超時時間然后切換成異步模式再提交；這樣做的目的可以使主從數據庫的數據延遲縮小，可以提高數據安全性，確保了事務提交后，binlog至少傳輸到了一個從節點上，不能保證從節點將此事務更新到db中。性能上會有一定的降低，響應時間會變長。如下圖所示：
半同步模式不是mysql內置的，從mysql 5.5開始集成，需要master 和slave 安裝插件開啟半同步模式。
l 全同步模式
全同步模式是指主節點和從節點全部執行了commit並確認才會向客戶端返回成功。
- binlog記錄格式
MySQL 主從復制有三種方式：基於SQL語句的復制（statement-based replication，SBR），基於行的復制（row-based replication，RBR)，混合模式復制（mixed-based replication,MBR)。對應的binlog文件的格式也有三種：STATEMENT,ROW,MIXED。
l Statement-base Replication (SBR)就是記錄sql語句在bin log中，Mysql 5.1.4 及之前的版本都是使用的這種復制格式。優點是只需要記錄會修改數據的sql語句到binlog中，減少了binlog日質量，節約I/O，提高性能。缺點是在某些情況下，會導致主從節點中數據不一致（比如sleep(),now()等）。
l Row-based Relication(RBR)是mysql master將SQL語句分解為基於Row更改的語句並記錄在bin log中，也就是只記錄哪條數據被修改了，修改成什么樣。優點是不會出現某些特定情況下的存儲過程、或者函數、或者trigger的調用或者觸發無法被正確復制的問題。缺點是會產生大量的日志，尤其是修改table的時候會讓日志暴增,同時增加bin log同步時間。也不能通過bin log解析獲取執行過的sql語句，只能看到發生的data變更。
l Mixed-format Replication(MBR)，MySQL NDB cluster 7.3 和7.4 使用的MBR。是以上兩種模式的混合，對於一般的復制使用STATEMENT模式保存到binlog，對於STATEMENT模式無法復制的操作則使用ROW模式來保存，MySQL會根據執行的SQL語句選擇日志保存方式。
- GTID復制模式
@ 在傳統的復制里面，當發生故障，需要主從切換，需要找到binlog和pos點，然后將主節點指向新的主節點，相對來說比較麻煩，也容易出錯。在MySQL 5.6里面，不用再找binlog和pos點，我們只需要知道主節點的ip，端口，以及賬號密碼就行，因為復制是自動的，MySQL會通過內部機制GTID自動找點同步。
@ 多線程復制（基於庫），在MySQL 5.6以前的版本，slave的復制是單線程的。一個事件一個事件的讀取應用。而master是並發寫入的，所以延時是避免不了的。唯一有效的方法是把多個庫放在多台slave，這樣又有點浪費服務器。在MySQL 5.6里面，我們可以把多個表放在多個庫，這樣就可以使用多線程復制。
- 基於GTID復制實現的工作原理
- 主節點更新數據時，會在事務前產生GTID，一起記錄到binlog日志中。
- 從節點的I/O線程將變更的bin log，寫入到本地的relay log中。
- SQL線程從relay log中獲取GTID，然后對比本地binlog是否有記錄（所以MySQL從節點必須要開啟binary log）。
- 如果有記錄，說明該GTID的事務已經執行，從節點會忽略。
- 如果沒有記錄，從節點就會從relay log中執行該GTID的事務，並記錄到bin log。
- 在解析過程中會判斷是否有主鍵，如果沒有就用二級索引，如果有就用全部掃描。
GTID復制原理：
基於GTID的復制是MySQL 5.6后新增的復制方式.
GTID (global transaction identifier) 即全局事務ID, 保證了在每個在主庫上提交的事務在集群中有一個唯一的ID.
在原來基於日志的復制中, 從庫需要告知主庫要從哪個偏移量進行增量同步, 如果指定錯誤會造成數據的遺漏, 從而造成數據的不一致.
而基於GTID的復制中, 從庫會告知主庫已經執行的事務的GTID的值, 然后主庫會將所有未執行的事務的GTID的列表返回給從庫. 並且可以保證同一個事務只在指定的從庫執行一次.
GTID是由server_uuid和事物id組成，格式為：GTID=server_uuid:transaction_id。server_uuid是在數據庫啟動過程中自動生成，每台機器的server-uuid不一樣。uuid存放在數據目錄的auto.conf文件中，而transaction_id就是事務提交時系統順序分配的一個不會重復的序列號。
GTID的好處：
（1）GTID使用master_auto_position=1代替了binlog和position號的主從復制搭建方式，相比binlog和position方式更容易搭建主從復制。
（2）GTID方便實現主從之間的failover，不用一步一步的去查找position和binlog文件。
- 總結
Mysql 主從復制是mysql 高可用，高性能的基礎，有了這個基礎，mysql 的部署會變得簡單、靈活並且具有多樣性，從而可以根據不同的業務場景做出靈活的調整。
MySQL主從復制數據一致性校驗和修復方法及自動化實現
1. 引言
“MySQL主從復制”技術在互聯網行業常見高可用架構中應用非常廣泛，例如常見的一主一從復制架構、keepalived＋MySQL雙主（主從）復制架構、MHA＋一主兩從復制架構等等都應用了MySQL主從復制技術。但因主從復制是基於binlog的邏輯復制，難免出現復制數據不一致的風險，這個風險不但會引起用戶數據訪問前后不一致的風險，而且會導致后續復制出現1032、1062錯誤進而引起復制架構停滯的隱患，為了及時發現並解決這個問題，我們需要定期或不定期地開展主從復制數據一致性的校驗和修復工作，那么如何實現這項工作呢？又如何實現這項工作的自動化呢？我們來探討這些問題。
2. 數據一致性校驗和修復方法
為了實現主從復制數據一致性校驗和修復，我們首先推薦兩個熱門工具，分別是percona公司的 pt-table-checksum和pt-table-sync，前者用來實現主從復制數據一致性的校驗，后者實現數據修復，將數據修復到一致。
2.1工作原理
pt-table-checksum通過SQL在主庫執行數據塊的校驗，再將相同的語句傳送到從庫，並在從庫上計算數據塊的校驗，最后將主從庫相同塊的校驗值進行對比，辨別主從數據是否不一致。
pt-table-sync用來修復主從復制數據的不一致，使得它們修復到最終一致，也可以實現多個實例或者是應用雙寫或多寫的多個不相關的數據庫實例修復到一致。同時它還內部集成了pt-table-checksum的校驗功能，可以一邊校驗一邊修復，也可以基於pt-table-checksum的計算結果來進行修復
主從數據修復
用pt-table-checksum工具確定確實存在數據不一致的情況下開始修復數據，數據修復使用工具pt-table-sync，內帶校驗功能，但前提是修復的表必須要有主鍵，這個工具也要在主庫上執行。
語句量大的情況下將修復的語句導入到sql文件中，再直接導入執行
在主庫用pt-table-sync打印出修復不一致數據的SQL，后將修復語句在從庫執行。
2.2 值得注意的點
（1）校驗修復工作每月定期開展；
（2）主從復制架構在割接操作前后均需執行數據校驗和修復工作；
（3）主從復制出現故障后要開展數據校驗和修復工作；
（4）校驗修復需在業務低谷期進行，CPU利用率超過60%時不建議做數據校驗和修復；
（5）校驗和修復必須在主庫進行；
（6）數據庫的表要有主鍵，否則校驗效率極差，並且修復不成功。
3.數據一致性校驗和修復的自動化實現
理解上述方法后，我們可以順利完成主從復制數據一致性的校驗和修復工作，但是這項工作在MySQL主從復制架構維護中開展頻率較高，包括定期和各種不定期的情況，每次都手工開展耗時耗力，並且容易出現人為錯誤及隱患，因此，我們考慮將這項工作通過腳本實現自動化。
自動化實現
部署自動化腳本和定時任務
理解數據一致性校驗和修復的全部原理和詳細步驟，將其轉化為多個自動化腳本，分別部署在主從庫上，每月定期執行可通過在主庫制定crontab定時任務調用主從庫腳本實現，不定期執行可通過手動調用主從庫部署的自動化腳本來實現。