高可用：
兩地雙中心概念
同城：同IDC：增強半同步復制
跨城：異步復制

兩地三中心：（金融支付銀行）
同城：跨IDC，增強半同步
跨城：異步復制

傳統復制線程解析
GTID原理
半同步復制線程解析
並發復制
延遲復制實現
多源復制
MySQL-5.7 在復制線程方面的增強

主從數據校驗：
pt-table-checksum

GTID:
MySQL 5.6 從非GTID到GTID切換，需要重啟
MySQL 5.7 支持在線啟用GTID
切換流程：
gtid_modd=
1、主從全部off_permissive。
set global gtid_mode=off_permissive;
2、從庫on_permissive，主庫on_permissive
set global gtid_mode=on_permissive
3、確認整個group中binlog非GTID的執行完畢
4、主庫on，從庫on
set global gtid_modd=on;

MySQL 5.7 GTID會存儲到表裏。
支持slave不用開啟binlog(log_slave_updates)
mysql.gtid_executed

如何記錄GTID
如果開啟binlog,在binlog切換時，將當前的GTID插入到gtid_executed表中。
如果沒有開啟binlog，每個事務提交前，會執行一個insert

gtid_executed表壓縮
控制壓縮頻率
set global gtid_executed_compression_period=N;（默認1000）

enforce-gtid-consistency
off:不檢測是否有GTID不支持的語句/事務
warn：當發現不支持語句/事務，返回警告，並在日誌中記錄警告信息
on： 當發現語句/事務不支持GTID時，返回錯誤

TIPS：
在現實從非GTID切換過程中，可以先設置成：warn

GTID Limit：
不能使用 create table tb1 select * from tb2;
可以改成： create table tb1 like tb2; insert into tb1 select * from tb2;
事務中更新非事務表：
begin：update no_trx_tabe set col1 =xxx where xxx; update trx_tb set col1=xxx where ...commit;
事務中創建/刪除臨時表
begin:update trx_tb set xxx;create temporary table...;commit;
sql_slave_skip_counter 不支持

GTID跳過錯誤：

stop slave;
SET @@SESSION.GTID_NEXT= ‘01eea86a-5da6-11e8-a709-c03fd5486d6f:282‘;
begin;commit;
set gtid_next="automactic"

半同步復制：

在Master收到Slave將事務執行完的ACK應答後才Commit事務（5.6是Master在Commit後，才等待Slave應答）
因此在事務復制到slave前，並發的事務看不到當前的事務的數據
當master故障時，所有已提交的事務都會復制到slave上
默認采用無數據丟失的應答等待機構，用戶可以選擇使用5.6的應答待機制
set rpl_semi_sync_master_wait_point=after_sync|after_commit

如果響應超時 rpl_semi_sync_master_timeout(超時時間)，會自動降級為異步復制
修復會自動升級為半同步

增強半同步：
5.7以後默認：(生產使用增強半同步沒問題）
主庫寫binlog，傳輸到從庫後，從庫返回ACK，主庫commit；性能更好
set rpl_semi_sync_master_wait_point=AFTER_SYNC;
創建單獨的應答接收線程
變成雙工默認，發送和接收互不影響

master接收到N個slave應答後，才commit事務
用戶可以設置應答的slave數量
set global rpl_semi_sync_master_wait_for_slave_count=2;(有兩個slave相應再commit；)

特別提示：
低於5.7的版本，在從庫關閉後一段時間後，剛啟動時，註意先用異步復制，復制追上後，再用半同步復制
master:
set global rpl_semi_sync_master_enabled=ON|OFF;
slave;
set global rpl_semi_sync_master_enabled=ON|OFF; (確認主庫on，之後slave再on)

增強半同步 Master Crash Recovery
1、掃描最後一個Binlog提取其中的Xid
2、掃描innodb維持狀態（redo log）在Prepare的事務鏈表，和binlog中的Xid比較，如果binlog中存在，則提交，否回滾。
提交到innoDB中處於Prepare，並且寫Binlog的，就可以從崩潰中恢復事務。

並發復制
MySQL 5.6的並發復制是基於庫級別（由於生產都是多實例+單庫的架構，所以基本無用）

實質上需要：
讓master上能並發執行的事務，在slave上也並發執行
在binlog中記錄事務並發執行的相關信息
slave上根據上這些的信息，讓這些食物在slave上多個線程中並發執行

MySQL 5.7的並發復制是基於事務級別的（logical Clock）

基於鎖的並行復制
並發信息以邏輯時間方式寫入的gtid_log_event中，共記錄2個邏輯時間：
sequence_number
當事務寫入binlog時，事務自己的邏輯時間，按照事務記錄binlog的順序遞增
commit_parent
當食物進行prepare階段時，已經提交的事務的最大邏輯時間
事務在slave執行
commit_parent 之前事務全部提交以後，才開始執行

並行復制：
最好配置binlog group commit
binlog_group_commit_sync_delay=20-300 微妙 ：時間
binlog_group_commit_sync_no_delay_count=10-30 ：事務數

延遲復制
讓從庫和主庫保持固定時間的延遲（sql_thread)
使用場景
利用延遲復制做誤操作恢復
利用延遲復制做統計分析環境處理
stop slave sql_thread
change master to master_delay=N; #N單位是S

多源復制
多個M對應一個S
場景：
集中備份
數據分析聚合
分片數據合並

多個channels(channel包含：recevier thread,relay logs,applier threads)每個channel能獨立的運行和停止
通過P_S表進行狀態監控：
下列表中添加了channel_name字段，不同的channel的信息在不同的行中顯示
replication_applier_status_by_coordinator
replication_applier_status_by_work
replication_connection_status
show slave status\G

group replication
實質是：
二進制日誌
基於Row格式+GTID
一個通信框架+事務排序控制
增強半同步&並行復制

是一個趨勢
備份不好搞定
xtrabackup備份，造成性能損失比較嚴重
新的節點加入過程對原有集群性能有影響

練習：
1、增強半同步復制，半同步復制，異步復制區別
2、測試主從數據校驗，pt-table-checksum

DAY7-剖析復制線程