MGR測試過程中出現的問題彙總

MGR出現的問題大概總結為以下幾點：

1．每次提交事務時儘量控制單次操作事務的資料量，減少大事物在其他節點check的時間和堵塞後面的操作帶來的叢集複製延遲，如事務回滾影響更大；

2．MGR叢集環境部署對網路的依賴性較強，網路延時會導致整個叢集效能的下降，叢集內伺服器儘量保持配置一致，叢集內其中一伺服器效能不好也會影響整個叢集的整體效能；

3．DDL操作時，如操作的table有事物執行，在ddl時間內的所有的 插入，更新和刪除操作記錄到一個日誌檔案，然後再把這些增量資料應用到相應的表上(等表上的事務完全釋放後)，日誌大小受innodb_online_alter_log_max_size引數限制，如寫一直持續innodb_online_alter_log_max_size引數大小不好人為控制，會導致ddl執行失敗；

4．Mysqldump會直接影響叢集效能，xtrbackup因對磁碟io佔用也會間接影響叢集效能，建議備份節點考慮在mgr叢集下掛載slave節點上執行備份；

5．版本升級，5.6在開啟gtid後可直接升級至5.7.17並開啟組複製模式；5.5版本則需要升級到5.6版本過渡一下才可升級為組複製模式。由於5.6、5.7版本上時間型別time,timestamp,datetime精度都支援到微秒精度，從5.5升級後帶來的影響需要評估；

6．資料校驗，現有工具Pt-table-checksum並不支援MGR叢集的校驗，僅可以對slave節點資料校驗；

7．流量控制，當certifer_queue佇列深度大於flow_crontrol_ certifer_threshold或者applier_queue佇列深度大於flow_crontrol_ applier_threshold值時會觸發流控制，觸發流控制後寫入會降低，這是為了避免更大的複製延遲，但是觸發流控制後前端應用就會感覺可用率的下降，所以這個引數是個雙刃劍，要根據實際生產環境設定，並且certifer_queue和applier_queue佇列深度暫時沒有監控項可監控，後期帶來的運維問題也需要考慮；

8．MGR叢集最多為9個節點，以5節點叢集為例，叢集內2個節點故障時，其餘3個節點是可以繼續提供服務的，但是當叢集內有3個節點故障時，剩餘2個節點就不能提供服務了，此時需要人工處理，如處理不當極容易發生腦裂現象。