復(fù)制信息記錄表|全方位認(rèn)識(shí)mysql系統(tǒng)庫

在上一期《時(shí)區(qū)信息記錄表|全方位認(rèn)識(shí) MySQL 系統(tǒng)庫》中，我們?cè)敿?xì)介紹了mysql系統(tǒng)庫中的時(shí)區(qū)信息記錄表，本期我們將為大家?guī)硐盗械谄咂稄?fù)制信息記錄表|全方位認(rèn)識(shí) mysql 系統(tǒng)庫》，下面請(qǐng)跟隨我們一起開始 mysql 系統(tǒng)庫的系統(tǒng)學(xué)習(xí)之旅吧！

成都創(chuàng)新互聯(lián)公司是一家專業(yè)提供全州企業(yè)網(wǎng)站建設(shè),專注與成都網(wǎng)站建設(shè)、網(wǎng)站建設(shè)、H5高端網(wǎng)站建設(shè)、小程序制作等業(yè)務(wù)。10年已為全州眾多企業(yè)、政府機(jī)構(gòu)等服務(wù)。創(chuàng)新互聯(lián)專業(yè)的建站公司優(yōu)惠進(jìn)行中。

1、復(fù)制信息表概述

復(fù)制信息表用于在從庫在復(fù)制主庫的數(shù)據(jù)期間，用于保存從主庫轉(zhuǎn)發(fā)到從庫的二進(jìn)制日志事件、記錄有關(guān)中繼日志當(dāng)前狀態(tài)和位置的信息。一共有三種類型的日志，如下：

master.info文件或者mysql.slave_master_info表：用于保存從庫的IO線程連接主庫的連接狀態(tài)、帳號(hào)、IP、端口、密碼以及IO線程當(dāng)前讀取主庫binlog的file和position等信息（被稱為IO線程信息日志。默認(rèn)情況下，IO線程的連接信息和狀態(tài)保存在master.info文件中(默認(rèn)位置在datadir下，可以使用master_info_file選項(xiàng)執(zhí)行master.info文件路徑)，如果需要保存在mysql.slave_master_info表中，需要在server啟動(dòng)之前設(shè)置master-info-repository = TABLE）。
relay-log.info文件或者mysql.slave_relay_log_info表：從庫的IO線程從主庫獲取到最新的binlog事件信息會(huì)先寫入到從庫本地的relay log中，SQL線程再去讀取relay log解析并重放，而relay_log.info文件或者mysql.slave_relay_log_info表就是用于記錄最新的relay log的file和position以及SQL線程當(dāng)前重放的事件對(duì)應(yīng)主庫binlog的file和position（relay log即被稱為中繼日志，SQL線程位置被稱為SQL線程信息日志。默認(rèn)情況下，relay log的位置信息和SQL線程的位置信息保存在relay-log.info文件中(默認(rèn)位置在datadir下，可以使用relay_log_info_file選項(xiàng)執(zhí)行relay-log.info文件路徑)，如果需要保存在mysql.slave_relay_log_info表中，需要在server啟動(dòng)之前設(shè)置relay-log-info-repository = TABLE）。

設(shè)置relay_log_info_repository和master_info_repository設(shè)置為TABLE可以提高數(shù)據(jù)庫本身或者所在主機(jī)意外終止之后crash recovery的能力（這兩張表是innodb表，可以保證crash之后表中的位置信息不丟失），且可以保證數(shù)據(jù)一致性。

從庫crash時(shí)，SQL線程可能還有一部分relay log重放延遲，另外，IO線程的位置也可能正處于一個(gè)事務(wù)的中間，并不完整，所以必須在從庫上啟用參數(shù)relay-log-recovery=ON，啟用該參數(shù)之后，從庫crash recovery時(shí)會(huì)清理掉SQL線程未重放完成的relay log，并以SQL線程的位置為準(zhǔn)重置掉IO線程的位置重新從主庫請(qǐng)求。

這兩張表在數(shù)據(jù)庫實(shí)例啟動(dòng)時(shí)如果無法被mysqld初始化，則mysqld允許繼續(xù)啟動(dòng)，但會(huì)在錯(cuò)誤日志中寫入警告信息，這種情況在MySQL從不支持該表的版本升級(jí)到支持該表的版本時(shí)常常遇見。

PS：

不要嘗試手動(dòng)更新slave_master_info或slave_relay_log_info表，否則后果自負(fù)。
從庫中復(fù)制線程在持續(xù)工作時(shí)，不允許任何可能對(duì)這兩張表加寫鎖的語句執(zhí)行，但允許對(duì)這兩張表做只讀的語句執(zhí)行。

2、復(fù)制信息表詳解

由于本期所介紹的表中存放的復(fù)制信息，在我們?nèi)粘５臄?shù)據(jù)庫維護(hù)過程當(dāng)中尤其重要，所以，下文中會(huì)在每張表的介紹過程中適度進(jìn)行一些擴(kuò)展。

2.1. slave_master_info

該表提供查詢IO線程讀取主庫的位置信息，以及從庫連接主庫的IP、賬號(hào)、端口、密碼等信息。

下面是該表中存儲(chǔ)的信息內(nèi)容。

root@localhost : mysql 01:08:29> select * from slave_master_info\G;
*************************** 1. row ***************************
       Number_of_lines: 25
       Master_log_name: mysql-bin.000292
        Master_log_pos: 194
                  Host: 192.168.2.148
             User_name: qfsys
         User_password: letsg0
                  Port: 3306
         Connect_retry: 60
           Enabled_ssl: 0
                Ssl_ca:
            Ssl_capath:
              Ssl_cert:
            Ssl_cipher:
               Ssl_key:
Ssl_verify_server_cert: 0
             Heartbeat: 5
                  Bind:
    Ignored_server_ids: 0
                  Uuid: ec123678-5e26-11e7-9d38-000c295e08a0
           Retry_count: 86400
               Ssl_crl:
           Ssl_crlpath:
 Enabled_auto_position: 0
          Channel_name:
           Tls_version:
1 row in set (0.00 sec)

表字段與show slave status輸出字段、master.info文件中的行信息對(duì)應(yīng)關(guān)系及其表字段含義如下：

