上周在講復(fù)制故障處理，利用DML在從主上手工造數(shù)據(jù)，導(dǎo)致主從復(fù)制中斷，然后處理復(fù)制故障，同時(shí)給大家安利了：課程Demo程序：主從故障自動(dòng)修復(fù)：zhishutech/ReplGurd (github.com)? 建議fork|star | watch ?有完善的地方請(qǐng)pull回來(lái)復(fù)制主從數(shù)據(jù)一致性校驗(yàn)、修復(fù)程序：pt-table-checksum/pt-table-sync 使用。

結(jié)課QA環(huán)節(jié)一個(gè)學(xué)生問(wèn)到：老師除了誤操作寫了從節(jié)點(diǎn)造成數(shù)據(jù)不一致性外，還有哪些原因？?看到這個(gè)問(wèn)題，當(dāng)時(shí)我真的是一口鮮血噴在了屏幕上啊？?
在4月26日MySQL復(fù)制原理及應(yīng)用中剛講了復(fù)制原理及半同步中可能出現(xiàn)的數(shù)據(jù)不一致時(shí)間點(diǎn)，整整用了一節(jié)課，在5月10日課中，被問(wèn)到這個(gè)問(wèn)題。有點(diǎn)無(wú)語(yǔ)了。

怎么剛講過(guò)，你們都忘了呢~~~ ：） 好吧。當(dāng)時(shí)就利用老師的特權(quán)給你們留個(gè)作業(yè)，回顧：MySQL復(fù)制原理及應(yīng)用場(chǎng)景，試試能不能解答復(fù)制主從可能造成主從數(shù)據(jù)不一致的地方。果真有很給力的同學(xué)，不管什么是哪一屆都還是有很多優(yōu)秀的同學(xué)，第二天一早就收到一份作業(yè)，也分享出來(lái)，給各位一個(gè)參考：

主從復(fù)制可能造成不一致分析（作者A1364-路遙-北京）
異步復(fù)制本身對(duì)于數(shù)據(jù)一致性不做保證，不過(guò)使用得當(dāng)也可以保證數(shù)據(jù)一致性，下面為了討論方面，我們直接使用半同步的兩個(gè)模式討論。
MYSQL5.7 之前半同步復(fù)制采用的是 AFTER_COMMIT 方式--比 AFTER_SYNC 會(huì)有更大概率造成數(shù)據(jù)不一致

AFTER_COMMIT 是先做 REDO COMMIT 后傳 BINLOG，做事務(wù)提交，只是不給客戶端返回。

AFTER_COMMIT模式下丟失數(shù)據(jù)實(shí)驗(yàn)版本8.0.23 （版本不重要，原理沒(méi)變，所有MySQL都一樣，本期課程使用的MySQL 8.0.23）
主庫(kù)參數(shù)

+-------------------------------------------+--------------+

| Variable_name | Value |

+-------------------------------------------+--------------+

| rpl_semi_sync_master_enabled | ON |

| rpl_semi_sync_master_timeout | 60000000000 |

| rpl_semi_sync_master_trace_level | 32 |

| rpl_semi_sync_master_wait_for_slave_count | 1 |

| rpl_semi_sync_master_wait_no_slave | ON |

| rpl_semi_sync_master_wait_point | AFTER_COMMIT |

| rpl_semi_sync_slave_enabled | OFF |

| rpl_semi_sync_slave_trace_level | 32 |

+-------------------------------------------+--------------+

從庫(kù)參數(shù)

+-------------------------------------------+--------------+

| Variable_name | Value |

+-------------------------------------------+--------------+

| rpl_semi_sync_master_enabled | OFF |

| rpl_semi_sync_master_timeout | 60000000000 |

| rpl_semi_sync_master_trace_level | 32 |

| rpl_semi_sync_master_wait_for_slave_count | 1 |

| rpl_semi_sync_master_wait_no_slave | ON |

| rpl_semi_sync_master_wait_point | AFTER_COMMIT |

| rpl_semi_sync_slave_enabled | ON |

| rpl_semi_sync_slave_trace_level | 32 |

