MySQL監(jiān)控組復制是什么

MySQL監(jiān)控組復制是什么，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

1. 監(jiān)控組復制

假設(shè)MySQL已經(jīng)在啟用了性能模式的情況下編譯，使用Perfomance Schema表監(jiān)控組復制。組復制添加以下表：

• performance_schema.replication_group_member_stats

• performance_schema.replication_group_members

這些現(xiàn)有的Perfomance Schema復制表也顯示有關(guān)組復制的信息：

• performance_schema.replication_connection_status 顯示有關(guān)組復制的信息，例如，已從組接收并在應用程序隊列中排隊的事務（中繼日志）。

• performance_schema.replication_applier_status 顯示與組復制相關(guān)的通道和線程的狀態(tài)，如果有許多不同的工作線程應用事務，那么這個表也可用于監(jiān)視每個工作線程正在執(zhí)行的操作。

Group Replication插件創(chuàng)建的復制通道命名為：

• group_replication_recovery - 此通道用于與分布式恢復階段相關(guān)的復制更改。

• group_replication_applier - 此通道用于來自組的傳入更改。并且應用直接來自組的事務的通道。

以下部分描述了每個表中可用的信息。

1.1 組成員實例狀態(tài)

組中的server實例可以處于多種狀態(tài)。如果server都正常通信，則所有server都報告相同的狀態(tài)。但是，如果存在網(wǎng)絡分隔，或者組成員離開組，則可能報告不同的信息，這取決于查詢了哪個server。要注意的是，如果某個組成員已經(jīng)離開組，那么顯然它不能報告關(guān)于其他server狀態(tài)的最新信息。如果發(fā)生網(wǎng)絡分隔，如果超出仲裁數(shù)量的server都斷開了，那么server之間將不能相互協(xié)作。因此，他們無法得知不同server成員的狀態(tài)。因此，他們會報告一些server不可訪問，而不是猜測他們的狀態(tài)。

表1.1 Server State

Important

一旦實例進入ERROR狀態(tài)后，該 super_read_only選項將設(shè)置為ON。要離開ERROR 狀態(tài)，您必須手動配置實例super_read_only=OFF

需要注意的是，組復制不是同步復制，但最終是同步的。更確切地說，事務以相同的順序傳遞給所有組成員，但是它們的執(zhí)行不同步，這意味著在接受事務被提交之后，每個成員以其自己的速度提交。

1.2 replication_group_members表

該 performance_schema.replication_group_members 表用于監(jiān)視作為組成員的不同server實例的狀態(tài)。每當視圖更改時，表replication_group_members就會更新，例如，當組的配置動態(tài)更改時。在此基礎(chǔ)上，server成員之間交換他們的一些元數(shù)據(jù)以保持同步并繼續(xù)協(xié)作。信息在組復制成員之間共享，因此可以從任何成員查詢有關(guān)所有組成員的信息。此表可用于獲取復制組狀態(tài)的高級視圖，例如通過發(fā)出：

SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+----------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST  | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |
+---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+----------------+
| group_replication_applier | 041f26d8-f3f3-11e8-adff-080027337932 | example1     |      3306   | ONLINE       | SECONDARY   | 8.0.13         |
| group_replication_applier | f60a3e10-f3f2-11e8-8258-080027337932 | example2     |      3306   | ONLINE       | PRIMARY     | 8.0.13         |
| group_replication_applier | fc890014-f3f2-11e8-a9fd-080027337932 | example3     |      3306   | ONLINE       | SECONDARY   | 8.0.13         |
+---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+----------------+

根據(jù)這個結(jié)果，我們可以看到該組由三個成員組成，每個成員的主機和端口號，客戶端用來連接成員，以及成員的 server_uuid。該MEMBER_STATE列顯示了 第18.3.1節(jié)“組成員實例狀態(tài)”之一，在該情況下，它顯示該組中的所有三個成員都是 ONLINE，并且該MEMBER_ROLE 列顯示有兩個從節(jié)點和一個主節(jié)點。因此，該組必須是以單主模式運行的。MEMBER_VERSION當您升級組并且組合中正在運行不同MySQL版本的成員時，該列可能很有用。請參見 第18.3.1節(jié)“組成員實例狀態(tài)” 獲得更多信息。

有關(guān)Member_host 值及其對分布式恢復過程的影響的更多信息，請參見 第18.2.1.3節(jié)“用戶憑據(jù)”。

1.3 Replication_group_member_stats

復制組中的每個成員都會驗證并應用該組提交的事務。有關(guān)驗證和應用程序的統(tǒng)計信息對于了解申請隊列增長情況、觸發(fā)了多少沖突、檢查了多少事務、哪些事務已被所有成員提交等等非常有用。

該 performance_schema.replication_group_member_stats 表提供與認證過程相關(guān)的組級信息，以及由復制組的每個成員接收和發(fā)起的事務的統(tǒng)計信息。信息在組成員實例之間共享，因此可以從任何成員查詢有關(guān)所有組成員的信息。請注意，刷新遠程成員的統(tǒng)計信息由group_replication_flow_control_period 選項中指定的消息周期控制 ，因此這些信息可能與進行查詢的成員的本地收集的統(tǒng)計信息略有不同。

表1.2 replication_group_member_stats

這些字段對于監(jiān)控組中的成員的性能很重要。例如，假設(shè)組的成員之一出現(xiàn)延遲，并且不能與該組的其他成員同步。在這種情況下，您可能會在隊列中看到大量的事務?；诖诵畔?，您可以決定從組中刪除成員或延遲組中其他成員的事務處理，從而減少排隊的事務的數(shù)量。此信息還可以幫助您決定如何調(diào)整組復制插件的流控制。

關(guān)于MySQL監(jiān)控組復制是什么問題的解答就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關(guān)注億速云行業(yè)資訊頻道了解更多相關(guān)知識。