原因主要就是io，網路，和cpu，一搬cpu不會跑的太滿，主要還在網路和io上，因為是讀日誌，一定會出現延時，就看這個延時是否接受，業務場景如果對延時不敏感，可以從slave讀取，如果是敏感，就可以控制從master讀，以免延時帶來讀髒資料的問題

問題描述的是DBA進行DDL操作（即索引合併）後就出現了複製延遲。

這裡可能的原因是：執行DDL需要一段時間，由於MySQL傳統複製是非同步複製，需要等到主庫執行完成後才會將DDL語句傳輸到從庫，在從庫應用。所以出現了主從延遲，這種情況的延遲時間基本跟DDL在主庫的執行時間吻合。判斷方法：可以透過對比主從延遲時間和主庫執行DDL時間來判讀是否是這個原因。另附上MySQL傳統主從複製的原理：

（1）、主庫必須開啟二進位制日誌

（2）、當有增刪改的語句時，會記錄到主庫的binlog中

（3）、主庫透過IO執行緒把binlog裡面的內容傳給從庫的relay binlog（中繼日誌）（這是msyql複製是非同步複製的原因）

（4）、從庫的sql執行緒負責讀取它的relay log裡的資訊並應用到資料庫中

group_replication_member_expel_timeout 指定組複製組成員在產生懷疑之後，從組中排除懷疑失敗的成員之前等待的時間（以秒為單位）。在產生懷疑之前的最初 5 秒檢測時間不計入該時間。直到幷包括 MySQL 8.0.20 在內，group_replication_member_expel_timeout 預設值均為 0，這意味著沒有等待時間，並且在 5 秒鐘的檢測時間結束後，可疑成員應立即被驅逐。從 MySQL 8.0.21 開始，該值預設為 5，這意味著在 5 秒鐘的檢測時間後如果該節點還是不正常，那會在等 5 秒鐘，如果可疑成員還是不正常，超過這個時間將被驅逐。

為驗證該引數對叢集影響，我們透過實驗模擬不同時長的網路延遲，然後調整group_replication_member_expel_timeout 值觀察該引數值對叢集驅逐故障節點的影響。

主從複製有兩個執行緒，sql和io。前者負責sql的複製，後者負責寫入。所以就是從兩方面看，當網路比較差，或者頻寬受限，或者master cpu過於繁忙導致binlog傳輸速度跟不上，或者slave機器的io效能較差，都容易導致主從複製延遲。可以透過show slave status的一些引數看出來，大概是xx_behind_master。mysql的主從其實問題很大，設計的比較low。至少三年多沒跟過mysql了，不知道這方面有沒有什麼改進。