MySQL監(jiān)控組復(fù)制是什么，針對這個(gè)問題，這篇文章詳細(xì)介紹了相對應(yīng)的分析和解答，希望可以幫助更多想解決這個(gè)問題的小伙伴找到更簡單易行的方法。
公司專注于為企業(yè)提供網(wǎng)站建設(shè)、網(wǎng)站設(shè)計(jì)、微信公眾號開發(fā)、購物商城網(wǎng)站建設(shè)，成都小程序開發(fā)，軟件按需求定制設(shè)計(jì)等一站式互聯(lián)網(wǎng)企業(yè)服務(wù)。憑借多年豐富的經(jīng)驗(yàn)，我們會(huì)仔細(xì)了解各客戶的需求而做出多方面的分析、設(shè)計(jì)、整合，為客戶設(shè)計(jì)出具風(fēng)格及創(chuàng)意性的商業(yè)解決方案，成都創(chuàng)新互聯(lián)公司更提供一系列網(wǎng)站制作和網(wǎng)站推廣的服務(wù)。
假設(shè)MySQL已經(jīng)在啟用了性能模式的情況下編譯，使用Perfomance Schema表監(jiān)控組復(fù)制。組復(fù)制添加以下表：
performance_schema.replication_group_member_stats
performance_schema.replication_group_members
這些現(xiàn)有的Perfomance Schema復(fù)制表也顯示有關(guān)組復(fù)制的信息：
performance_schema.replication_connection_status 顯示有關(guān)組復(fù)制的信息，例如，已從組接收并在應(yīng)用程序隊(duì)列中排隊(duì)的事務(wù)（中繼日志）。
performance_schema.replication_applier_status 顯示與組復(fù)制相關(guān)的通道和線程的狀態(tài)，如果有許多不同的工作線程應(yīng)用事務(wù)，那么這個(gè)表也可用于監(jiān)視每個(gè)工作線程正在執(zhí)行的操作。
Group Replication插件創(chuàng)建的復(fù)制通道命名為：
group_replication_recovery - 此通道用于與分布式恢復(fù)階段相關(guān)的復(fù)制更改。
group_replication_applier - 此通道用于來自組的傳入更改。并且應(yīng)用直接來自組的事務(wù)的通道。
以下部分描述了每個(gè)表中可用的信息。
組中的server實(shí)例可以處于多種狀態(tài)。如果server都正常通信，則所有server都報(bào)告相同的狀態(tài)。但是，如果存在網(wǎng)絡(luò)分隔，或者組成員離開組，則可能報(bào)告不同的信息，這取決于查詢了哪個(gè)server。要注意的是，如果某個(gè)組成員已經(jīng)離開組，那么顯然它不能報(bào)告關(guān)于其他server狀態(tài)的最新信息。如果發(fā)生網(wǎng)絡(luò)分隔，如果超出仲裁數(shù)量的server都斷開了，那么server之間將不能相互協(xié)作。因此，他們無法得知不同server成員的狀態(tài)。因此，他們會(huì)報(bào)告一些server不可訪問，而不是猜測他們的狀態(tài)。
表1.1 Server State
| Field | 描述 | 組同步 |
|---|---|---|
ONLINE | 該成員可以作為一個(gè)具有所有功能的組成員，這意味著客戶端可以連接并開始執(zhí)行事務(wù)。 | Yes |
RECOVERING | 該成員正在成為該組的有效成員，并且正處于恢復(fù)過程中，從數(shù)據(jù)源節(jié)點(diǎn)（數(shù)據(jù)源節(jié)點(diǎn)）接收狀態(tài)信息。 | No |
OFFLINE | 插件已加載，但成員不屬于任何組。 | No |
ERROR | 本地成員的狀態(tài)。 只要恢復(fù)階段或應(yīng)用更改時(shí)出現(xiàn)錯(cuò)誤，server就會(huì)進(jìn)入此狀態(tài)。 | No |
UNREACHABLE | 每當(dāng)本地故障檢測器懷疑某個(gè)給定的server可能由于已經(jīng)崩潰或被意外地?cái)嚅_而不可訪問時(shí)，server的狀態(tài)顯示為“UNREACHABLE” | No |
Important
一旦實(shí)例進(jìn)入
ERROR狀態(tài)后，該super_read_only選項(xiàng)將設(shè)置為ON。要離開ERROR狀態(tài)，您必須手動(dòng)配置實(shí)例super_read_only=OFF
需要注意的是，組復(fù)制不是同步復(fù)制，但最終是同步的。更確切地說，事務(wù)以相同的順序傳遞給所有組成員，但是它們的執(zhí)行不同步，這意味著在接受事務(wù)被提交之后，每個(gè)成員以其自己的速度提交。
該 performance_schema.replication_group_members 表用于監(jiān)視作為組成員的不同server實(shí)例的狀態(tài)。每當(dāng)視圖更改時(shí)，表replication_group_members就會(huì)更新，例如，當(dāng)組的配置動(dòng)態(tài)更改時(shí)。在此基礎(chǔ)上，server成員之間交換他們的一些元數(shù)據(jù)以保持同步并繼續(xù)協(xié)作。信息在組復(fù)制成員之間共享，因此可以從任何成員查詢有關(guān)所有組成員的信息。此表可用于獲取復(fù)制組狀態(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ù)這個(gè)結(jié)果，我們可以看到該組由三個(gè)成員組成，每個(gè)成員的主機(jī)和端口號，客戶端用來連接成員，以及成員的 server_uuid。該MEMBER_STATE列顯示了 第18.3.1節(jié)“組成員實(shí)例狀態(tài)”之一，在該情況下，它顯示該組中的所有三個(gè)成員都是 ONLINE，并且該MEMBER_ROLE 列顯示有兩個(gè)從節(jié)點(diǎn)和一個(gè)主節(jié)點(diǎn)。因此，該組必須是以單主模式運(yùn)行的。MEMBER_VERSION當(dāng)您升級組并且組合中正在運(yùn)行不同MySQL版本的成員時(shí)，該列可能很有用。請參見 第18.3.1節(jié)“組成員實(shí)例狀態(tài)” 獲得更多信息。
有關(guān)Member_host 值及其對分布式恢復(fù)過程的影響的更多信息，請參見 第18.2.1.3節(jié)“用戶憑據(jù)”。
復(fù)制組中的每個(gè)成員都會(huì)驗(yàn)證并應(yīng)用該組提交的事務(wù)。有關(guān)驗(yàn)證和應(yīng)用程序的統(tǒng)計(jì)信息對于了解申請隊(duì)列增長情況、觸發(fā)了多少?zèng)_突、檢查了多少事務(wù)、哪些事務(wù)已被所有成員提交等等非常有用。
該 performance_schema.replication_group_member_stats 表提供與認(rèn)證過程相關(guān)的組級信息，以及由復(fù)制組的每個(gè)成員接收和發(fā)起的事務(wù)的統(tǒng)計(jì)信息。信息在組成員實(shí)例之間共享，因此可以從任何成員查詢有關(guān)所有組成員的信息。請注意，刷新遠(yuǎn)程成員的統(tǒng)計(jì)信息由group_replication_flow_control_period 選項(xiàng)中指定的消息周期控制 ，因此這些信息可能與進(jìn)行查詢的成員的本地收集的統(tǒng)計(jì)信息略有不同。
表1.2 replication_group_member_stats
| Field | 描述 |
|---|---|
| CHANNEL_NAME | 組復(fù)制通道的名稱。 |
| VIEW_ID | 此組的當(dāng)前視圖標(biāo)識符。 |
| Member_id | 此值為我們當(dāng)前連接到的server成員的UUID。組中的每個(gè)成員具有不同的值。因?yàn)樗鼘γ總€(gè)成員是唯一的，所以它也成為了一個(gè)關(guān)鍵字。 |
| Count_transactions_in_queue | 隊(duì)列中等待沖突檢測檢查的事務(wù)數(shù)。沖突檢查通過后，他們排隊(duì)等待應(yīng)用。 |
| Count_transactions_checked | 表示已進(jìn)行過沖突檢查的事務(wù)數(shù)。 |
| Count_conflicts_detected | 表示未通過沖突檢測檢查的事務(wù)數(shù)。 |
| Count_transactions_rows_validating | 表示沖突檢測數(shù)據(jù)庫的當(dāng)前大?。總€(gè)事務(wù)經(jīng)過驗(yàn)證的數(shù)據(jù)庫）。 |
| Transactions_committed_all_members | 表示已在當(dāng)前視圖的所有成員上成功提交的事務(wù)。 此值以固定的時(shí)間間隔更新。 |
| Last_conflict_free_transaction | 顯示最后一個(gè)經(jīng)檢查無沖突的事務(wù)標(biāo)識符。 |
| Count_transactions_remote_in_applier_queue | 此成員從復(fù)制組收到的等待應(yīng)用的事務(wù)數(shù)。 |
| Count_transactions_remote_applied | 此成員從已應(yīng)用的復(fù)制組收到的事務(wù)數(shù)。 |
| Count_transactions_local_proposed | 此成員發(fā)起并發(fā)送到復(fù)制組以進(jìn)行協(xié)調(diào)的事務(wù)數(shù)。 |
| Count_transactions_local_rollback | 此成員發(fā)起的事務(wù)在發(fā)送到復(fù)制組后的回滾數(shù)。 |
這些字段對于監(jiān)控組中的成員的性能很重要。例如，假設(shè)組的成員之一出現(xiàn)延遲，并且不能與該組的其他成員同步。在這種情況下，您可能會(huì)在隊(duì)列中看到大量的事務(wù)?；诖诵畔ⅲ梢詻Q定從組中刪除成員或延遲組中其他成員的事務(wù)處理，從而減少排隊(duì)的事務(wù)的數(shù)量。此信息還可以幫助您決定如何調(diào)整組復(fù)制插件的流控制。
關(guān)于MySQL監(jiān)控組復(fù)制是什么問題的解答就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道了解更多相關(guān)知識。
重慶分公司
重慶分公司