master.info文件中的行數(shù)	mysql.slave_master_info表字段	show slave status命令輸出字段	字段含義描述
1	Number_of_lines	[None]	表示master.info中的信息行數(shù)或者slave_master_info表中的信息字段數(shù)
2	Master_log_name	Master_Log_File	表示從庫IO線程當(dāng)前讀取主庫最新的binlog file名稱
3	Master_log_pos	Read_Master_Log_Pos	表示從庫IO線程當(dāng)前讀取主庫最新的binlog position
4	Host	Master_Host	表示從庫IO線程當(dāng)前正連接的主庫IO或者主機(jī)名
5	User_name	Master_User	表示從庫IO線程用于連接主庫用戶名
6	User_password	[None]	表示從庫IO線程用于連接主庫的用戶密碼
7	Port	Master_Port	表示從庫IO線程所連接主庫的網(wǎng)絡(luò)端口
8	Connect_retry	Connect_Retry	表示從庫IO線程斷線重連主庫的間隔時(shí)間，單位為秒，默認(rèn)值為60
9	Enabled_ssl	Master_SSL_Allowed	表示主從之間的連接是否支持SSL
10	Ssl_ca	Master_SSL_CA_File	表示CA(Certificate Authority )認(rèn)證文件名
11	Ssl_capath	Master_SSL_CA_Path	表示CA(Certificate Authority )認(rèn)證文件路徑
12	Ssl_cert	Master_SSL_Cert	表示SSL認(rèn)證證書文件名
13	Ssl_cipher	Master_SSL_Cipher	表示用于SSL連接握手中可能使用到的密碼列表
14	Ssl_key	Master_SSL_Key	表示SSL認(rèn)證的密鑰文件名
15	Ssl_verify_server_cert	Master_SSL_Verify_Server_Cert	表示是否需要校驗(yàn)server的證書
16	Heartbeat	[None]	表示主從之間的復(fù)制心跳包的間隔時(shí)間，單位為秒
17	Bind	Master_Bind	表示從庫可用于連接主庫的網(wǎng)絡(luò)接口，默認(rèn)為空
18	Ignored_server_ids	Replicate_Ignore_Server_Ids	表示從庫復(fù)制需要忽略哪些server-id，注意：這是一個(gè)列表，第一個(gè)數(shù)字表示需要忽略的實(shí)例server-id總數(shù)
19	Uuid	Master_UUID	表示主庫的UUID
20	Retry_count	Master_Retry_Count	表示從庫最大允許重連主庫的次數(shù)
21	Ssl_crl	[None]	SSL證書撤銷列表文件的路徑
22	Ssl_crl_path	[None]	包含ssl證書吊銷列表文件的目錄路徑
23	Enabled_auto_position	Auto_position	表示從庫是否啟用在主庫中自動(dòng)尋找位置的功能（使用1時(shí)啟動(dòng)自動(dòng)尋找位置，如果使用auto_position=0，則不會(huì)自耦東找位置）
24	Channel_name	Channel_name	表示從庫復(fù)制通道名稱，一個(gè)通道代表一個(gè)復(fù)制源
25	Tls_Version	Master_TLS_Version	表示在Master上的TLS版本號(hào)

2.2. slave_relay_log_info

該表提供查詢SQL線程重放的二進(jìn)制文件對(duì)應(yīng)的主庫位置和relay log當(dāng)前最新的位置。

下面是該表中存儲(chǔ)的信息內(nèi)容。

root@localhost : mysql 10:39:31> select * from slave_relay_log_info\G
*************************** 1. row ***************************
  Number_of_lines: 7
   Relay_log_name: /home/mysql/data/mysqldata1/relaylog/mysql-relay-bin.000205
    Relay_log_pos: 14097976
  Master_log_name: mysql-bin.000060
   Master_log_pos: 21996812
        Sql_delay: 0
Number_of_workers: 16
               Id: 1
     Channel_name:
1 row in set (0.00 sec)

表字段與show slave statu s輸出字段、relay-log.info文件中的行信息對(duì)應(yīng)關(guān)系及其表字段含義如下：

relay-log.info文件中的行數(shù)	mysql.slave_relay_log_info表字段	show slave status命令輸出字段	字段含義描述
1	Number_of_lines	[None]	表示relay-log.info中的信息行數(shù)或者slave_relay_log_info表中的信息字段數(shù)，用于版本化表定義
2	Relay_log_name	Relay_Log_File	表示當(dāng)前最新的relay log文件名稱
3	Relay_log_pos	Relay_Log_Pos	表示當(dāng)前最新的relay log文件對(duì)應(yīng)的最近一次完整接收的event的位置
4	Master_log_name	Relay_Master_Log_File	表示SQL線程當(dāng)前正在重放的中繼日志對(duì)應(yīng)的主庫binlog 文件名
5	Master_log_pos	Exec_Master_Log_Pos	表示SQL線程當(dāng)前正在重放的中繼日志對(duì)應(yīng)主庫binlog 文件中的位置
6	Sql_delay	SQL_Delay	表示延遲復(fù)制指定的從庫必須延遲主庫多少秒
7	Number_of_workers	[None]	表示從庫當(dāng)前并行復(fù)制有多少個(gè)worker線程
8	Id	[None]	用于內(nèi)部唯一標(biāo)記表中的每一行記錄，目前總是1
9	Channel_name	Channel_name	表示從庫復(fù)制通道名稱，用于多源復(fù)制，一個(gè)通道對(duì)應(yīng)一個(gè)主庫源

什么是中繼日志：

中繼日志(relay log)與二進(jìn)制日志(binlog，即，binary log)中，保存的event數(shù)據(jù)是一樣的(但中繼日志中還保存了更多的信息)，也是由一組包含描述數(shù)據(jù)庫變更的事件數(shù)據(jù)的文件組成，這些文件名后綴帶連續(xù)編號(hào)，此外，還有一個(gè)包含所有正在使用的中繼日志文件名稱的索引文件。
中繼日志中的數(shù)據(jù)存放格式與二進(jìn)制日志相同，都可以使用mysqlbinlog命令來提取數(shù)據(jù)，默認(rèn)情況下，中繼日志保存在datadir下，文件名格式為： host_name-relay-bin.nnnnnn，其中host_name是從庫服務(wù)器主機(jī)名，nnnnnn是文件后綴序列號(hào)。連續(xù)的中繼日志文件從000001開始的連續(xù)序列號(hào)創(chuàng)建。使用索引文件來跟蹤當(dāng)前正在使用的中繼日志文件。默認(rèn)的中繼日志索引文件名保存在datadir下，文件名格式為：host_name-relay-bin.index。
* 中繼日志文件和中繼日志索引文件名稱可分別使用--relay-log和--relay-log-index參數(shù)選項(xiàng)指定值覆蓋默認(rèn)值，如果文件名使用默認(rèn)值，則要注意主機(jī)名稱不能修改，否則會(huì)報(bào)無法打開中繼日志的錯(cuò)誤，建議使用參數(shù)選項(xiàng)指定固定的文件名稱前綴。如果已經(jīng)出現(xiàn)了這種情況發(fā)生報(bào)錯(cuò)了，那么需要修改index文件中的中繼日志文件名和datadir下的中繼日志文件名前綴為新的主機(jī)名，然后重啟從庫。

在什么情況下會(huì)產(chǎn)生新的中繼日志文件。

I/O線程啟動(dòng)時(shí)。
使用語句： FLUSH LOGS或mysqladmin flush-logs命令時(shí)。
當(dāng)前中繼日志文件的大小變得“太大”時(shí)，日志滾動(dòng)規(guī)則如下：
* 如果max_relay_log_size系統(tǒng)變量的值大于0，那么中繼日志按照此參數(shù)指定的大小進(jìn)行滾動(dòng)。
* 如果max_relay_log_size系統(tǒng)變量的值為0，則中繼日志按照max_binlog_size系統(tǒng)變量指定的大小進(jìn)行滾動(dòng)。

SQL線程在執(zhí)行完relay log之后，會(huì)自行決定何時(shí)清理掉這些已經(jīng)執(zhí)行完成的relay log文件，但如果使用FLUSH LOGS語句或mysqladmin flush-logs命令強(qiáng)制滾動(dòng)中繼日志時(shí)，SQL線程可能會(huì)同時(shí)清理掉已經(jīng)執(zhí)行完成的relay log文件。

2.3. slave_worker_info

