## 問題重現 搭建一主一備，主備配置分別如下 ，同時設置備庫的auto_position=0 ~~~ $cat crash_recovery-slave.opt gtid_mode=on enforce_gtid_consistency=on log_slave_updates=on relay_log_purge=OFF sync_relay_log_info=1000 sync_relay_log=1 sync_relay_log_info=100 $cat crash_recovery-master.opt gtid_mode=on enforce_gtid_consistency=on log_slave_updates=on ~~~ 用 sysbench 不斷對主庫進行壓測，由于主庫壓力比較大，可以發現備庫延遲不斷增加，在有延遲的情況下，重啟備庫 OS 并啟動備庫 mysql server，關閉主庫壓力，待主備延遲為零的時候，做主備校驗（這樣的過程我們稱之為一輪，在每一輪的結尾處做主備校驗），這時可以發現會有一個表的 checksum 不一致，即產生了主備不一致的問題。 ## 問題分析 1. 分別在主備庫比較?`show global variables like '%gtid_executed%'`?可以發現主備的 gtid_executed 的值是相等的; 2. 將 checksum 不一致的表中的數據分別取出，然后vimdiff 一下，找到不一致表的具體數據的主建; 3. 在主庫的binlog中找到對這條數據最近一次操作的gtid; 4. 解析備庫的relaylog，并查找步驟 3) 中的gtid，可以發現，該gtid是一個relay log的結尾，且文件結尾處沒有rotate log event. 5. 繼續解析relaylog文件，可以發現在format event之后是一個table_map_event, update_rows, xid_log_event, gtid_log_event, 只是gtid_log_event 的 id 小于3)中出現問題的gtid; 6. 從 5）解析的relay log 來看，備庫crash后，并不是接著crash之前的 binlog 來進行拉的，而是 crash 之前的一個位點，假設我們在crash之前拉取了 gtid 為30的binlog event，并sync 了relay log,此時，master_log_info記錄的是之前的主庫事務位點，假設為事務 10 的一個位點，那么當 OS 重啟后，由于備庫 auto_position=0, 會從master_log_info中的位點10來拉取binlog，從而形成了這樣的binlog序列： gtid_log_event(30), table_map_event(10), update_rows_log_event(10), xid_log_event(10), gtid_log_event(11)….. 這樣的后果是將事務10的數據再次執行并誤認為是事務30的數據，而直正拉取到事務30的binlog event時不執行，從而造成主備不一致的問題。 ## 解決方案 1. 打開gtid時，必須指定auto_position= 1; 2. 備庫在記錄master_log_info時，以事務為單位記錄位點信息，而不是以event為單位記錄位點信息，這個需要在handle_slave_io中修改源碼。 ## 參數說明 sync_relay_log_info：Synchronously flush relay log info to disk after every #th transaction，每隔多少個事務 sync 一次 relay log 信息； sync_master_info： Synchronously flush master info to disk after every #th event，每隔多少個log_event sync 一次 master log 信息； sync_relay_log： Synchronously flush relay log to disk after every #th event，每隔多少個 log_event sync 一次 relay log 信息； mysql 在讀取binlog event時，會首先將位點信息寫入操作系統的文件，但是沒有 sync 操作，所以當OS crash時，會造成之前寫但沒有 sync 的位點信息丟失。