前言
系列文章：
1.MySQL主從復(fù)制
2.OneProxy實(shí)現(xiàn)MySQL讀寫分離
3.MySQL數(shù)據(jù)庫(kù)結(jié)構(gòu)設(shè)計(jì)
4.MySQL基于GTID主從復(fù)制的雜談
先來(lái)回顧一下MySQL的二進(jìn)制知識(shí)點(diǎn)轴术×⒗颍基于Row格式的日志可以避免MySQL主從復(fù)制中出現(xiàn)的主從不一致問(wèn)題允青。在一個(gè)sql語(yǔ)句修改了1000條數(shù)據(jù)的情況下，基于段的日志格式只會(huì)記錄這個(gè)sql語(yǔ)句。而基于row的日志格式會(huì)有1000條記錄來(lái)記錄每一行的數(shù)據(jù)修改辜膝。
MySQL官方推薦基于row的日志格式深啤，優(yōu)點(diǎn)如下：
1.使MySQL主從復(fù)制 更加安全拴魄。
2.對(duì)每一行數(shù)據(jù)的修改比基于段的復(fù)制更加高效。
有時(shí)候我們進(jìn)行誤操作而修改了數(shù)據(jù)庫(kù)中的數(shù)據(jù)崖飘，同時(shí)又沒有備份可以恢復(fù)時(shí)稳衬，我們可以通過(guò)分析binlog，對(duì)日志中記錄的數(shù)據(jù)修改操作做反向處理來(lái)達(dá)到恢復(fù)數(shù)據(jù)的目的坐漏。
基于row格式的日志量會(huì)比較大薄疚，我們可以通過(guò)
配置binlog_row_image=full|minimal|noblob。full模式會(huì)記錄所有的列赊琳。minimal模式只會(huì)記錄被修改的列街夭。noblob模式在沒有對(duì)text、blob列進(jìn)行修改時(shí)不會(huì)記錄text躏筏、blob列板丽。
推薦日志采用mixed格式，它具有以下優(yōu)點(diǎn)：
1.根據(jù)sql語(yǔ)句埃碱，系統(tǒng)決定在基于段和基于行的日志格式中進(jìn)行選擇酥泞。
2.數(shù)據(jù)量的大小由所執(zhí)行的sql語(yǔ)句決定。
由于日志的格式原因似炎，復(fù)制又分為：
基于sql語(yǔ)句的復(fù)制(SBR)：二進(jìn)制日志格式使用的是statement格式悯姊。
基于行的復(fù)制(RBR):二進(jìn)制日志格式使用的是基于行的日志格式。
混合模式：根據(jù)實(shí)際內(nèi)容在以上兩者進(jìn)行切換悯许。
SBR的優(yōu)點(diǎn)：
1.生成的日志量較少，節(jié)約網(wǎng)絡(luò)傳輸IO瘩扼。
2.并不強(qiáng)制要求主從數(shù)據(jù)庫(kù)的表定義完全相同。
3.相比于基于row的復(fù)制模式更加靈活启上。
SBR的缺點(diǎn)：
1.對(duì)非確定性時(shí)間邢隧，無(wú)法保證主從復(fù)制數(shù)據(jù)的一致性，比如uuid()冈在。從而導(dǎo)致主從數(shù)據(jù)一致性，造成復(fù)制鏈路中斷按摘。
2.對(duì)于存儲(chǔ)過(guò)程包券，觸發(fā)器纫谅，自定義函數(shù)進(jìn)行的修改也可能造成數(shù)據(jù)不一致。
3.相比基于行的復(fù)制方式在執(zhí)行時(shí)需要更多的行鎖溅固。
RBR的優(yōu)點(diǎn)：
1.可以應(yīng)用任何sql的復(fù)制包括非確定函數(shù),存儲(chǔ)過(guò)程付秕。
2.可以減少數(shù)據(jù)庫(kù)鎖的使用。
RBR的缺點(diǎn)：
1.要求主從數(shù)據(jù)庫(kù)的表結(jié)構(gòu)相同侍郭，否則可能會(huì)發(fā)生復(fù)制中斷询吴。
2.無(wú)法再slave上單獨(dú)執(zhí)行觸發(fā)器。
- 基于sql段的日志是slave上重新執(zhí)行binlog記錄的sql亮元。
- 基于row的日志則是在slave上直接應(yīng)用對(duì)數(shù)據(jù)庫(kù)的修改猛计。
在slave配置中繼日志的時(shí)候，如果不加mysql前綴的話爆捞，默認(rèn)生成的中繼日志格式是本機(jī)ip-mysql-replay-bin.000001奉瘤。最好還是指定前綴。
relay_log=mysql-relay-bin
把中繼日志的內(nèi)容加入到slave的binlog中煮甥。也就是說(shuō)slave的binlog會(huì)記錄master同步的操作日志盗温。
log-slave-updates=on
對(duì)數(shù)據(jù)庫(kù)進(jìn)行備份
mysqldump -utest -ptest rap_test > rap_test.dump
master-data=1或者2，其實(shí)沒有什么區(qū)別成肘。只是master-data=2,把change master注釋掉了。指定single-transaction双霍，備份時(shí)是不會(huì)加鎖的蟹演，也不會(huì)阻止任何的事務(wù)酒请，保證備份時(shí)數(shù)據(jù)一致性羞反。想要實(shí)現(xiàn)在線備份昼窗，可以用xtrabackup工具澄惊。
mysqldump --single-transaction --master-data --triggers --routines --all-databases -utest -ptest > db.dump
下面來(lái)說(shuō)說(shuō)基于日志點(diǎn)復(fù)制和基于GTID復(fù)制的優(yōu)缺點(diǎn)把肛搬。
基于日志點(diǎn)復(fù)制的優(yōu)點(diǎn)：
1.MySQL最早支持的復(fù)制技術(shù)，BUG相對(duì)較少鬼癣。
2.對(duì)sql查詢沒有什么限制拜秧。
3.故障處理比較容易腹纳。
基于日志點(diǎn)復(fù)制的缺點(diǎn)：
1.故障轉(zhuǎn)移時(shí)重新獲取master的日志點(diǎn)信息比較困難嘲恍〉枧＃基于日志點(diǎn)復(fù)制是從master的binlog的偏移量進(jìn)行增量同步。如果指定錯(cuò)誤會(huì)造成遺漏或者重復(fù)蔬将，造成主從不一致惫东。
GTID是全局事務(wù)ID廉沮，其保證為每個(gè)在master上提交的事務(wù)在復(fù)制集群中可以生產(chǎn)一個(gè)唯一ID滞时。GTID的生成策略是source_id(也就是server的uuid坪稽，在auto.conf文件里面可以看到):transaction_id(自增序列)演训。
[auto]
server-uuid=67ccaaf1-e4b4-11e7-a07f-c8d3ffc0c026
在基于GTID的復(fù)制中贝咙，slave會(huì)告訴master庭猩，slave已經(jīng)執(zhí)行事務(wù)的 GTID，master也會(huì)告訴slave录肯，slave未執(zhí)行事務(wù)的GTID优炬。同一個(gè)事務(wù)只會(huì)在指定的從庫(kù)執(zhí)行一次蠢护。
基于GTID復(fù)制的優(yōu)點(diǎn)是：
1.可以很方便的進(jìn)行故障轉(zhuǎn)移葵硕，記錄master最后事務(wù)的GTID值。比如master：A悄谐，slave：B,C威沫。當(dāng)A掛了后棒掠，B執(zhí)行了所有A傳過(guò)來(lái)的事務(wù)烟很。當(dāng)C連接到B后雾袱，在自己的binlog找到最后一次A傳過(guò)來(lái)的GTID毒坛。然后C將這個(gè)GTID發(fā)送給B煎殷，B獲取到這個(gè)GTID豪直，就開始從這個(gè)GTID的下一個(gè)GTID開始發(fā)送事務(wù)給C弓乙。這種自我尋找復(fù)制位置的模式減少事務(wù)丟失的可能性以及故障恢復(fù)的時(shí)間暇韧。
2.slave不會(huì)丟失master的任何修改(開啟了log_slave_updates)
基于GTID復(fù)制的缺點(diǎn)：
1.不支持非事務(wù)引擎。
2.故障處理比較復(fù)雜酪刀，需要注入空事務(wù)骂倘。
3.不支持sql_slave_skip_counter(一般用這個(gè)來(lái)跳過(guò)基于binlog主從復(fù)制出現(xiàn)的問(wèn)題历涝。)
4.對(duì)執(zhí)行的sql有一定的限制。
5.為了保證事務(wù)的安全性赵刑，create table ... select無(wú)法使用蚪战。不能使用create temporary table創(chuàng)建臨時(shí)表。不能使用關(guān)聯(lián)更新事務(wù)表和非事務(wù)表瞎疼。
廢話不BB了贼急，直接進(jìn)入正題竿裂。
這是我從網(wǎng)上copy的一張圖。一般主從復(fù)制有3個(gè)線程參與这揣，binlog dump(master),IO Thread(slave),sql Thread(slave)
基于GTID主從復(fù)制的步驟：
1.master數(shù)據(jù)改變時(shí)，會(huì)在事務(wù)前產(chǎn)生一個(gè)GTID片迅，通過(guò)binlog dump記錄到master的binlog中柑蛇。
2.slave通過(guò)IO Thread將binlog中變更的數(shù)據(jù)耻台，寫入到slave的relay log中(中繼日志)。
3.slave通過(guò)sql Thread讀取relay log中的GTID摄杂，然后對(duì)比slave的binlog是否有此記錄析恢。
4.如果slave的binlog存在該GTID的記錄氮昧，那么不好意思袖肥，忽略掉了椎组。
5.如果slave的binlog不存在該GTID的記錄寸癌，那么就執(zhí)行該GTID事務(wù)蒸苇，并一同記錄到slave的binlog中溪烤。
slave配置
server-id=6
log-bin=mysql-bin
binlog_format=mixed
gtid_mode=on
enforce-gtid-consistency=on
log-slave-updates=on
#read_only=on
#innodb_read_only=on
master_info_repository=TABLE
relay_log_info_repository=TABLE
relay_log=mysql-relay-bin
binlog_row_image=minimal
relay_log_recovery=1
slave-parallel-type=LOGICAL_CLOCK
slave-parallel-workers=16
master配置
# Binary Logging.
sync_binlog=1
log-bin=mysql-bin
binlog_format=mixed
binlog_row_image=minimal
gtid_mode=on
enforce-gtid-consistency=on
log-slave-updates=on
# Error Logging.
log-error="cmazxiaoma-mysql.err"
# Server Id.
server-id=21
在slave配置master相關(guān)的信息槽驶。
mysql> change master to
-> master_host="192.168.10.21",
-> master_user="gtid",
-> master_password="gtid",
-> master_auto_position=0\g
Query OK, 0 rows affected, 2 warnings (0.13 sec)
mysql> show slave status\G
*************************** 1. row ***************************
Slave_IO_State:
Master_Host: 192.168.10.21
Master_User: gtid
Master_Port: 3306
Connect_Retry: 60
Master_Log_File:
Read_Master_Log_Pos: 4
Relay_Log_File: mysql-relay-bin.000001
Relay_Log_Pos: 4
Relay_Master_Log_File:
Slave_IO_Running: No
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 0
Relay_Log_Space: 154
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 1236
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Slave has more GTIDs than the master has, using the master's SERVER_UUID. This may indicate that the end of the binary log was truncated or that the last binary log file was lost, e.g., after a power or disk failure when sync_binlog != 1. The master may or may not have rolled back transactions that were already replica'
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 21
Master_UUID: 67ccaaf1-e4b4-11e7-a07f-c8d3ffc0c026
Master_Info_File: mysql.slave_master_info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp: 181108 11:26:16
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set:
Executed_Gtid_Set: 67ccaaf1-e4b4-11e7-a07f-c8d3ffc0c026:1-42135,
803785ec-db4e-11e8-987c-000c29c74079:1-6139
Auto_Position: 1
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
1 row in set (0.00 sec)
之前我在master上執(zhí)行了reset master的命令揍异，清除了binlog烤镐。首先IO線程讀取主庫(kù)的binlog將master數(shù)據(jù)變化寫入到slave的relay log棍鳖。然后sql線程從relay log獲取gtid镜悉，與slave的binlog對(duì)比侣肄，發(fā)現(xiàn)slave比master的gtid數(shù)量還要多稼锅，所以拋出了1236錯(cuò)誤矩距。
我們?cè)趍aster執(zhí)行SHOW GLOBAL VARIABLES LIKE '%gtid%'锥债，發(fā)現(xiàn)gtid_executed和gtid_purged都為空哮肚。
我們?cè)趕lave也同樣執(zhí)行SHOW GLOBAL VARIABLES LIKE '%gtid%'恼策，發(fā)現(xiàn)gtid_executed為67ccaaf1-e4b4-11e7-a07f-c8d3ffc0c026:1-42135, 803785ec-db4e-11e8-987c-000c29c74079:1-6139
我們?cè)趕lave執(zhí)行reset master，再來(lái)看看gtid_executed的值，發(fā)現(xiàn)它清空了改含。
mysql> show global variables like '%gtid%'\G
*************************** 1. row ***************************
Variable_name: binlog_gtid_simple_recovery
Value: ON
*************************** 2. row ***************************
Variable_name: enforce_gtid_consistency
Value: ON
*************************** 3. row ***************************
Variable_name: gtid_executed
Value:
*************************** 4. row ***************************
Variable_name: gtid_executed_compression_period
Value: 1000
*************************** 5. row ***************************
Variable_name: gtid_mode
Value: ON
*************************** 6. row ***************************
Variable_name: gtid_owned
Value:
*************************** 7. row ***************************
Variable_name: gtid_purged
Value:
*************************** 8. row ***************************
Variable_name: session_track_gtids
Value: OFF
8 rows in set (0.00 sec)
運(yùn)行slave捍壤，查看slave的狀態(tài)，一切正常睹逃。
mysql> show slave status\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.10.21
Master_User: gtid
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000001
Read_Master_Log_Pos: 154
Relay_Log_File: mysql-relay-bin.000003
Relay_Log_Pos: 367
Relay_Master_Log_File: mysql-bin.000001
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 154
Relay_Log_Space: 751
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 21
Master_UUID: 67ccaaf1-e4b4-11e7-a07f-c8d3ffc0c026
Master_Info_File: mysql.slave_master_info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set:
Executed_Gtid_Set:
Auto_Position: 1
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
1 row in set (0.00 sec)
后來(lái)我不小心在master上執(zhí)行了一段sqlINSERT INTO groupon.date_demo VALUES(NULL,NOW(),NOW(),NOW(),NOW(),NOW())疗隶，由于master和slave上的數(shù)據(jù)不一致(master上有g(shù)roupon數(shù)據(jù)庫(kù)斑鼻，slave沒有g(shù)roupon數(shù)據(jù)庫(kù))蜀备，導(dǎo)致slave的SQL線程執(zhí)行sql語(yǔ)句時(shí)琼掠，掛了瓷蛙。
mysql> show slave status\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.10.21
Master_User: gtid
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000001
Read_Master_Log_Pos: 537
Relay_Log_File: mysql-relay-bin.000003
Relay_Log_Pos: 367
Relay_Master_Log_File: mysql-bin.000001
Slave_IO_Running: Yes
Slave_SQL_Running: No
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 1146
Last_Error: Coordinator stopped because there were error(s) in the worker(s). The most recent failure being: Worker 0 failed executing transaction '67ccaaf1-e4b4-11e7-a07f-c8d3ffc0c026:1' at master log mysql-bin.000001, end_log_pos 506. See error log and/or performance_schema.replication_applier_status_by_worker table for more details about this failure or others, if any.
Skip_Counter: 0
Exec_Master_Log_Pos: 154
Relay_Log_Space: 1134
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 1146
Last_SQL_Error: Coordinator stopped because there were error(s) in the worker(s). The most recent failure being: Worker 0 failed executing transaction '67ccaaf1-e4b4-11e7-a07f-c8d3ffc0c026:1' at master log mysql-bin.000001, end_log_pos 506. See error log and/or performance_schema.replication_applier_status_by_worker table for more details about this failure or others, if any.
Replicate_Ignore_Server_Ids:
Master_Server_Id: 21
Master_UUID: 67ccaaf1-e4b4-11e7-a07f-c8d3ffc0c026
Master_Info_File: mysql.slave_master_info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State:
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp: 181108 11:57:50
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set: 67ccaaf1-e4b4-11e7-a07f-c8d3ffc0c026:1
Executed_Gtid_Set:
Auto_Position: 1
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
1 row in set (0.00 sec)
通過(guò)看slave的狀態(tài)冠桃，我們可以抓住幾條關(guān)鍵消息食听，來(lái)定位錯(cuò)誤樱报。
Retrieved_Gtid_Set是slave收到的事務(wù)信息迹蛤，Executed_Gtid_Set是slave執(zhí)行的事務(wù)消息。我們發(fā)現(xiàn)收到的事務(wù)信息是1,但是slave卻沒有執(zhí)行任何事務(wù)消息陋桂。所以我判斷是執(zhí)行67ccaaf1-e4b4-11e7-a07f-c8d3ffc0c026:1事務(wù)消息報(bào)錯(cuò)宣渗。
Retrieved_Gtid_Set: 67ccaaf1-e4b4-11e7-a07f-c8d3ffc0c026:1
Executed_Gtid_Set
還有一條關(guān)鍵信息是Last_SQL_Error落包，它顯示執(zhí)行67ccaaf1-e4b4-11e7-a07f-c8d3ffc0c026:1事務(wù)消息報(bào)錯(cuò)咐蝇。證明了我們上面的想法抹腿。如果Last_SQL_Error沒有顯示執(zhí)行錯(cuò)誤的事務(wù)信息旭寿，那該怎么辦肩祥。我們可以通過(guò)查看log的方式混狠，定位到事務(wù)信息GTID将饺。
Last_SQL_Error: Coordinator stopped because there were error(s) in the worker(s). The most recent failure being: Worker 0 failed executing transaction '67ccaaf1-e4b4-11e7-a07f-c8d3ffc0c026:1' at master log mysql-bin.000001, end_log_pos 506. See error log and/or performance_schema.replication_applier_status_by_worker table for more details about this failure or others, if any.
還有一條關(guān)鍵消息是Relay_Master_Log_File: mysql-bin.mysql-bin.000001和Exec_Master_Log_Pos: 154。這是相對(duì)于主庫(kù)掖蛤，是從庫(kù)的sql線程執(zhí)行到的位置。也就是SQL線程讀取Relay_Master_Log_File文件，執(zhí)行完position為154的位置蝇恶，發(fā)生異常。為了確認(rèn)我的想法是對(duì)的贿衍，執(zhí)行mysqlbinlog --no-defaults -v -v --base64-output=decode-rows --stop-position=200 mysql-bin.000001查看binlog日志，發(fā)現(xiàn)mysql-bin.000001文件中end_log_pos:154的后面沒有消息了救恨。按理來(lái)說(shuō)執(zhí)行完end_log_pos:154消息贸辈，再往下執(zhí)行就會(huì)報(bào)錯(cuò)，會(huì)輸出相關(guān)執(zhí)行錯(cuò)誤的事務(wù)信息肠槽。那為什么沒有相關(guān)錯(cuò)誤的事務(wù)消息呢擎淤？腦子里面仔細(xì)回想一下GTID主從復(fù)制的流程：slave通過(guò)讀取relay log文件奢啥，執(zhí)行GTID的事務(wù)并記錄到slave的binlog中。由于執(zhí)行GTID的事務(wù)失敗嘴拢，那么相關(guān)信息肯定不會(huì)記錄到slave的binlog中桩盲。
在Relay_Master_Log_File沒有找到相關(guān)信息，不要緊。我們從Relay_Log_File里面找信息。Relay_Log_File是中繼日志，相對(duì)于從庫(kù)，記錄著從庫(kù)的sql線程執(zhí)行到的位置蚤霞。我們可以確定從庫(kù)的sql線程執(zhí)完中繼日志的pos為367的位置發(fā)生異常捶闸。
Relay_Log_File: mysql-relay-bin.000003
Relay_Log_Pos: 367
執(zhí)行mysqlbinlog --no-defaults -v -v --base64-output=decode-rows --stop-position=390 mysql-relay-bin.000003税灌，我們可以看到執(zhí)行到end_log_pos為219的位置發(fā)生異常狸窘，異常事務(wù)消息gtid為67ccaaf1-e4b4-11e7-a07f-c8d3ffc0c026:1劳吠。
我們從master查看到binlog中pos為219的消息蠢古，可以看到GTID為67ccaaf1-e4b4-11e7-a07f-c8d3ffc0c026:1堕战，證明我的猜想是正確的祠饺。
那如何定位錯(cuò)誤事務(wù)GTID已經(jīng)說(shuō)完了祝旷，接下來(lái)是怎么解決錯(cuò)誤了吻谋，我們可以注入空事務(wù)的方式跳過(guò)這個(gè)錯(cuò)誤速种。
mysql> stop slave\G
Query OK, 0 rows affected, 1 warning (0.00 sec)
mysql> set gtid_next='67ccaaf1-e4b4-11e7-a07f-c8d3ffc0c026:1'\G
Query OK, 0 rows affected (0.00 sec)
mysql> begin\G
Query OK, 0 rows affected (0.00 sec)
mysql> commit\G
Query OK, 0 rows affected (0.00 sec)
mysql> set gtid_next="automatic"\G
Query OK, 0 rows affected (0.00 sec)
運(yùn)行slave，查看狀態(tài)，可以看到Retrieved_Gtid_Set: 67ccaaf1-e4b4-11e7-a07f-c8d3ffc0c026:1和Executed_Gtid_Set: 67ccaaf1-e4b4-11e7-a07f-c8d3ffc0c026:1數(shù)據(jù)一致葱绒，證明我們注入空事務(wù)成功，nice。
mysql> show slave status\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.10.21
Master_User: gtid
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000001
Read_Master_Log_Pos: 537
Relay_Log_File: mysql-relay-bin.000004
Relay_Log_Pos: 454
Relay_Master_Log_File: mysql-bin.000001
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 537
Relay_Log_Space: 1257
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 21
Master_UUID: 67ccaaf1-e4b4-11e7-a07f-c8d3ffc0c026
Master_Info_File: mysql.slave_master_info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set: 67ccaaf1-e4b4-11e7-a07f-c8d3ffc0c026:1
Executed_Gtid_Set: 67ccaaf1-e4b4-11e7-a07f-c8d3ffc0c026:1
Auto_Position: 1
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
1 row in set (0.00 sec)
mysql>
為了測(cè)試基于GTID的主從復(fù)制是否成功，
我們?cè)趍aster插入一條數(shù)據(jù)INSERT INTO date_demo VALUES(NULL,NOW(),NOW(),NOW(),NOW(),NOW())偷线，然后看slave是否有此記錄。
再看看slave的Retrieved_Gtid_Set和Executed_Gtid_Set發(fā)生了什么變化兢仰。它們從67ccaaf1-e4b4-11e7-a07f-c8d3ffc0c026:1轉(zhuǎn)變成了67ccaaf1-e4b4-11e7-a07f-c8d3ffc0c026:1-2,說(shuō)明slave成功執(zhí)行了剛才插入sql的事務(wù)消息洽议。
Retrieved_Gtid_Set: 67ccaaf1-e4b4-11e7-a07f-c8d3ffc0c026:1-2
Executed_Gtid_Set: 67ccaaf1-e4b4-11e7-a07f-c8d3ffc0c026:1-2
尾言
大家好菲盾，我是cmazxiaoma(寓意是沉夢(mèng)昂志的小馬)悉默，感謝各位閱讀本文章跟磨。
小弟不才墩瞳。
如果您對(duì)這篇文章有什么意見或者錯(cuò)誤需要改進(jìn)的地方,歡迎與我討論。
如果您覺得還不錯(cuò)的話,希望你們可以點(diǎn)個(gè)贊旺隙。
希望我的文章對(duì)你能有所幫助妥粟。
有什么意見、見解或疑惑沉噩，歡迎留言討論。
最后送上：心之所向氓侧，素履以往。生如逆旅，一葦以航优质。