該表提供查詢多線程復(fù)制時(shí)的worker線程狀態(tài)信息，與performance_schema.replication_applier_status_by_worker表的區(qū)別是： slave_worker_info表記錄worker線程重放的relay log和主庫binlog位置信息，而performance_schema.replication_applier_status_by_worker表記錄的是worker線程重放的GTID位置信息。

下面是該表中存儲(chǔ)的信息內(nèi)容。

root@localhost : mysql 01:09:39> select * from slave_worker_info limit 1\G;
*************************** 1. row ***************************
                        Id: 1
            Relay_log_name:
             Relay_log_pos: 0
           Master_log_name:
            Master_log_pos: 0
 Checkpoint_relay_log_name:
  Checkpoint_relay_log_pos: 0
Checkpoint_master_log_name:
 Checkpoint_master_log_pos: 0
          Checkpoint_seqno: 0
     Checkpoint_group_size: 64
   Checkpoint_group_bitmap:
              Channel_name:
1 row in set (0.00 sec)

表字段含義。

Id：表中數(shù)據(jù)的ID，也是worker線程的ID，對(duì)應(yīng)著performance_schema.replication_applier_status_by_worker表的WORKER_ID字段（如果復(fù)制停止，則該字段值仍然存在，不像performance_schema.replication_applier_status_by_worker表中THREAD_ID字段值會(huì)清空）。
Relay_log_name：每個(gè)worker線程當(dāng)前最新執(zhí)行到的relay log文件名。
Relay_log_pos：每個(gè)worker線程當(dāng)前最新執(zhí)行到的relay log文件中的position。
Master_log_name：每個(gè)worker線程當(dāng)前最新執(zhí)行到的主庫binary log文件名。
Master_log_pos：每個(gè)worker線程當(dāng)前最新執(zhí)行到的主庫binary log文件中的position。
Checkpoint_relay_log_name：每個(gè)worker線程最新檢查點(diǎn)的relay log文件名。
Checkpoint_relay_log_pos：每個(gè)worker線程最新檢查點(diǎn)的relay log文件中的position。
Checkpoint_master_log_name：每個(gè)worker線程最新檢查點(diǎn)對(duì)應(yīng)主庫的binary log文件名。
Checkpoint_master_log_pos：每個(gè)worker線程最新檢查點(diǎn)對(duì)應(yīng)主庫的binary log文件中的position。
Checkpoint_seqno：每個(gè)worker線程當(dāng)前最新執(zhí)行完成的事務(wù)號(hào)，這個(gè)事務(wù)號(hào)的大小值是相對(duì)于每個(gè)worker線程自己的最新檢查點(diǎn)而言的，并不是真正的事務(wù)號(hào)。
Checkpoint_group_size：表示每個(gè)worker線程的執(zhí)行隊(duì)列大于這個(gè)字段值時(shí)，就會(huì)觸發(fā)當(dāng)前worker線程執(zhí)行一次檢查點(diǎn)。
Checkpoint_group_bitmap：用于從庫crash之后recovery的關(guān)鍵值，它是一個(gè)位圖值，表示每個(gè)worker線程在自己的最新檢查點(diǎn)中已經(jīng)執(zhí)行的事務(wù)。
Channel_name：復(fù)制通道名稱，多主復(fù)制時(shí)，顯示指定的復(fù)制通道名稱，單主復(fù)制時(shí)該字段為空。

該表中記錄的內(nèi)容對(duì)從庫多線程復(fù)制crash recovery至關(guān)重要，所以下文對(duì)該表中記錄的內(nèi)容如何作用于crash recovery過程進(jìn)行一些必要的說明。

從庫多線程復(fù)制如何做復(fù)制分發(fā)。

我們知道在MySQL 5.7中加入了基于事務(wù)的并行復(fù)制(基于行)，主庫在binlog的GTID事件中新加入了last_commit和sequence_number標(biāo)記，用于表示在每個(gè)binlog中的每個(gè)group中的提交順序(每個(gè)binlog中重置這兩個(gè)計(jì)數(shù)標(biāo)記)，在每個(gè)給定的binlog中，每個(gè)group中的last_commit總是為上一個(gè)group中最大的sequence_number、總是為當(dāng)前group中最小的sequence_number - 1(在每個(gè)binlog中，last_commit總是從0開始計(jì)數(shù)，sequence_number總是從1開始計(jì)數(shù))。
從庫relay log中記錄的主庫binlog，不會(huì)改變主庫的server id、時(shí)間戳信息以及l(fā)ast_commit和sequence_number值，這樣，從庫SQL線程在執(zhí)行binlog重放時(shí)，就可以依據(jù)這些信息決定從庫是否需要嚴(yán)格按照主庫提交順序進(jìn)行提交（從庫重放的事務(wù)只是分發(fā)順序按照主庫提交順序，但是從庫自己在提交這些事務(wù)時(shí)是否按照主庫提交順序進(jìn)行提交，還需要看從庫自己的slave_preserve_commit_order變量設(shè)置，設(shè)置為1則嚴(yán)格按照relay log中的順序進(jìn)行提交，設(shè)置為0從庫會(huì)自行決定提交順序）。
SQL線程并行分發(fā)原理。

* SQL協(xié)調(diào)器線程讀取到一個(gè)新的事務(wù)，取出last_commit和sequence_number值。

* SQL協(xié)調(diào)器線程判斷取出的新事務(wù)的當(dāng)前l(fā)ast_commit是否大于當(dāng)前已執(zhí)行完成的sequence_number中的最小值（Low water mark，簡(jiǎn)稱LWM，也叫低水位線標(biāo)記）。

* 如果SQL協(xié)調(diào)器線程讀取到的當(dāng)前事務(wù)的last_commit大于當(dāng)前已執(zhí)行完成的sequence_number值，則說明上一個(gè)group中的事務(wù)還沒有全部執(zhí)行完成，此時(shí)SQL協(xié)調(diào)器線程需要等待所有的worker線程執(zhí)行完成上一個(gè)group中的事務(wù)，等待LWM變大，直到當(dāng)前讀取到的事務(wù)的last_commit與當(dāng)前已執(zhí)行完成的事務(wù)的最小sequence_number值相等才可以繼續(xù)分發(fā)新的事務(wù)給空閑的worker線程（并行復(fù)制是針對(duì)每個(gè)group內(nèi)的事務(wù)才可以并行復(fù)制，所以，group之間是串行的，一個(gè)group未執(zhí)行完成之前，下一個(gè)group的事務(wù)是需要進(jìn)行等待的。只有同一個(gè)group內(nèi)的事務(wù)之間才可以并行執(zhí)行。根據(jù)上文中的描述，每個(gè)group中的事務(wù)的last_commit總是為當(dāng)前group中最小的sequence_number - 1，即，如果SQL協(xié)調(diào)器線程讀取到的當(dāng)前事務(wù)的last_commit小于當(dāng)前已執(zhí)行完成事務(wù)的最小的sequence_number 就說明當(dāng)前所有worker線程正在執(zhí)行的事務(wù)處于同一個(gè)group中，那么也就是說SQL協(xié)調(diào)器線程可以繼續(xù)往下尋找空閑的worker線程進(jìn)行分發(fā)，否則SQL協(xié)調(diào)器線程就需要進(jìn)行等待）。

