mysql的復制
這片博文會詳細說明MySQL復制的過程以及復制的原理！
會詳細說明以下幾種復制模式：傳統的MySQL復制，MySQL5.6的半同步輔助以及MySQL5.7的無損復制。
傳統的MySQL異步復制
復制解決的基本問題是讓一臺服務器的數據與其他服務器的數據保持同步。一臺主庫的數據可以同步到多臺備庫上，備庫本身也可以被設置成另外一臺服務器的主庫。主庫和備庫之間可以有多種不同的組合方式。
mysql支持兩種方式的復制；基於行的復制和基於語句的復制。基於語句的復制在之前的版本中就已經存在，但是基於行的復制在mysql5.1之後，才開始支持！這兩種方式都是通過在主庫上記錄二進制日誌，在備庫重放日誌的方式來實現異步數據的復制
上面我們提到過復制是基於二進制日誌進行的，那麽復制究竟是如何工作的？總的來說，復制有三個步驟
- 在主庫上把數據更改記錄到二進制日誌中（這些記錄被稱為二進制日誌事件）
- 被庫將主庫上的二進制日誌復制到自己的中繼日誌中。
- 備庫讀取中繼中的事件，然後將其重放到備庫上！
復制過程如圖（圖片來自網絡，這個圖很經典，幾乎每片將mysql主從的都會有的）
第一步：在主庫上記錄二進制日誌。在每次準備提交事務完成數據更新前，主庫將數據更新的事件按照事務提交的順序寫入二進制日誌，寫入二進制日誌之後，主庫會告訴存儲引擎可以提交事務了！
第二步：備庫將主庫的二進制日誌復制到本地的中繼日誌中。首先，備庫會啟動一個工作線程（I/O線程），I/O線程跟主庫建立一個普通的客戶端連接，然後在主庫上啟動一個特殊的二進制轉儲線程（dump 線程），dump線程會讀取主庫上二進制日誌中的事件。它不會對事件盡心輪詢，如果該線程追趕上了主庫，它將進入休眠狀態，直到主庫發送信號量通知其有新的事件產生時才會被喚醒，備庫I/O線程會將接收到的事件記錄到中繼日誌中。
第三：備庫的SQL線程會重放中繼日誌中的事件，從而實現主庫的數據在從庫的復制。
這種復制架構實現了獲取事件和重放事件的解耦（生產者與消費者模型），允許這兩個事件異步進行。也就是說I/O線程獨立於SQL線程之外工作。但是由於這種架構限制了復制過程，其中最重要的就是在主庫上並發運行的查詢在備庫上只能串行執行，因為只有一個SQL線程來重放中繼日誌中的事件。而這一點也是mysql復制的性能瓶頸所在，因此在mysql5.6和mysql5.7中都對此做了優化，後面我們會說到的！
#在mysql的復制過程中，基本上來說有三個主要線程！
master轉儲線程：當slave IO線程連接master時，master創建這個線程。負責從master的binlog文件讀取記錄，然後發送給slave。每個連接到master的slave都有一個轉儲線程
slave IO線程：負責連接master並請求所有master上的更新轉儲到中繼日誌，以便SQL線程進行進一步的處理。每個slave都有一個IO線程。一旦連接建立，這個線程就一直都在，
這樣slave就能立即收到master的所有更新。
slave SQL線程：這個線程讀取中繼日誌中的更新，然後在從庫上應用這些更新。這個線程負載協調其他mysql線程，保證這些更新不與mysql服務器上的其他活動產生沖突。
下面我們搭建一個傳統的異步復制
mysql的主從搭建很簡單，只說一下搭建的步驟：
若是兩個全新的服務器，沒有任何數據：（全新的服務器，數據本身就是一致的狀態）
l 第一步：分別開啟二進制日誌
l 第二步：修改兩個服務器的server-id,兩臺服務器的id設置要不一樣。
l 第三步：在作為master的服務器上創建用來做主從復制的用戶。
l 第四步：在從上連接master服務器，然後在從上執行start slave。
mysql> select @@version; #我們測試用的數據庫的版本 +-----------+ | @@version | +-----------+ | 5.7.23 | +-----------+ 1 row in set (0.00 sec) mysql> show databases; #這臺數據庫上有數據 +--------------------+ | Database | +--------------------+ | information_schema | | djtest | | employees | | hostinfo | | mysql | | mytest | | performance_schema | | sys | +--------------------+ 8 rows in set (0.00 sec)
第一步：把當前服務器服務器中所有的數據備份，然後在新建的從庫上進行恢復，使兩臺服務器處於一致的狀態！
[root@mgt01 ~]# mysqldump -uroot -p123456 --single-transaction --all-databases > all.sql mysqldump: [Warning] Using a password on the command line interface can be insecure. [root@mgt01 ~]# scp all.sql 192.168.1.121:/root/ root@192.168.1.121‘s password: all.sql 100% 161MB 32.3MB/s 00:05 [root@mgt01 ~]# #在從庫執行恢復 [root@mgt02 ~]# mysql -uroot -p123456 < all.sql mysql: [Warning] Using a password on the command line interface can be insecure. [root@mgt02 ~]#
第二步：開啟主庫的而二進制日誌，若是做級聯復制從庫也需要開啟二進制日誌（後面再說）
#在主庫配置文件設置 log-bin= #二進制日誌默認是在datadir指定的目錄下面的 server-id=13 #在主從環境中，每臺服務器的server-id要設置的不一樣 #在從庫配置文件設置 server-id=13
第三步：在主庫上創建用來復制的賬號：
mysql> grant all privileges on *.* to "repl"@"192.168.1.121" identified by "123456"; Query OK, 0 rows affected, 1 warning (0.00 sec) mysql> show warnings; +---------+------+------------------------------------------------------------------------------------------------------------------------------------+ | Level | Code | Message | +---------+------+------------------------------------------------------------------------------------------------------------------------------------+ | Warning | 1287 | Using GRANT for creating new user is deprecated and will be removed in future release. Create new user with CREATE USER statement. | +---------+------+------------------------------------------------------------------------------------------------------------------------------------+ 1 row in set (0.00 sec) mysql> flush privileges; Query OK, 0 rows affected (0.00 sec) mysql>
第四步：從庫連接主庫
首先查看主庫二進制的日誌點：
mysql> show master status; +------------------+----------+--------------+------------------+-------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | +------------------+----------+--------------+------------------+-------------------+ | mgt01-bin.000001 | 598 | | | | +------------------+----------+--------------+------------------+-------------------+ 1 row in set (0.00 sec) mysql>
然後在從庫上執行如下命令：
mysql> change master to master_host="192.168.1.120", master_user="repl",master_password="123456",master_log_file="mgt01-bin.000001",master_log_pos=598; Query OK, 0 rows affected, 2 warnings (0.08 sec)
#這裏的兩個警告，只是說明了一些傳輸安全信息
mysql> start slave; #開啟復制
Query OK, 0 rows affected (0.00 sec)
mysql> show slave status\G #從上查看狀態
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.1.120
Master_User: repl
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mgt01-bin.000001
Read_Master_Log_Pos: 598
Relay_Log_File: mgt02-relay-bin.000002
Relay_Log_Pos: 320
Relay_Master_Log_File: mgt01-bin.000001
Slave_IO_Running: Yes #表明IO線程和SQL線程已經工作了
Slave_SQL_Running: Yes
。。。。。。。。
測試如下：
#在主庫做如下操作 mysql> insert into tb1 values(1, @@hostname, "test"); Query OK, 1 row affected (0.04 sec) mysql> select * from tb1; +------+-------+------+ | id | name | info | +------+-------+------+ | 1 | mgt01 | test | +------+-------+------+ 1 row in set (0.00 sec) #在從庫查看數據 mysql> select * from tb1; +------+-------+------+ | id | name | info | +------+-------+------+ | 1 | mgt01 | test | +------+-------+------+ 1 row in set (0.00 sec) #若是基於語句的復制，這兩個數據應該不一樣的，但是現在是一樣的，說明是基於行的復制！ mysql> show variables like "binlog_format"; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | binlog_format | ROW | +---------------+-------+ 1 row in set (0.00 sec)測試主從
一個簡易的主從架構已經完成！
下面我們會詳細說明與MySQL主從復制相關的幾個文件（二進制日誌文件會單獨列出來講的）
中繼日誌是連接master和slave的信息，是復制的核心。
中繼日誌除了含有二進制日誌和索引文件以外，中繼日誌還維護兩個文件來跟蹤復制的進度，即中繼日誌信息文件和master日誌信息文件，這個兩個文件名字由my.cnf的兩個參數配置。
relay_log_info_file=filename；如果沒有指定文件名，則默認為：relay-log.info。 master-info-file=filename：這個參數設置master日誌信息文件。默認文件名為master.info。
查看一下maste.info信息如下：
master.info文件包含master的讀位置，以及連接master和啟動復制必須的所有信息。當slave的IO線程啟動時，如果有master.info文件，則線程先從這個文件讀取信息。
master.info文件中的信息優於my.cnf文件。也就是說，如果改變了配置文件中的信息，重啟服務器，將會從master.info讀取信息而不是配置文件。
因此不推薦在配置文件中使用change master to參數配置，而是直接使用命令。由於某種原因，需要把復制參數放到配置文件中，而且希望slave啟動的時候讀取這些
參數，則必須在編輯配置文件之前執行reset slave命令。
請謹慎執行reset slave命令！這個命令會刪除master.info和relay-log.info文件，以及所有的中繼日誌文件！
查看relay-log.info的信息
[root@test2 mysql]# cat relay-log.info 7 ./test2-relay-bin.000002 #當前正在讀取的中繼日誌 320 #當前正在讀取的中級日誌的position位置 test3-bin.000003 #這個在主從復制時change master命令指向的master的二進制日誌的文件名和日誌位置 1669 0 0 1
relay-log.info文件跟蹤復制的進度，並由SQL線程負責更新。
如果某些文件不可用時，在slave啟動的時候，能夠根據配置文件和change master to命令參數重建這些文件。僅僅使用配置文件並執行change命令是不夠的，只有執行了start slave命令， master.info文件和relay-log.info文件才會被創建。
也就是可以這樣說：master.info對應的是I/O線程，而relay-log.info對應的是SQL線程！
控制slave復制的幾個命令：
START / STOP SLAVE START / STOP slave io_thread START/ STOP slave sql_thread
slave_parallel_workers參數
上面提到過在MySQL5.6之前的異步復制中，只有一個IO線程，一個用於回放中繼日誌的SQL線程，SQL線程的回放效率成為性能的瓶頸！在MySQL5.6中引入了slave_parallel_workers參數，這個參數可以設置用於回放中繼日誌的線程數量。
但是MySQL5.6的多線程復制卻是基於schema，也就是說只有在master上多個schema，那麽這個多線程復制才會有作用，但是線上環境大多是一個schema中含有多張表，因此這個時候多線程將無法發揮應有的作用；MySQL5.7中引入了slave_parallel_type參數，這個參數可以設置為LOGICAL_CLOCK，基於邏輯的復制，才能真正發揮多線程的作用。
mysql> show variables like "slave_parallel_type"; +---------------------+----------+ | Variable_name | Value | +---------------------+----------+ | slave_parallel_type | DATABASE | #默認是基於schema +---------------------+----------+ 1 row in set (0.01 sec) mysql>
配置slave參數：
#並行復制參數配置
slave_parallel_workers=3 slave_parallel_type=LOGICAL_CLOCK
#設置了並行復制之後，可以看到有3個SQL線程在等待處理中繼日誌
mysql> show processlist; +----+-------------+-----------+------+---------+------+--------------------------------------------------------+------------------+ | Id | User | Host | db | Command | Time | State | Info | +----+-------------+-----------+------+---------+------+--------------------------------------------------------+------------------+ | 1 | system user | | NULL | Connect | 68 | Waiting for master to send event | NULL | | 2 | system user | | NULL | Connect | 68 | Slave has read all relay log; waiting for more updates | NULL | | 3 | system user | | NULL | Connect | 68 | Waiting for an event from Coordinator | NULL | | 4 | system user | | NULL | Connect | 68 | Waiting for an event from Coordinator | NULL | | 5 | system user | | NULL | Connect | 68 | Waiting for an event from Coordinator | NULL | | 8 | root | localhost | NULL | Query | 0 | starting | show processlist | +----+-------------+-----------+------+---------+------+--------------------------------------------------------+------------------+ 6 rows in set (0.01 sec)
#在數據庫目錄下面也產生了對應個數的中繼日誌信息（線上環境建議為16或32）
[root@test2 mysql]# ls worker-relay-log.info.*
worker-relay-log.info.1 worker-relay-log.info.2 worker-relay-log.info.3
以上就是傳統的異步復制
半同步復制和無損復制
半同步復制的原理是在復制繼續運行之前，確保至少有一個slave將變更寫到磁盤。也就是說，對每個鏈接來說，如果發生master崩潰，至多只有一個事務丟失。
半同步復制並不會阻止事務的提交，而是直到事務寫入至少一個slave中繼日誌才向客戶端發送響應。事務發送到slave之前是先提交到存儲引擎，而在一個slave確定事務已經寫入磁盤之後，才向客戶端發送提交確認。
半同步復制，只有在任一個slave已經確定存儲了上一個事務，然後向主發送確認回應，主才會繼續向slave中傳遞事務信息。因此半同步復制，最多只會丟失一個事務。
配置半同步復制：
第一：首先配置好主從架構。
第二：安裝插件，在mysql5.6及之後的版本已經融合入mysql中，可以直接安裝。
第三：主和從都要開啟復制，然後重啟服務器。
#查看當前MySQL是否開啟自動加載的功能！ mysql> show variables like "have_dynamic_loading"; +----------------------+-------+ | Variable_name | Value | +----------------------+-------+ | have_dynamic_loading | YES | +----------------------+-------+ 1 row in set (0.00 sec)
安裝插件：
mysql> install plugin rpl_semi_sync_master soname "semisync_master.so"; ERROR 1125 (HY000): Function ‘rpl_semi_sync_master‘ already exists mysql> install plugin rpl_semi_sync_slave soname "semisync_slave.so"; Query OK, 0 rows affected (0.03 sec)
然後開啟半同步復制：
#在主和從上分別添加如下參數 在主上添加 rpl-semi-sync-master-enabled = 1 在從上添加 rpl-semi-sync-slave-enabled = 1
查看參數：
mysql> show variables like "%semi%"; +-------------------------------------------+------------+ | Variable_name | Value | +-------------------------------------------+------------+ | rpl_semi_sync_master_enabled | ON | | rpl_semi_sync_master_timeout | 10000 | | rpl_semi_sync_master_trace_level | 32 | | rpl_semi_sync_master_wait_for_slave_count | 1 | | rpl_semi_sync_master_wait_no_slave | ON | | rpl_semi_sync_master_wait_point | AFTER_COMMIT | | rpl_semi_sync_slave_enabled | OFF | | rpl_semi_sync_slave_trace_level | 32 | +-------------------------------------------+------------+ 8 rows in set (0.01 sec)
#參數說明
rpl_semi_sync_master_enabled： 主服務器開啟半同步復制。
rpl_semi_sync_slave_enabled ： 從服務器開啟半同步復制。
rpl_semi_sync_master_timeout： 超過10s slave沒有回應，半同步復制會變為異步復制
rpl_semi_sync_master_trace_level：開啟半同步復制時的調試級別，默認是32.
rpl_semi_sync_master_wait_no_slave ：master的每個事務是否都需要slave的接收確認！
rpl_semi_sync_master_wait_for_slave_count：
rpl_semi_sync_master_wait_point： 最後兩個參數樹MySQL5.7加入的，半同步復制升級為無損復制。後面再說明
半同步復制具體特性：（摘自http://www.ywnds.com/?p=7023）
- 從庫會在連接到主庫時告訴主庫，它是不是配置了半同步。
- 如果半同步復制在主庫端是開啟了的，並且至少有一個半同步復制的從庫節點，那麽此時主庫的事務線程在提交後會被阻塞並等待。此時，等待的結果有兩種可能，要麽至少一個從庫節點通知它已經收到了所有這個事務的Binlog事件，要麽一直等待直到超過配置的某一個時間點為止。而此時，半同步復制將自動關閉，轉換為異步復制。
- 從庫節點只有在接收到某一個事務的所有Binlog，將其寫入並Flush到Relay Log文件之後，才會通知對應主庫上面的等待線程。
- 如果在等待過程中，等待時間已經超過了配置的超時時間，沒有任何一個從節點通知當前事務，那麽此時主庫會自動轉換為異步復制，當至少一個半同步從節點趕上來時，主庫便會自動轉換為半同步方式的復制。
- 半同步復制必須是在主庫和從庫兩端都開啟時才行，如果在主庫上沒打開，或者在主庫上開啟了而在從庫上沒有開啟，主庫都會使用異步方式復制。
通過上面幾點特征，可以知道半同步的實質是，在主庫被阻塞的過程中（等待從庫反饋確認消息），主庫處理線程不會返回去處理當前事務。當阻塞被激活之後，系統才會把控制權交給當前線程，然後繼續處理當前事務余下的事情。處理完成之後，此時主庫的事務已經提交，同時至少會有一個從庫也已經收到了這個事務的Binlog，這樣就盡可能地保證了主庫和從庫的數據一致性。
丟失一個事務：
上面我們提到過，半同步復制至多會丟失一個事務，也就是說當master已經提交了事務t1（事務t1已經在master上持久化了），這時候dump線程會推送二進制日誌給slave，如果在這個推送的過程中master主機crash掉了，這時候我們若想讓一臺slave來做master時，因為事務t1沒有在任何的一個slave上存在，也就是這時候事務t1丟失了！
事務的提交主要分為兩個主要步驟： 1. 準備階段（Storage Engine（InnoDB） Transaction Prepare Phase） 此時SQL已經成功執行，並生成xid信息及redo和undo的內存日誌。然後調用prepare方法完成第一階段，papare方法實際上什麽也沒做，將事務狀態設為TRX_PREPARED，並將redo log刷磁盤。 2. 提交階段(Storage Engine（InnoDB）Commit Phase) 2.1 記錄協調者日誌，即Binlog日誌。 如果事務涉及的所有存儲引擎的prepare都執行成功，則調用TC_LOG_BINLOG::log_xid方法將SQL語句寫到binlog（write()將binary log內存日誌數據寫入文件系統緩存，fsync()將binary log文件系統緩存日誌數據永久寫入磁盤）。此時，事務已經鐵定要提交了。否則，調用ha_rollback_trans方法回滾事務，而SQL語句實際上也不會寫到binlog。 2.2 告訴引擎做commit。 最後，調用引擎的commit完成事務的提交。會清除undo信息，刷redo日誌，將事務設為TRX_NOT_STARTED狀態。
半同步復制就是在2.2之後推送了二進制日誌到slave！
為了防止這一個事務的丟失，MySQL5.7引入了無損復制！
現在我們已經知道，在半同步環境下，主庫是在事務提交之後等待Slave ACK，所以才會有數據不一致問題。所以這個Slave ACK在什麽時間去等待，也是一個很關鍵的問題了。因此MySQL針對半同步復制的問題，在5.7.2版本引入了Loss-less Semi-Synchronous，在調用binlog sync之後，engine層commit之前等待Slave ACK。這樣只有在確認Slave收到事務Binlog後，事務才會提交。另外，在commit之前等待Slave ACK，同時可以堆積事務，利於Group Commit，有利於提升性能。
半同步復制與無損復制的主要區別在於半同步復制在InnoDB commit後等待Slave ACK（需要收到至少一個Slave節點回復的ACK），無損復制在binlog sync後與Slave確認。雖然都同樣避免不了數據丟失的風險，但是由於ack確認的位置不同，這樣就有一個大的區別在於其他事務是否看得見這個事務的修改操作，半同步復制由於在InnoDB commit後ack，此時事務已經提交，對其他事務可見，如果此時主庫宕機並發生主從切換，那麽用戶在新主庫找不到剛剛那個事務修改後的數據，就可以稱得上數據丟失了，因為用戶已經看見過。而無損復制由於在binlog sync後進行binlog發送和ack確認，此時由於事務並沒有提交，對於其他事務來說不可見，所以就算發生主從切換，新主庫雖然也沒有剛剛那個事務修改後的數據，但用戶並沒有看見新數據，所以也就稱不上數據丟失了。
需要註意的是無損復制，用戶提交的事務寫入了二進制日誌，但是進行commit提交；也就是MySQL5.7在crash recovery時，主動拋棄了這條可能引起數據庫不一致的事務！
兩個參數介紹：
rpl_semi_sync_master_wait_for_slave_count：
rpl_semi_sync_master_wait_point：
rpl_semi_sync_master_wait_for_slave_count： MySQL5.7之後加入的，多少個slave確認之後，主才繼續下一個二進制日誌推送。
rpl_semi_sync_master_wait_point：這個值有兩個取值，after-commit和after-sync; after-commit表示的半同步復制，after-sync表示的是無損復制！
半同步復制與無損復制的對比總結：
1. ACK的時間點不同
- 半同步復制在InnoDB層的Commit Log後等待ACK，主從切換會有數據丟失風險。
- 無損復制在MySQL Server層的Write binlog後等待ACK，主從切換不會有數據丟失風險，但是主從有不一致的風險。
2. 主從數據一致性
- 半同步復制意味著在Master節點上，這個剛剛提交的事務對數據庫的修改，對其他事務是可見的。因此，如果在等待Slave ACK的時候crash了，那麽會對其他事務出現幻讀，數據丟失。
- 無損復制在write binlog完成後，就傳輸binlog，但還沒有去寫commit log，意味著當前這個事務對數據庫的修改，其他事務也是不可見的。因此，不會出現幻讀，數據丟失風險。
因此5.7引入了無損復制（after_sync）模式，帶來的主要收益是解決after_commit導致的Master crash後數據丟失問題，因此在引入after_sync模式後，所有提交的數據已經都被復制，故障切換時數據一致性將得到提升。
中繼日誌的回放與寫入
SQL線程
當slave的SQL線程從中繼日誌回放一個事件時，第一會把這個事件在數據庫中進行回放，第二會把這個事件結束點二進制信息寫入relay-log.info文件中，如果每回放一個事件，就寫一次relay-log.info文件，因此磁盤的寫入速度比較慢，因此在並發較高的情況下，slave就會產生和主的延遲，MySQL引入了一個參數sync_relay_log_info，這個參數默認值是10000，表示回放10000次時把日誌點刷新入文件。
SQL線程回放了中繼日誌的1，2，3三個事件（這兩個事件已經寫入了從庫），但是在2，3兩個事件並沒有寫入relay_log_info_file文件，這時候如果slave服務器發生crash 重啟，這時候slave會重新去抓取2，3兩個事件，然後再執行就會發生1062錯誤。
造成這樣主要是因為，回放是寫入數據庫，而寫日誌點則是寫入file文件的，這兩個無法做到一致性。
如果把sync_relay_log_info設置為1時候，還是會有最後一個event重復執行的可能，並且會造成性能下降！
因此從mysql5.6開始：relay_log_info_repository可以設置為TABLE，把中繼日誌的回放，和中繼日誌信息的寫入放入表中，這樣可以把這兩個操作設置變成原子性的，就可以避免這種情況的發生！線上環境建議設置為TABLE。
mysql> show variables like "%relay%_log_info%"; +---------------------------+----------------+ | Variable_name | Value | +---------------------------+----------------+ | relay_log_info_file | relay-log.info | | relay_log_info_repository | FILE | #建議設置為table。 | sync_relay_log_info | 10000 | +---------------------------+----------------+ 3 rows in set (0.00 sec)
I/O線程
I/O線程會寫入master.info和relay-log-info,若是每拉一個event就寫一次，效率會很低，MySQL5.6引入了如下參數！
mysql> show variables like "%master_info%"; +------------------------+-------+ | Variable_name | Value | +------------------------+-------+ | master_info_repository | FILE | #這個建議設置為table，這樣的性能會比file性能高大概2倍左右 | sync_master_info | 10000 | #每拉10000次event寫入文件一次 +------------------------+-------+ 2 rows in set (0.00 sec)
master配置： binlog-do-db= binlog-ignore-db= max_binlog_szie=2048M binlog_format=ROW transaction-isolation=READ-COMMITTED expire_logs_days=7 server-id=111 binlog_cache_size= sysnc_binlog=1 # must set to 1, default is 0 innodb_flush_log_at_trx_commit=1 innodb_support_xa = 1 slave配置 log_slave_upates replicate-do-db replicate-ignore-db replicate-do-table replicate-ignore-table server-id master_info_ repository = TABLE relay_log_recovery = 1 #I/O thread crash safe relay_log_info_repository = TABLE # SQL thread crash safe read_only = 1 super_read_only = on #mysql5.7 加入的 relay_log_recovery=1主從復制的一些參數建議設置數值
mysql的復制