MySQL的各種無損複製說明
MySQL5.7新特性：lossless replication 無損複製
https://dev.mysql.com/doc/refman/5.7/en/replication-semisync.html
MySQL的三種複製方式
- asynchronous 非同步複製
- fully synchronous 全同步複製
- Semisynchronous 半同步複製
asynchronous replication
原理：在非同步複製中，master寫資料到binlog且sync，slave request binlog後寫入relay-log並flush disk
優點：複製的效能最好
缺點：master掛掉後，slave可能會丟失事務
代表：MySQL原生的複製
fully synchronous replication
原理：在全同步複製中，master寫資料到binlog且sync，所有slave request binlog後寫入relay-log並flush disk，並且回放完日誌且commit
優點：資料不會丟失
缺點：會阻塞master session，效能太差，非常依賴網路
代表：MySQL-Cluster
semisynchronous replication
- 普通的半同步複製
原理: 在半同步複製中，master寫資料到binlog且sync，且commit，然後一直等待ACK。當至少一個slave request bilog後寫入到relay-log並flush disk，就返回ack（不需要回放完日誌）
優點：會有資料丟失風險（低）
缺點：會阻塞master session，效能差，非常依賴網路，
代表：after commit, 原生的半同步
重點：由於master是在三段提交的最後commit階段完成後才等待，所以master的其他session是可以看到這個提交事務的，所以這時候master上的資料和slave不一致，master crash後，slave資料丟失
- 增強版的半同步複製（lossless replication）
原理: 在半同步複製中，master寫資料到binlog且sync，然後一直等待ACK. 當至少一個slave request bilog後寫入到relay-log並flush disk，就返回ack（不需要回放完日誌）
優點：資料零丟失（前提是讓其一直是lossless replication），效能好
缺點：會阻塞master session，非常依賴網路
代表：after sync, 原生的半同步
重點：由於master是在三段提交的第二階段sync binlog完成後才等待, 所以master的其他session是看不見這個提交事務的，所以這時候master上的資料和slave一致，master crash後，slave沒有丟失資料
重要引數
| 引數 | comment | 預設值 | 推薦值 | 是否動態 |
|---|---|---|---|---|
| rpl_semi_sync_master_wait_for_slave_count | 至少有N個slave接收到日誌 | 1 | 1 | dynamic |
| rpl_semi_sync_master_wait_point | 等待的point | AFTER_SYNC | AFTER_SYNC | dynamic |
| rpl_semi_sync_master_timeout | 切換複製的timeout | 10000（10s） | 1000(1s) | dynamic |
| rpl_semi_sync_master_enabled | 是否開啟半同步 | OFF | ON | dynamic |
| rpl_semi_sync_slave_enabled | 是否開啟半同步 | OFF | ON | dynamic |
如何開啟lossless replication
########semi sync replication settings########
plugin_dir=/usr/local/mysql/lib/plugin
plugin_load = "rpl_semi_sync_master=semisync_master.so;rpl_semi_sync_slave=semisync_slave.so"
loose_rpl_semi_sync_master_enabled = 1
loose_rpl_semi_sync_slave_enabled = 1
loose_rpl_semi_sync_master_timeout = 1000實踐是檢驗真理的唯一標準
如何檢驗上述after_sync,after_commit
如何檢驗上述原理的正確性
InnoDB commit ： 三階段提交過程
A階段. wite prepare log -- 寫入Xid
B階段. write binlog
C階段. write commit log測試點
master上當一個事務Waiting for semi-sync ACK from slave的時候，後來的事務是在A,B,C哪個階段卡住呢？
0，RC模式
1. semi-sync C階段等待
假設設定time-out=100000s，當事務一提交了一個大事務，在write commit log(C階段)時候等待，
那麼第二個事務在敲commit命令的時候，是卡在哪個階段呢？是卡在 wite prepare log（A階段）？還是write binlog（B階段）？還是write commit log（C階段）
測試：semi-sync vs loss-less semi-sync
【semi-sync】 C階段等待
0, 開啟事務1，然後在slave上執行stop slave，製造timeout的情況，讓其阻塞。(Waiting for semi-sync ACK from slave)
1，在開啟一個事務2，事務2插入一條特殊記錄（XXXXX）。 (Waiting for semi-sync ACK from slave)
2，在開啟一個事務3。
2.1，測試案例：這個時候，kill -9 mysqld，造成人為的mysql crash
3，假設卡在A階段，那麼事務3，肯定是看不到事務1,2寫入的記錄（XXXXX）,且重啟mysql後，事務2不會提交。
4，假設卡在C階段，那麼事務3，肯定是可以看見事務1，2寫入的記錄（XXXXX）。
經過測試：
1，是卡在C階段，也就是說事務3是可以看見事務1，事務2的。
2，MySQL crash重啟後，事務1，事務2的dml都已經提交成功，說明不是卡在A階段
【loss-less semi-sync】B階段等待
0, 開啟事務1，然後在slave上執行stop slave，製造timeout的情況，讓其阻塞。(Waiting for semi-sync ACK from slave)
1，在開啟一個事務2，事務2插入一條特殊記錄（XXXXX）。(Waiting for semi-sync ACK from slave)
2，在開啟一個事務3
3，假設卡在A階段，那麼事務3，肯定是看不到事務1,2寫入的記錄（XXXXX）,且重啟mysql後，事務2不會提交。。
4，假設卡在B階段，那麼事務3，肯定是可以看見事務1,2寫入的記錄（XXXXX）,且重啟mysql後，事務1，2都會提交。。
5, 假設卡在C階段，那麼事務3，肯定是可以看見事務3寫入的記錄（XXXXX）。
經過測試：
1，是卡在B階段，也就是說事務3，既看不見事務1的提交內容，也看不見事務2的提交內容，且重啟mysql後，事務1，2都已經提交。。
2，MySQL crash重啟後，事務1，事務2的dml都已經提交成功，說明不是卡在A階段。效能
semi-sync vs lossless semi-sync 的效能對比
根據以上的測試，可以得知，lossless只卡在B階段，普通的semi-sync是卡在C階段。
lossless的效能遠遠好於普通的semi-sync，即（after_sync 優於 after_commit）
因為lossless 卡在B階段的時候可以堆積事務，可以在C階段進行group commit。
普通的semi-sync，卡在C階段,事務都已經commit了，並沒有堆積的過程。
CAP理論
一致性【C】
可用性【A】
分割槽容忍性【P】
理論：CAP 三者不可兼得，必須要犧牲一個
分割槽，是一定存在的，不是你想不要就不要的。所以，這裡只剩下兩種組合
- CP 犧牲可用性
這種做法，就是保留強一致性，犧牲可用性
案例：可以將rpl_semi_sync_master_timeout設定成一個無限大的值，比如：100天，那麼master和slave就強一致了，但是可用性就大打折扣
- AP 犧牲一致性
這種做法，就是保留高可用性，犧牲一致性
案例：比如原生的非同步複製就是這樣咯。可以快速做到切換，但是一致性就沒有保障