* SQL協(xié)調(diào)器線程通過統(tǒng)計(jì)worker線程返回的狀態(tài)信息，尋找一個(gè)空閑的worker線程，如果沒有空閑的線程，則SQL協(xié)調(diào)器線程需要進(jìn)行等待，知道找到一個(gè)空閑的worker線程為止（如果有多個(gè)worker線程，則SQL協(xié)調(diào)器線程隨機(jī)選擇一個(gè)空閑的worker線程進(jìn)行分發(fā)）。

* 將當(dāng)前讀取到的事務(wù)的binlog event分發(fā)給選定的空閑worker線程，之后worker線程會(huì)去應(yīng)用這個(gè)事務(wù)，然后SQL協(xié)調(diào)器線程繼續(xù)讀取新的binlog event（注意，SQL協(xié)調(diào)器線程分發(fā)是按照event為單位的，不是事務(wù)單位，所以，如果當(dāng)一個(gè)事務(wù)的第一個(gè)event分發(fā)給了給定worker線程之后，后續(xù)讀取到的新的event如果同屬于一個(gè)事務(wù)，則進(jìn)入下一個(gè)事務(wù)之前的所有event都會(huì)分發(fā)給同一個(gè)worker線程處理。當(dāng)一個(gè)事務(wù)中所有的binlog event組分發(fā)完成，讀取到下一個(gè)新的事務(wù)時(shí)，SQL協(xié)調(diào)器線程會(huì)重復(fù)以上判斷流程）。

從庫多線程復(fù)制的crash recovery。

從前面多線程復(fù)制分發(fā)的原理我們可以知道，處于同一個(gè)group中的事務(wù)是并行應(yīng)用的，且事務(wù)是隨機(jī)分配的，在從庫正常運(yùn)行過程當(dāng)中，如果任意掐一刻下去，那么所有worker線程正在執(zhí)行的事務(wù)中，哪些是已經(jīng)執(zhí)行完成的，哪些還未執(zhí)行完成其實(shí)是無法使用單個(gè)位置來確定（因?yàn)閺膸觳⑿袕?fù)制時(shí)有可能是亂序提交：需要看slave_preserve_commit_order變量如何設(shè)置），也就是說所有worker線程中正在執(zhí)行的最大位置和最小位置之間可能有斷點(diǎn)。那MySQL是如何解決從庫crash recovery的斷點(diǎn)續(xù)做問題的呢？
MySQL 為了解決這個(gè)問題，對(duì)worker線程的執(zhí)行狀態(tài)做了很多記錄工作，首先，維護(hù)了一個(gè)隊(duì)列，這個(gè)隊(duì)列叫做GAQ（Group Assigned Queue），當(dāng)SQL協(xié)調(diào)器線程在分配某一個(gè)事務(wù)時(shí)，首先會(huì)將這個(gè)事務(wù)加入到這個(gè)隊(duì)列，然后，才會(huì)去按照規(guī)則來尋找一個(gè)空閑的worker線程來執(zhí)行，如下圖（鄭重聲明：該圖來自書籍《MySQL 運(yùn)維內(nèi)參》）：

每一個(gè)事務(wù)在分發(fā)到worker線程之后，都會(huì)分配一個(gè)編號(hào)，這個(gè)編號(hào)在某一段時(shí)間內(nèi)，都是相對(duì)固定的，這個(gè)編號(hào)一旦被分配，就不會(huì)再改變。在事務(wù)被某個(gè)worker線程執(zhí)行完成之后，它的位置信息就會(huì)被flush一次，這與5.5版本中的relay_log_info記錄的原理是類似的（relay_log_info中存放了從庫當(dāng)前SQL線程重放的位置），但是現(xiàn)在是多線程，每個(gè)worker線程的執(zhí)行位置不能直接存放在relay_log_info中了，relay_log_info中存放的是所有worker線程匯總之后的位置，每個(gè)worker線程獨(dú)立的位置信息存放在了mysql.slave_worker_info表中，在該表中，有多少個(gè)并行復(fù)制線程，就有多少行記錄（如果是多主復(fù)制，則每個(gè)復(fù)制通道都有slave_parallel_workers變量指定的記錄數(shù)）。

mysql.slave_worker_info表中，Checkpoint開頭的字段記錄了每個(gè)worker線程的檢查點(diǎn)相關(guān)的信息（這里與innodb存儲(chǔ)引擎的檢查點(diǎn)不同，但是概念相通），worker線程的檢查點(diǎn)的作用是什么呢？

前面說了SQL協(xié)調(diào)器線程在分配事務(wù)給worker線程之前會(huì)將事務(wù)先存放到GAQ隊(duì)列中，但是這個(gè)隊(duì)列的長度是有限的（是不是很熟悉？跟redo log的總大小是有限的概念類似），不可能無限制的增長下去，所以必須要在這個(gè)隊(duì)列中，找到一個(gè)位置點(diǎn)，這個(gè)位置點(diǎn)就是GAQ的起點(diǎn)位置，這個(gè)位置點(diǎn)之前的binlog就表示已經(jīng)執(zhí)行完成了。確定這個(gè)位置的過程，就叫做檢查點(diǎn)。在多線程復(fù)制的執(zhí)行過程中，隨著每個(gè)worker線程不斷第應(yīng)用事務(wù)的binlog，檢查點(diǎn)在GAQ中被不斷地向前推進(jìn)，每個(gè)worker線程通過Checkpoint_point_bitmap字段記錄自己已經(jīng)執(zhí)行過的事務(wù)和每個(gè)已執(zhí)行事務(wù)與之對(duì)應(yīng)的當(dāng)時(shí)的最新檢查點(diǎn)的相對(duì)位置，這樣一來，當(dāng)復(fù)制意外終端之后，重新開始復(fù)制時(shí)，就可以通過所有的worker線程記錄的Checkpoint_point_bitmap字段來計(jì)算出哪些事務(wù)是已經(jīng)執(zhí)行過的，哪些事務(wù)是還未執(zhí)行的，即通過所有worker線程記錄的Checkpoint_point_bitmap信息執(zhí)行一次檢查點(diǎn)操作就可以找到一個(gè)合適的恢復(fù)位置，執(zhí)行檢查點(diǎn)的大概過程如下（注意：這里是執(zhí)行檢查點(diǎn)的過程，與從庫crash recovery過程無關(guān)）：

* 在GAQ隊(duì)列中，從尾部開始掃描，如果是已經(jīng)執(zhí)行過的事務(wù)，則直接將其從隊(duì)列中刪除。

* 持續(xù)掃描GAQ隊(duì)列，直到找到一個(gè)未執(zhí)行過的事務(wù)為止即停止掃描。

* 上述步驟中掃描動(dòng)作停止前掃描到的最后一個(gè)事務(wù)被確定為檢查點(diǎn)的最新位置，并且別標(biāo)記為LWM（低水位線標(biāo)記）。

* 將當(dāng)前LWM這個(gè)事務(wù)對(duì)應(yīng)的位置(master_log_pos和relay_log_pos位置)設(shè)置為此次檢查點(diǎn)對(duì)應(yīng)的位置。

* 通過所有的worker線程檢查自己的檢查點(diǎn)，也就是查看每個(gè)worker線程自己的Checkpoint_seqno字段值，這個(gè)字段值是每個(gè)worker線程在執(zhí)行事務(wù)提交時(shí)更新的，更新的字段值為每個(gè)worker線程在做事務(wù)提交時(shí)對(duì)應(yīng)的最新檢查點(diǎn)的相對(duì)位置。