+-------------------------------------------+--------------+

從庫(kù)上停掉IO_THREAD模擬從庫(kù)異常stop replica io_thread;

主庫(kù)上插入一條數(shù)據(jù)，此時(shí)會(huì)HANG?。ǖ沁@條數(shù)據(jù)已經(jīng)寫入了，開(kāi)啟一個(gè)會(huì)話是可以查到該數(shù)據(jù)的）
insert into t values(1);

開(kāi)啟新SESSION查詢T表

select * from t;

+------+

| id |

+------+

| 1 |

+------+

開(kāi)啟另一個(gè)會(huì)話殺掉主庫(kù)MYSQLD進(jìn)程

pkill -9 mysqld

此時(shí)從庫(kù)中是查不到這條數(shù)據(jù)的。
select * from t;

Empty set (0.00 sec)
如果此時(shí)發(fā)生主從切換則主從數(shù)據(jù)發(fā)生不一致。這也是after_commit模式復(fù)制中幻讀現(xiàn)象。?如圖：

AFTER_SYNC 是先傳 binlog 后做 REDO COMMIT

極端有兩種情況：1. 當(dāng)主庫(kù)還沒(méi)來(lái)得及把日志傳輸?shù)綇膸?kù)上；主庫(kù)上在完成write binlog后crash2.日志已經(jīng)傳輸?shù)綇膸?kù)上,完成了wait slave ack，此時(shí)發(fā)生crash；應(yīng)用端此時(shí)并沒(méi)有接收到主庫(kù)返回OK。情況1. 主庫(kù)Crash恢復(fù)后，這個(gè)事務(wù)操作數(shù)據(jù)可以被commit，這種事務(wù)可以稱為local commit或是幽靈事務(wù)，并沒(méi)有真正的完成半同步。情況2. 產(chǎn)生臟數(shù)據(jù)，是一個(gè)業(yè)務(wù)沒(méi)得到確認(rèn)的事務(wù)。也可以稱為幽靈事務(wù)。

在after_sync中，確實(shí)不會(huì)丟數(shù)據(jù)了，但有可能會(huì)多數(shù)據(jù)。?這種架構(gòu)下復(fù)制故障：1062，1032類的錯(cuò)誤，會(huì)發(fā)生在第一種情況，原始的master故障恢復(fù)后，做為新master的從。1062錯(cuò)誤很容易出現(xiàn)，但1032錯(cuò)誤可能被MySQL本身掩蓋了。所以對(duì)于after_sync復(fù)制，最好的做法是原始主庫(kù)故障后，可以對(duì)比一下最后一個(gè)GTID事務(wù)的內(nèi)容或是直接自動(dòng)化重建（云上的方案）

那么使用復(fù)制如何保證數(shù)據(jù)的絕對(duì)一致性呢？

1.復(fù)制一定是binlog row格式+gtid，同時(shí)在數(shù)據(jù)庫(kù)故障時(shí)，注意local commit問(wèn)題，引入數(shù)據(jù)校驗(yàn)機(jī)制。

?2. 復(fù)制環(huán)境絕對(duì)一致性屬于偽命題，如果想要絕對(duì)的一致目前可以考慮MySQL Group Replication。?

3. 如果一定要用復(fù)制架構(gòu)，同時(shí)又要絕對(duì)的一致性，考慮使用增強(qiáng)半同步after_sync結(jié)合session_track_gtids功能使用。

4. 復(fù)制推薦使用after_sync,同樣要求半同步不允許退化成為異步。
5. 深入理解復(fù)制的原理，避免不適當(dāng)?shù)牟僮髟斐蓮?fù)制一致性：?大事務(wù)，較長(zhǎng)DDL等操作。如果必須操作，可以考慮一些特殊的運(yùn)維方式操作。

孔子曰：三人行，必有我?guī)煛４竽懡涣?，不恥下問(wèn)。加油，學(xué)到了才是真本事。歡迎交流指正。沒(méi)有評(píng)論的公眾號(hào)有點(diǎn)缺乏靈魂，靈魂需要你。
? ? ? ? ? ? ? ?