crash-safe replication的解析及主從注意事項

先前碰到一個故障,于是引入了crash-safe replication,下面仔細描述;

故障描述:
   從庫(slave端)宕機,重啟后,mysql同步發現有數據主鍵沖突;
故障分析:
    從庫宕機后,從庫的mysql服務遭到非正常退出,部分數據可能未刷新到磁盤;但這個案例是已經有數據刷新到磁盤了.重啟后,從庫又重新從主庫拉取了這部分數據,再次進行了應用,所以導致數據沖突了.所以接下來就要分析主從相關的一些參數了;
   
    先說說,主從同步的那點事兒.
    所謂主從同步,就是主庫在生成binlog后,從庫拉取主庫的binlog,然后將數據應用到從庫的過程;
    同步分為半同步和異步同步.這個案例是異步,半同步就不細說了.異步同步是指,在主庫生成binlog后,從庫拉取主庫的binlog應用到從庫本機的過程;
    那這里就要重點介紹幾個名詞信息了:
    IO_thread
    SQL_thread
    master-info.log
    relay-info.log
    IO_tread和SQL_thread,經常搭建主從的同學都知道,這是從庫上面用于同步的兩個關鍵線程(show processlist可以看到);
    master-info.log和relay-info.log是記錄從庫同步位置和狀態等一些信息.
   
    來看下這幾個名詞間的聯系:
    從主庫生成binlog開始,從庫拉取binlog到本機,傳輸完成后,IO_thread會將拉取到的binlog的文件名及事務位置(postion和gtid)記錄到master-info.log,同時,SQL_thread會將拉取到的binlog應用到本地,應用完成后會將完成的binlog文件名和事務位置(postion和gtid)寫入到relay-info.log.
    這是整個的同步過程.(注意:這兩個文件記錄的binlog相關信息都是主庫的信息,從庫的binlog是不會記錄到這兩個文件的.)
    這個過程有兩點需要注意:
    1.在默認配置的情況下,master-info.log和relay-info.log文件系統層面完成寫入操作的.也就是說mysql在將更改信息完成后提交給OS的緩存,什么時候刷盤是由OS決定的.
    2.如果從庫宕機,重啟后,會去讀取master-info.log的位置信息.5.6后啟用了relay_log_recovery參數,將讀取relay-info.log的位置,而不讀取master-info.log;
   
    那么結合這個案例,我們就很清晰的知道問題出在哪了.
    1.IO_thread拉取完數據,master_info的更改信息在OS的緩存里,還未更改文件,同時,SQL_thread已經應用完數據,這個時候宕機了.那就造成了,master-info.log未更新,但數據庫已經將數據寫入了.重啟后,IO_thread根據未更新的master-info.log重新拉取了重復的數據.
    2.在啟用了relay_log_recovery后,重啟從庫后讀取的是relay-info.log文件,跟上面情況類似,也是未更新到relay-info.log,然后重新應用了.
    3.sync_relay_log和master_relay_log參數為1,這種情況會丟失最后一個事務.導致最后同步的一個事務沖突.
解決方法:
    查看沖突數據是否一致,要么在從庫刪除該數據,讓從庫重新應用,要么就跳過該錯誤,繼續同步,具體方法不累述,網上大把大把的案例.
   
總結:
    主從異步同步,很多場景都會用到,主從不同步也是經常發生.好在mysql一直在不斷的進步,修改.到mysql5.7,主從架構已經相當成熟了.你要相信,你踩到的坑,肯定有很多前輩已經踩過很多次了,所以,放心大膽的用吧.為了讓大家少掉坑,我總結下使用異步同步的一些參數設置和一些坑.
   
    主庫:1.binlog_format=row 能選用row格式,其他兩種就別考慮了,具體的坑太多了.
         2.sync_binlog=1,innodb_flush_log_at_trx_commit=1  不要問我為什么.安全是數據庫的唯一標準.
         3.log_bin_trust_function_creators =1 這個開一下吧,備用,萬一被那個二貨給改了binlog行模式勒.
         4.binlog_rows_query_log_events =1  這個挺有用的,記錄sql,row格式下,看binlog是挺不好看的.有這參數,杠杠的.
        
    從庫:master-info-repository=table           
         relay-log-info-repository=table 改成table吧... SQL_thread會吧更改relay-log-info放到應用事務的同一個事務里面,這樣就實現了事務與日志修改的原子性了
         relay_log_recovery = 1   讀的是relay-info的信息,而且會把未執行的relay-log給刪掉,重新拉取.
         sync_relay_log_info=1   這個,如果relay-info為table的話,可用可不用.如果是file,加個保險吧.
         sync_master_info=1   能保證master-info的一致性.
        
 crash-safe 不管是主庫還是從庫,都挺蛋疼的.上面主要講的還是crash-safe replication的一些參數.總之保證安全的前提下,在去提升效率吧.如果你覺得可以犧牲安全來保證效率,那就忽略吧.