* 將本次執(zhí)行檢查點(diǎn)的位置記錄到mysql.slave_relay_log_info表中，作為全局bin log應(yīng)用的位置。
現(xiàn)在，我們來看從庫crash recovery的過程：

* 首先，讀取mysql.slave_master_info、mysql.slave_relay_log_info、mysql.slave_worker_info表中的信息讀取出來，從mysql.slave_master_info表中找到連接主庫的信息，從mysql.slave_relay_log_info表中找到全局最新的復(fù)制位置以及worker線程個(gè)數(shù)，從mysql.slave_worker_info表中找到每一個(gè)worker線程對(duì)應(yīng)的復(fù)制信息位置。

* 然后，根據(jù)mysql.slave_relay_log_info表中的位置（這個(gè)位置就是全局最新的檢查點(diǎn)位置）為準(zhǔn)來判斷所有worker線程的位置，在這個(gè)位置之前的worker線程位置就表示已經(jīng)執(zhí)行過的了，直接剔除，在這個(gè)位置之后的worker線程位置就表示這些事務(wù)是還沒有執(zhí)行過的（根據(jù)每個(gè)worker線程在mysql.slave_worker_info表中記錄的Checkpoint_seqno和Checkpoint_group_bitmap字段計(jì)算出自己哪些事務(wù)沒有執(zhí)行過，然后通過每個(gè)worker線程在mysql.slave_worker_info表中記錄的其他checkpoint字段信息轉(zhuǎn)換為對(duì)應(yīng)的全局檢查點(diǎn)的位置。然后根據(jù)所有worker線程的轉(zhuǎn)換位置信息匯總為一個(gè)共同的bitmap，根據(jù)這個(gè)共同的bitmap來比對(duì)mysql.slave_relay_log_info表中的位置就可以提取出哪些事務(wù)還沒有執(zhí)行過），找出了哪些事務(wù)還沒有執(zhí)行之后，把這些事務(wù)串行地一個(gè)一個(gè)地去重新應(yīng)用（應(yīng)用一個(gè)更新一次mysql.slave_relay_log_info表，為什么要串行，這是為了在恢復(fù)過程中如果再次跪了，還可以正確地恢復(fù)位置），應(yīng)用完成之后清空mysql.slave_worker_info表。然后啟動(dòng)復(fù)制線程，繼續(xù)從主庫拉取最新的binlog進(jìn)行數(shù)據(jù)復(fù)制。

PS：如果在主從復(fù)制架構(gòu)中，有2個(gè)以上的從庫，且從庫永遠(yuǎn)不做提升主庫的操作時(shí)，可以使用如下方法優(yōu)化從庫延遲（在該場(chǎng)景下，從庫無需擔(dān)心數(shù)據(jù)丟失問題，因?yàn)橛辛硗庖粋€(gè)從庫兜底+不做主從切換，只需要專心提供快速應(yīng)用主庫binlog與只讀業(yè)務(wù)即可）。

關(guān)閉log_slave_updates參數(shù)，減少從庫binlog寫入量（如果不做級(jí)聯(lián)復(fù)制甚至可以同時(shí)關(guān)閉binlog）。
設(shè)置innodb_flush_log_at_trx_commit為0或者2，減少事務(wù)提交時(shí)redo log的等待頻率。
設(shè)置sync_binlog為默認(rèn)值或者更大的值，減少事務(wù)提交時(shí)binlog的等待頻率。
設(shè)置slave_preserve_commit_order參數(shù)為OFF（默認(rèn)為OFF，設(shè)置為ON時(shí)要求開啟binlog和log_slave_updates參數(shù)），減少事務(wù)嚴(yán)格按照主庫順序提交時(shí)的提交等待時(shí)間。

2.4. gtid_executed

前面介紹的三張表中，存放的都不包括GTID信息，在數(shù)據(jù)庫運(yùn)行過程中，GTID相關(guān)的信息是保存在performance_schema下的相關(guān)表中，詳見"全方位認(rèn)識(shí) performance_schema"系列文章《復(fù)制狀態(tài)與變量記錄表 | performance_schema全方位介紹》。但是performance_schema下的表都是內(nèi)存表，記錄的信息是易失的。gtid_executed表才是GTID信息的持久表，該表提供查詢與當(dāng)前實(shí)例中的數(shù)據(jù)一致的GTID集合（該表用于存儲(chǔ)所有事務(wù)分配的 GTID集合，GTID集合由UUID集合構(gòu)成，每個(gè)UUID集合的組成為：uuid:interval[:interval]...，例如：28b13b49-3dfb-11e8-a76d-5254002a54f2:1-600401, 3ff62ef2-3dfb-11e8-a448-525400c33752:1-110133）

GTID是在整個(gè)復(fù)制拓?fù)渲惺侨治ㄒ坏?，GTID中的事務(wù)號(hào)是一個(gè)單調(diào)遞增的無間隙數(shù)字。正常情況下，客戶端的數(shù)據(jù)修改在執(zhí)行commit時(shí)會(huì)分配一個(gè)GTID，且會(huì)記錄到binlog中，這些GTID通過復(fù)制組件在其他實(shí)例中進(jìn)行重放時(shí)也會(huì)保留GTID來源不變。但是如果客戶端自行使用sql_log_bin變量關(guān)閉了binlog記錄或者客戶端執(zhí)行的是一個(gè)只讀事務(wù)，那么server不會(huì)分配GTID，在binlog中也不會(huì)有GTID記錄。
當(dāng)某個(gè)從庫接受到自己的GTID集合中已經(jīng)包含的GTID時(shí)，會(huì)忽略這個(gè)已存在的GTID，并且不會(huì)報(bào)錯(cuò)，事務(wù)也不會(huì)被執(zhí)行。

從MySQL 5.7.5開始，GTID存儲(chǔ)在mysql數(shù)據(jù)庫的名為gtid_executed的表中。對(duì)于每個(gè)GTID集合，默認(rèn)情況下值記錄每個(gè)GTID集合的起始和結(jié)束的事務(wù)號(hào)對(duì)應(yīng)的GTID，該表只在數(shù)據(jù)庫初始化或者執(zhí)行update_grade升級(jí)的時(shí)候創(chuàng)建，不允許手工創(chuàng)建于修改。當(dāng)實(shí)例本身有客戶端訪問數(shù)據(jù)寫入或者有從其他主庫通過復(fù)制插件同步數(shù)據(jù)的時(shí)候，該表中會(huì)有新的GTID記錄寫入，另外，該表中的記錄還會(huì)在binlog滾動(dòng)或者實(shí)例重啟的時(shí)候被更新（日志滾動(dòng)時(shí)該表需要把除了最新的binlog之外其他binlog中的所有GTID結(jié)合記錄到該表中，實(shí)例重啟時(shí)，需要把所有的binlog中的GTID集合記錄到該表中）。

由于有mysql.gtid_executed表記錄GTID（避免了binlog丟失的時(shí)候丟失GTID歷史記錄），所以，從5.7.5版本開始，在復(fù)制拓?fù)渲械膹膸煸试S關(guān)閉binlog，也允許在binlog開啟的情況下關(guān)閉log_slave_updates變量。

由于GTID必須要再gtid_mode為ON或者為ON_PERMISSIVE時(shí)才會(huì)生成，所以自然該表中的記錄也需要依賴于gtid_mode變量為ON或ON_PERMISSIVE時(shí)才會(huì)進(jìn)行記錄，另外，該表中是否實(shí)時(shí)存儲(chǔ)GTID，取決于binlog日志是否開啟，或者binlog啟用時(shí)是否啟用log_slave_updates變量，如下：

