MySQL複製框架

1、複製框架

開始接觸複製時，看到各類各樣的複製，總想把不一樣類型對應起來，結果越理越亂~
究其緣由就是對比了不一樣維度的屬性，不一樣維度得出的結果集之間必然存在交集，沒有必要將不一樣維度的屬性安插到成對的蘿蔔與坑

MySQL複製框架
    Replication Methods
        Binary Log File Position Based Replication(Traditional)
        Global Transaction Identifiers Based Replication(GTID)
    Synchronization Types
        Asynchronous Replication：默認是異步複製
        Semisynchronous Replication：半同步(AFTER_COMMIT)、加強半同步(AFTER_SYNC)
        Synchronous Replication：MySQL Group Replication 、MGR和PXC的區別
    Replication Formats
        Statement-Based Replication(SBR,<5.7.7默認)
        Row-Based Replication(RBR,>=5.7.7默認)
        Mixed-Based Replication(MBR)
    複製原理
        複製線程：Dump_Thread、IO_Thread、SQL_Thread
        GTID原理：構成、gtid_executed表如何寫入及壓縮、GTID Limit、GTID和傳統複製切換(>=5.7.6支持在線切換)
    複製監控管理
        複製中斷處理：1062(duplicate-key)、1032(no-key-found)、1677(data-type-convert)
        複製延遲排查：show slave status\G結果解讀、判斷複製是否有延遲、經過SQL_Thread定位執行的操做
        複製結構調整：增長/刪減節點、提高/下降節點的角色
        Binlog Server：利用mysqlbinlog命令備份遠程的Binlog
        數據一致性校驗：主從數據爲何不一致、什麼時間須要校驗數據、pt-table-checksum、pt-table-sync
    其餘
        Multi-Threaded Slave(>=5.6.3)：5.6基於庫級別DATABASE，5.7.2支持庫級別和事務級別LOGICAL_CLOCK
        Delayed Replication(>=5.7)：作誤操做恢復、測試系統在存在滯後時的行爲、檢查好久之前數據庫的狀態
        Multi-Source Replication(>=5.7.6)：集中備份、數據分析聚合、分片數據合併
        Replication Filter：5.7.3開始能夠動態更改從庫的過濾規則

View Code

2、知其因此然

一、主從結構的瓶頸點是什麼？
• sql_thread單線程
• 對於沒有緩存熱點數據的從庫，大部分DML操做需從磁盤讀數據到內存，更新後再刷新到磁盤，須要通過讀磁盤、寫undo、寫redo、寫binlog、寫數據文件等過程
二、row格式下從庫是如何應用主庫上的更新？
• 有主鍵/非空惟一索引，只需匹配主鍵/非空惟一索引便可，其餘列的數據是否一致不做校驗
• 有其餘二級索引，經過二級索引找到對應記錄，而後匹配全部列是否與更新前主庫上的列一致
• 沒有索引，全表掃描匹配記錄
所以，在沒有主鍵/非空惟一索引的狀況下，須要匹配全部的列來肯定是不是同一條記錄
三、爲何建議從庫開啓log_slave_updates？
• 從庫開啓log_bin(自己操做記錄binlog)+log_slave_updates(複製操做記錄binlog)，那麼binlog會記錄全部的操做，能夠用其作備份，作級聯複製的中間節點
• 若是從庫沒有開啓log_slave_updates，從庫應用relay-log中的每一個事務會執行一個insert...mysql.gtid_executed操做；若是開啓了log_bin，在binlog發生rotate(flush binary logs/達到max_binlog_size)或者關閉服務時，會把全部寫入到binlog中的Gtid信息寫入到mysql.gtid_executed表
四、半同步/加強半同步複製主從會不會存在延遲？
會。半同步/加強半同步複製只保證relay log在從庫寫入並刷盤，並無論sql_thread是否已應用relay log，所以會存在延遲現象。
五、show master status 從哪裏讀的數據？
show master status/show slave status中的Executed_Gtid_Set取自@@global.gtid_executed
擴展閱讀：gtid_executed和gtid_purged變量是如何初始化的、爲何還原innobackupex備份後查看到的Executed_Gtid_Set與xtrabackup_binlog_info不一致
六、show slave status 從哪裏讀的數據？
show slave status從內存中讀出來的。 若是slave_relay_log_info基於Innodb表，二者是一致的。若是基於非事務表，默認配置頗有多是不一致的。若是須要一致能夠經過修改sync_relay_log_info=1
擴展閱讀：FAQ: show slave status從哪裏讀的數據
七、sql_slave_skip_counter跳過一個事務？
sql_slave_skip_counter以event爲單位skip，直到skip完第N個event所在的event group才中止。對於事務表，一個event group對應一個事務，一個事務能夠包含多個DML操做；對於非事務表，一個event group對應一個DML操做。一個DML操做包含多個events。
對於103二、1062錯誤儘可能修補數據，讓複製進程在從庫應用變動
擴展閱讀：跳過複製錯誤——sql_slave_skip_counter
八、pt-table-checksum 3.0.4/3.0.9檢測不出主從差別？
使用以往的pt-table-checksum參數選項，在主從不一致的狀況下，檢測不出差別。原覺得工具備bug，卻未曾發現工具提供對應的參數選項~.~
其實能夠在命令行帶上--set-vars binlog_format='statement'
擴展閱讀：pt-table-checksum檢測不出主從差別處理