MySQL 組複製一致性 EVENTUAL 與 BEFORE_ON_PRIMARY_FAILOVER
據我了解，在發生故障轉移之前，它的
BEFORE_ON_PRIMARY_FAILOVER行為與正常情況完全一樣EVENTUAL，前者將阻止所有新事務，直到新的主節點應用其積壓，而後者允許事務立即執行。我在實驗室環境中嘗試了這兩種選擇。當複制延遲比較高時，新的主數據庫需要很長時間才能應用積壓並打開新事務。這會顯著影響 HA，使 Group Replication 的自動故障轉移功能幾乎毫無意義。
所以我的問題是，使用
BEFORE_ON_PRIMARY_FAILOVER而不是真的有益EVENTUAL嗎？這真的是一個“更安全”的選擇嗎？有關我的環境的一些資訊，以防萬一：MySQL 8.0.25，使用 TAR 球格式安裝。RHEL：8.0
最讓 DBA 熱血沸騰的是腦裂。
這是您開始向集群中的一個節點寫入更新，同時它仍在應用從其他節點之一複制的更新的場景的術語。因此，您很有可能對某行數據進行更新，但隨後它會被最初發生的複制更改覆蓋。
然後你剛剛送出的事務在另一個節點上執行。但是更改是基於過時的數據版本，因此它的值是錯誤的。現在兩個節點都沒有數據的“真實”狀態。
從這種錯誤中恢復是非常困難的。您必須以某種方式從日誌中重建正確的更改順序，然後從備份中恢復整個集群，然後以正確的順序重新執行更改。當然，應用程序所有者說您必須在沒有停機的情況下執行此操作，因此您不能中斷正在進行的流量或使數據庫離線來恢復它。
要做到這一點幾乎是不可能的，但是你很快就會讓上層的經理們對你大喊大叫，讓你立即解決這個問題。
這就是為什麼同步複製是值得的，即使它會延遲故障轉移。它可以防止腦裂，坦率地說，這比高吞吐量更重要。
如果您經常出現複製延遲，則切換到 EVENTUAL 不是一個好的解決方案。解決方案是要麼減少查詢流量，要麼提高伺服器的性能，直到組複製集群能夠跟上它而不會造成頻繁的複制延遲。
這是通過以下兩種方式之一完成的：
- **擴大規模：**獲得更快的 CPU、更快的儲存驅動器、更多的 RAM。
- **橫向擴展：**將數據拆分到多個集群上，並在集群之間或多或少地平均分配數據更新，因此每個集群只需要處理一小部分流量。
或者最終，您需要同時使用這兩種解決方案，因為您只能擴大規模。