當(dāng)禁用二進(jìn)制日志記錄（log_bin為OFF），或者啟用binlog但禁用log_slave_updates，則Server會(huì)在每個(gè)事物提交時(shí)把屬于該事物的GTID同時(shí)更新到該表中。此時(shí)，該表的GTID周期性自動(dòng)壓縮功能激活，每達(dá)到gtid_executed_compression_period系統(tǒng)變量指定的事物數(shù)量壓縮一次該表中的GTID集合(也就是把每個(gè)UUID對(duì)應(yīng)的事務(wù)號(hào)的記錄取一個(gè)最大值，取一個(gè)最小值，刪除中間值)，要注意：周期性自動(dòng)壓縮功能僅針對(duì)從庫，對(duì)主庫無效，因?yàn)橹鲙毂仨殕⒂胋inlog，且log_slave_updates參數(shù)不影響主庫。
如果啟用二進(jìn)制日志記錄（log_bin為ON）且log_slave_updates參數(shù)也啟用，則周期性自動(dòng)壓縮功能失效，該表中的記錄只會(huì)在binlog日志滾動(dòng)或者服務(wù)器關(guān)閉時(shí)才會(huì)進(jìn)行壓縮，且會(huì)把除了最后一個(gè)binlog之外，其他所有binlog中包含的GTID集合寫入該表中。
注意：

* 如果啟用二進(jìn)制日志記錄（log_bin為ON）且log_slave_updates參數(shù)也啟用，那么該表不會(huì)實(shí)時(shí)記錄GTID，也就是說，完整的GTID集合，有一部分記錄在該表中，有一部分是記錄在binlog中的，如果一旦server發(fā)生crash，那么在crash recovery時(shí)會(huì)讀取binlog中最新的GTID集合并合并到該表中。

* 該表中的記錄在執(zhí)行reset master語句時(shí)會(huì)被清空。

該表中的記錄周期性執(zhí)行壓縮示例。

# 假設(shè)表中有如下實(shí)時(shí)記錄的GTID記錄
mysql> SELECT * FROM mysql.gtid_executed;
+ -------------------------------------- + ---------- ------ + -------------- +
| source_uuid | interval_start | interval_end |
| -------------------------------------- + ---------- ------ + -------------- |
| 3E11FA47-71CA-11E1-9E33-C80AA9429562 | 37 | 37 |
| 3E11FA47-71CA-11E1-9E33-C80AA9429562 | 38 | 38 |
| 3E11FA47-71CA-11E1-9E33-C80AA9429562 | 39 | 39 |
| 3E11FA47-71CA-11E1-9E33-C80AA9429562 | 40 | 40 |
| 3E11FA47-71CA-11E1-9E33-C80AA9429562 | 41 | 41 |
| 3E11FA47-71CA-11E1-9E33-C80AA9429562 | 42 | 42 |
| 3E11FA47-71CA-11E1-9E33-C80AA9429562 | 43 | 43 |
...
# 那么，每達(dá)到gtid_executed_compression_period變量定義的事務(wù)個(gè)數(shù)時(shí)，激活壓縮功能，GTID被壓縮為一行記錄，如下
+ -------------------------------------- + ---------- ------ + -------------- +
| source_uuid | interval_start | interval_end |
| -------------------------------------- + ---------- ------ + -------------- |
| 3E11FA47-71CA-11E1-9E33-C80AA9429562 | 37 | 43 |
...
# 注意：當(dāng)gtid_executed_compression_period系統(tǒng)變量設(shè)置為0時(shí)，周期性自動(dòng)壓縮功能失效，你需要預(yù)防該表被撐爆的風(fēng)險(xiǎn)

表字段含義。

source_uuid：代表數(shù)據(jù)來源的GTID集合。
interval_start：每個(gè)UUID集合的最小事務(wù)號(hào)。
interval_end：每個(gè)UUID集合的最大事務(wù)號(hào)。

對(duì)該表的壓縮功能由名為 thread/sql/compress_gtid_table 的專用前臺(tái)線程執(zhí)行。該線程使用SHOW PROCESSLIST無法查看，但它可以在performance_schema.threads表中查看到(線程 thread/sql/compress_gtid_table 大多數(shù)時(shí)候都處于休眠狀態(tài)，直到每滿gtid_executed_compression_period個(gè)事務(wù)之后，該線程被喚醒以執(zhí)行前面所述的對(duì)mysql.gtid_executed表的壓縮。然后繼續(xù)進(jìn)入睡眠狀態(tài)，直到下一次滿gtid_executed_compression_period個(gè)事務(wù)，然后被喚醒再次執(zhí)行壓縮，以此類推，無限重復(fù)此循環(huán)。但如果當(dāng)關(guān)閉binlog或者啟用binlog但關(guān)閉log_slave_updates變量時(shí)，gtid_executed_compression_period變量被設(shè)置為了0，那么意味著該線程會(huì)始終處于休眠狀態(tài)且永不會(huì)喚醒)，如下所示：

mysql> SELECT * FROM performance_schema.threads WHERE NAME LIKE '%gtid%'\G
*************************** 1. row ***************************
          THREAD_ID: 26
               NAME: thread/sql/compress_gtid_table
               TYPE: FOREGROUND
     PROCESSLIST_ID: 1
   PROCESSLIST_USER: NULL
   PROCESSLIST_HOST: NULL
     PROCESSLIST_DB: NULL
PROCESSLIST_COMMAND: Daemon
   PROCESSLIST_TIME: 1509
  PROCESSLIST_STATE: Suspending
   PROCESSLIST_INFO: NULL
   PARENT_THREAD_ID: 1
               ROLE: NULL
       INSTRUMENTED: YES
            HISTORY: YES
    CONNECTION_TYPE: NULL
       THREAD_OS_ID: 18677

2.5. ndb_binlog_index

該表提供查詢ndb集群引擎相關(guān)的統(tǒng)計(jì)信息，由于國內(nèi)較少使用NDB存儲(chǔ)引擎，這里不做過多介紹，有興趣的朋友可自行研究。

本期內(nèi)容就介紹到這里，本期內(nèi)容參考鏈接如下：

https://dev.mysql.com/doc/refman/5.7/en/replication-gtids-concepts.html#replication-gtids-gtid-executed-table

"翻過這座山，你就可以看到一片海！ "。堅(jiān)持閱讀我們的"全方位認(rèn)識(shí) mysql 系統(tǒng)庫"系列文章分享，你就可以系統(tǒng)地學(xué)完它。謝謝你的閱讀，我們下期不見不散！

| 作者簡(jiǎn)介

羅小波·沃趣科技高級(jí)數(shù)據(jù)庫技術(shù)專家

IT從業(yè)多年，主要負(fù)責(zé)MySQL 產(chǎn)品的數(shù)據(jù)庫支撐與售后二線支撐。曾參與版本發(fā)布系統(tǒng)、輕量級(jí)監(jiān)控系統(tǒng)、運(yùn)維管理平臺(tái)、數(shù)據(jù)庫管理平臺(tái)的設(shè)計(jì)與編寫，熟悉MySQL體系結(jié)構(gòu)，Innodb存儲(chǔ)引擎，喜好專研開源技術(shù)，多次在公開場(chǎng)合做過線下線上數(shù)據(jù)庫專題分享，發(fā)表過多篇數(shù)據(jù)庫相關(guān)的研究文章。

