MYSQL8 P_S 及新版在MGR 中的變化有哪些

MYSQL8 P_S 及新版在MGR 中的變化有哪些，相信很多沒有經驗的人對此束手無策，為此本文總結了問題出現的原因和解決方法，通過這篇文章希望你能解決這個問題。

隨著MYSQL 8 越來越成熟，未來MYSQL 將會開始替換 MYSQL 5.7X成為新的MYSQL 數據庫在市面上的主力。

而MYSQL 8 在 P_S （performance_schema）中的一些變化，以及如何更好的monitor MGR 這是一個值得去學習的地方。

在MYSQL 8 后P_S 引入了 XCOM, GCS兩個信息，這主要是要增加MGR的可觀測性和管理性。

1  在thread中引入了部分Xcom GCS 信息，

這四個線程主要啟動的作用

Gcs_ext_logger_impl::m_consumer  處理有關任何觸發點后的日志信息記錄線程

Gcs_xcom_engine::m_engine_thread  處理GCS 中的事件線程

Gcs_xcom_control::m_xcom_thread  負責xcom的運行線程

Gcs_xcom_control::m_suspicions_processing_thread 處理意外情況驅逐節點的線程

2 在等待事件表中也可以查看關于這兩方面的等待信息

首先我們需要打開相關的等待時間的記錄開關

在打開后，我們可以通過查看相關的等待記錄，或歷史等待記錄，來了解MGR 在使用過程中有哪些問題細節。具體哪些等待事件對應哪些問題，可以通過查看官方文檔來解決。

并且在 Replication_group_member_stats

中在MYSQL 8 添加了一些字段

1 COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE

從接收組中的事務在等待隊列

2 COUNT_TRANSACTIONS_REMOTE_APPLIED

成員已經從應用組中應用的事務

3 COUNT_TRANSACTION_LOCAL_PROPOSED

群組中協同的事務數量

4 COUNT_TRANSACTION_LOCAL_ROLLEDBACK

群組中進行rollback的事務數量、

并且最近從愛可生發布的文章，中提到了Large Messages Fragmentation Layer for Group Replication，這是對于MGR中被人提到的大事務造成的MGR 主機離線的問題的一個解決方法，通過對事務打散后在重新組裝的方式來進行大事務的集群化的處理。

除此之外MYSQL 8.016 還在，同時 XCom’s message cache 不在是綁定一個靜態的數字，而是開始進行動態的設定根據消息的大小開始變化。

而最新的8.016版本支持 Auto-rejoin for Group Replication，未來新版本中被踢出的MYSQL 很可能可以自動重新加入，不在依賴手工進行加載。

發展的速度太快，一步跟不上，步步跟不上。

看完上述內容，你們掌握MYSQL8 P_S 及新版在MGR 中的變化有哪些的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注億速云行業資訊頻道，感謝各位的閱讀！