網(wǎng)站題目：復(fù)制信息記錄表|全方位認(rèn)識(shí)mysql系統(tǒng)庫
網(wǎng)頁路徑：http://muchs.cn/article36/pgdesg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供移動(dòng)網(wǎng)站建設(shè)、全網(wǎng)營銷推廣、虛擬主機(jī)、用戶體驗(yàn)、微信小程序、網(wǎng)站收錄

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源：創(chuàng)新互聯(lián)

猜你還喜歡下面的內(nèi)容

復(fù)制信息記錄表|全方位認(rèn)識(shí)mysql系統(tǒng)庫

2.1. slave_master_info

該表提供查詢IO線程讀取主庫的位置信息，以及從庫連接主庫的IP、賬號(hào)、端口、密碼等信息。

下面是該表中存儲(chǔ)的信息內(nèi)容。

表字段與show slave status輸出字段、master.info文件中的行信息對(duì)應(yīng)關(guān)系及其表字段含義如下：

2.2. slave_relay_log_info

該表提供查詢SQL線程重放的二進(jìn)制文件對(duì)應(yīng)的主庫位置和relay log當(dāng)前最新的位置。

下面是該表中存儲(chǔ)的信息內(nèi)容。

表字段與show slave statu s輸出字段、relay-log.info文件中的行信息對(duì)應(yīng)關(guān)系及其表字段含義如下：

2.3. slave_worker_info

下面是該表中存儲(chǔ)的信息內(nèi)容。

表字段含義。

Relay_log_name： 每個(gè)worker線程當(dāng)前最新執(zhí)行到的relay log文件名。

Relay_log_pos： 每個(gè)worker線程當(dāng)前最新執(zhí)行到的relay log文件中的position。

Master_log_name： 每個(gè)worker線程當(dāng)前最新執(zhí)行到的主庫binary log文件名。

Master_log_pos： 每個(gè)worker線程當(dāng)前最新執(zhí)行到的主庫binary log文件中的position。

Checkpoint_relay_log_name： 每個(gè)worker線程最新檢查點(diǎn)的relay log文件名。

Checkpoint_relay_log_pos： 每個(gè)worker線程最新檢查點(diǎn)的relay log文件中的position。

Checkpoint_master_log_name： 每個(gè)worker線程最新檢查點(diǎn)對(duì)應(yīng)主庫的binary log文件名。

Checkpoint_master_log_pos： 每個(gè)worker線程最新檢查點(diǎn)對(duì)應(yīng)主庫的binary log文件中的position。

Checkpoint_seqno： 每個(gè)worker線程當(dāng)前最新執(zhí)行完成的事務(wù)號(hào)，這個(gè)事務(wù)號(hào)的大小值是相對(duì)于每個(gè)worker線程自己的最新檢查點(diǎn)而言的，并不是真正的事務(wù)號(hào)。

Checkpoint_group_size： 表示每個(gè)worker線程的執(zhí)行隊(duì)列大于這個(gè)字段值時(shí)，就會(huì)觸發(fā)當(dāng)前worker線程執(zhí)行一次檢查點(diǎn)。

Checkpoint_group_bitmap： 用于從庫crash之后recovery的關(guān)鍵值，它是一個(gè)位圖值，表示每個(gè)worker線程在自己的最新檢查點(diǎn)中已經(jīng)執(zhí)行的事務(wù)。

Channel_name： 復(fù)制通道名稱，多主復(fù)制時(shí)，顯示指定的復(fù)制通道名稱，單主復(fù)制時(shí)該字段為空。

該表中記錄的內(nèi)容對(duì)從庫多線程復(fù)制crash recovery至關(guān)重要，所以下文對(duì)該表中記錄的內(nèi)容如何作用于crash recovery過程進(jìn)行一些必要的說明。

從庫多線程復(fù)制如何做復(fù)制分發(fā)。

SQL線程并行分發(fā)原理。

* SQL協(xié)調(diào)器線程讀取到一個(gè)新的事務(wù)，取出last_commit和sequence_number值。

* SQL協(xié)調(diào)器線程判斷取出的新事務(wù)的當(dāng)前l(fā)ast_commit是否大于當(dāng)前已執(zhí)行完成的sequence_number中的最小值（Low water mark，簡(jiǎn)稱LWM，也叫低水位線標(biāo)記）。

從庫多線程復(fù)制的crash recovery。

mysql.slave_worker_info表中，Checkpoint開頭的字段記錄了每個(gè)worker線程的檢查點(diǎn)相關(guān)的信息（這里與innodb存儲(chǔ)引擎的檢查點(diǎn)不同，但是概念相通），worker線程的檢查點(diǎn)的作用是什么呢？

* 在GAQ隊(duì)列中，從尾部開始掃描，如果是已經(jīng)執(zhí)行過的事務(wù)，則直接將其從隊(duì)列中刪除。

* 持續(xù)掃描GAQ隊(duì)列，直到找到一個(gè)未執(zhí)行過的事務(wù)為止即停止掃描。

* 上述步驟中掃描動(dòng)作停止前掃描到的最后一個(gè)事務(wù)被確定為檢查點(diǎn)的最新位置，并且別標(biāo)記為LWM（低水位線標(biāo)記）。

* 將當(dāng)前LWM這個(gè)事務(wù)對(duì)應(yīng)的位置(master_log_pos和relay_log_pos位置)設(shè)置為此次檢查點(diǎn)對(duì)應(yīng)的位置。

* 將本次執(zhí)行檢查點(diǎn)的位置記錄到mysql.slave_relay_log_info表中，作為全局bin log應(yīng)用的位置。

現(xiàn)在，我們來看從庫crash recovery的過程：

關(guān)閉log_slave_updates參數(shù)，減少從庫binlog寫入量（如果不做級(jí)聯(lián)復(fù)制甚至可以同時(shí)關(guān)閉binlog）。

設(shè)置innodb_flush_log_at_trx_commit為0或者2，減少事務(wù)提交時(shí)redo log的等待頻率。

設(shè)置sync_binlog為默認(rèn)值或者更大的值，減少事務(wù)提交時(shí)binlog的等待頻率。

設(shè)置slave_preserve_commit_order參數(shù)為OFF（默認(rèn)為OFF，設(shè)置為ON時(shí)要求開啟binlog和log_slave_updates參數(shù)），減少事務(wù)嚴(yán)格按照主庫順序提交時(shí)的提交等待時(shí)間。

2.4. gtid_executed

當(dāng)某個(gè)從庫接受到自己的GTID集合中已經(jīng)包含的GTID時(shí)，會(huì)忽略這個(gè)已存在的GTID，并且不會(huì)報(bào)錯(cuò)，事務(wù)也不會(huì)被執(zhí)行。

由于有mysql.gtid_executed表記錄GTID（避免了binlog丟失的時(shí)候丟失GTID歷史記錄），所以，從5.7.5版本開始，在復(fù)制拓?fù)渲械膹膸煸试S關(guān)閉binlog，也允許在binlog開啟的情況下關(guān)閉log_slave_updates變量。

注意：

* 該表中的記錄在執(zhí)行reset master語句時(shí)會(huì)被清空。

該表中的記錄周期性執(zhí)行壓縮示例。

表字段含義。

source_uuid： 代表數(shù)據(jù)來源的GTID集合。

interval_start： 每個(gè)UUID集合的最小事務(wù)號(hào)。

interval_end： 每個(gè)UUID集合的最大事務(wù)號(hào)。

2.5. ndb_binlog_index

該表提供查詢ndb集群引擎相關(guān)的統(tǒng)計(jì)信息，由于國內(nèi)較少使用NDB存儲(chǔ)引擎，這里不做過多介紹，有興趣的朋友可自行研究。

本期內(nèi)容就介紹到這里，本期內(nèi)容參考鏈接如下：

https://dev.mysql.com/doc/refman/5.7/en/replication-gtids-concepts.html#replication-gtids-gtid-executed-table

該表提供查詢IO線程讀取主庫的位置信息，以及從庫連接主庫的IP、賬號(hào)、端口、密碼等信息。

下面是該表中存儲(chǔ)的信息內(nèi)容。

該表提供查詢SQL線程重放的二進(jìn)制文件對(duì)應(yīng)的主庫位置和relay log當(dāng)前最新的位置。

下面是該表中存儲(chǔ)的信息內(nèi)容。

表字段與show slave statu s輸出字段、relay-log.info文件中的行信息對(duì)應(yīng)關(guān)系及其表字段含義如下：

表字段含義。

Relay_log_name：每個(gè)worker線程當(dāng)前最新執(zhí)行到的relay log文件名。

Relay_log_pos：每個(gè)worker線程當(dāng)前最新執(zhí)行到的relay log文件中的position。

Master_log_name：每個(gè)worker線程當(dāng)前最新執(zhí)行到的主庫binary log文件名。

Master_log_pos：每個(gè)worker線程當(dāng)前最新執(zhí)行到的主庫binary log文件中的position。

Checkpoint_relay_log_name：每個(gè)worker線程最新檢查點(diǎn)的relay log文件名。

Checkpoint_relay_log_pos：每個(gè)worker線程最新檢查點(diǎn)的relay log文件中的position。

Checkpoint_master_log_name：每個(gè)worker線程最新檢查點(diǎn)對(duì)應(yīng)主庫的binary log文件名。

Checkpoint_master_log_pos：每個(gè)worker線程最新檢查點(diǎn)對(duì)應(yīng)主庫的binary log文件中的position。

Checkpoint_seqno：每個(gè)worker線程當(dāng)前最新執(zhí)行完成的事務(wù)號(hào)，這個(gè)事務(wù)號(hào)的大小值是相對(duì)于每個(gè)worker線程自己的最新檢查點(diǎn)而言的，并不是真正的事務(wù)號(hào)。

Checkpoint_group_size：表示每個(gè)worker線程的執(zhí)行隊(duì)列大于這個(gè)字段值時(shí)，就會(huì)觸發(fā)當(dāng)前worker線程執(zhí)行一次檢查點(diǎn)。

Checkpoint_group_bitmap：用于從庫crash之后recovery的關(guān)鍵值，它是一個(gè)位圖值，表示每個(gè)worker線程在自己的最新檢查點(diǎn)中已經(jīng)執(zhí)行的事務(wù)。

Channel_name：復(fù)制通道名稱，多主復(fù)制時(shí)，顯示指定的復(fù)制通道名稱，單主復(fù)制時(shí)該字段為空。

該表中記錄的內(nèi)容對(duì)從庫多線程復(fù)制crash recovery至關(guān)重要，所以下文對(duì)該表中記錄的內(nèi)容如何作用于crash recovery過程進(jìn)行一些必要的說明。

從庫多線程復(fù)制如何做復(fù)制分發(fā)。

SQL線程并行分發(fā)原理。

* SQL協(xié)調(diào)器線程讀取到一個(gè)新的事務(wù)，取出last_commit和sequence_number值。

* SQL協(xié)調(diào)器線程判斷取出的新事務(wù)的當(dāng)前l(fā)ast_commit是否大于當(dāng)前已執(zhí)行完成的sequence_number中的最小值（Low water mark，簡(jiǎn)稱LWM，也叫低水位線標(biāo)記）。

從庫多線程復(fù)制的crash recovery。

mysql.slave_worker_info表中，Checkpoint開頭的字段記錄了每個(gè)worker線程的檢查點(diǎn)相關(guān)的信息（這里與innodb存儲(chǔ)引擎的檢查點(diǎn)不同，但是概念相通），worker線程的檢查點(diǎn)的作用是什么呢？

* 在GAQ隊(duì)列中，從尾部開始掃描，如果是已經(jīng)執(zhí)行過的事務(wù)，則直接將其從隊(duì)列中刪除。

* 持續(xù)掃描GAQ隊(duì)列，直到找到一個(gè)未執(zhí)行過的事務(wù)為止即停止掃描。

* 上述步驟中掃描動(dòng)作停止前掃描到的最后一個(gè)事務(wù)被確定為檢查點(diǎn)的最新位置，并且別標(biāo)記為LWM（低水位線標(biāo)記）。

* 將本次執(zhí)行檢查點(diǎn)的位置記錄到mysql.slave_relay_log_info表中，作為全局bin log應(yīng)用的位置。

現(xiàn)在，我們來看從庫crash recovery的過程：

關(guān)閉log_slave_updates參數(shù)，減少從庫binlog寫入量（如果不做級(jí)聯(lián)復(fù)制甚至可以同時(shí)關(guān)閉binlog）。

設(shè)置innodb_flush_log_at_trx_commit為0或者2，減少事務(wù)提交時(shí)redo log的等待頻率。

設(shè)置sync_binlog為默認(rèn)值或者更大的值，減少事務(wù)提交時(shí)binlog的等待頻率。

設(shè)置slave_preserve_commit_order參數(shù)為OFF（默認(rèn)為OFF，設(shè)置為ON時(shí)要求開啟binlog和log_slave_updates參數(shù)），減少事務(wù)嚴(yán)格按照主庫順序提交時(shí)的提交等待時(shí)間。

當(dāng)某個(gè)從庫接受到自己的GTID集合中已經(jīng)包含的GTID時(shí)，會(huì)忽略這個(gè)已存在的GTID，并且不會(huì)報(bào)錯(cuò)，事務(wù)也不會(huì)被執(zhí)行。

由于有mysql.gtid_executed表記錄GTID（避免了binlog丟失的時(shí)候丟失GTID歷史記錄），所以，從5.7.5版本開始，在復(fù)制拓?fù)渲械膹膸煸试S關(guān)閉binlog，也允許在binlog開啟的情況下關(guān)閉log_slave_updates變量。

* 該表中的記錄在執(zhí)行reset master語句時(shí)會(huì)被清空。

該表中的記錄周期性執(zhí)行壓縮示例。

表字段含義。

source_uuid：代表數(shù)據(jù)來源的GTID集合。

interval_start：每個(gè)UUID集合的最小事務(wù)號(hào)。

interval_end：每個(gè)UUID集合的最大事務(wù)號(hào)。

該表提供查詢ndb集群引擎相關(guān)的統(tǒng)計(jì)信息，由于國內(nèi)較少使用NDB存儲(chǔ)引擎，這里不做過多介紹，有興趣的朋友可自行研究。

本期內(nèi)容就介紹到這里，本期內(nèi)容參考鏈接如下：