濮阳杆衣贸易有限公司

主頁 > 知識庫 > 簡述mysql監(jiān)控組復制

簡述mysql監(jiān)控組復制

熱門標簽:廣東400企業(yè)電話申請流程 咸陽防封電銷卡 宜賓全自動外呼系統(tǒng)廠家 新鄉(xiāng)智能外呼系統(tǒng)好處 臨沂做地圖標注 許昌外呼增值業(yè)務線路 申請400電話電話價格 石家莊400電話辦理公司 地圖標注客戶付款

原文:https://dev.mysql.com/doc/refman/8.0/en/group-replication-monitoring.html
譯者:kun
最近在翻譯MySQL8.0官方文檔 本文是第18.3“監(jiān)控組復制”部分。

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

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

  • performance_schema.replication_group_member_stats
  • performance_schema.replication_group_members

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

  • performance_schema.replication_connection_status 顯示有關組復制的信息,例如,已從組接收并在應用程序隊列中排隊的事務(中繼日志)。
  • performance_schema.replication_applier_status 顯示與組復制相關的通道和線程的狀態(tài),如果有許多不同的工作線程應用事務,那么這個表也可用于監(jiān)視每個工作線程正在執(zhí)行的操作。

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

  • group_replication_recovery - 此通道用于與分布式恢復階段相關的復制更改。
  • group_replication_applier - 此通道用于來自組的傳入更改。并且應用直接來自組的事務的通道。

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

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

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

Server State

Field 描述 組同步
ONLINE 該成員可以作為一個具有所有功能的組成員,這意味著客戶端可以連接并開始執(zhí)行事務。 yes
RECOVERING 該成員正在成為該組的有效成員,并且正處于恢復過程中,從數(shù)據源節(jié)點(數(shù)據源節(jié)點)接收狀態(tài)信息。 no
OFFLINE 插件已加載,但成員不屬于任何組。 no
ERROR 本地成員的狀態(tài)。 只要恢復階段或應用更改時出現(xiàn)錯誤,server就會進入此狀態(tài)。 no
UNREACHABLE 每當本地故障檢測器懷疑某個給定的server可能由于已經崩潰或被意外地斷開而不可訪問時,server的狀態(tài)顯示為“UNREACHABLE” no

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

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

3.replication_group_members表

performance_schema.replication_group_members 表用于監(jiān)視作為組成員的不同server實例的狀態(tài)。每當視圖更改時,表replication_group_members就會更新,例如,當組的配置動態(tài)更改時。在此基礎上,server成員之間交換他們的一些元數(shù)據以保持同步并繼續(xù)協(xié)作。信息在組復制成員之間共享,因此可以從任何成員查詢有關所有組成員的信息。此表可用于獲取復制組狀態(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     |+---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+----------------+

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

4. Replication_group_member_stats

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

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

表 replication_group_member_stats

field 描述
CHANNEL_NAME 組復制通道的名稱。
VIEW_ID 此組的當前視圖標識符。
Member_id 此值為我們當前連接到的server成員的UUID。組中的每個成員具有不同的值。因為它對每個成員是唯一的,所以它也成為了一個關鍵字。
Count_transactions_in_queue 隊列中等待沖突檢測檢查的事務數(shù)。沖突檢查通過后,他們排隊等待應用。
Count_transactions_checked 表示已進行過沖突檢查的事務數(shù)。
Count_conflicts_detected 表示未通過沖突檢測檢查的事務數(shù)。
Count_transactions_rows_validating 表示沖突檢測數(shù)據庫的當前大?。總€事務經過驗證的數(shù)據庫)。
Transactions_committed_all_members 表示已在當前視圖的所有成員上成功提交的事務。 此值以固定的時間間隔更新。
Last_conflict_free_transaction 顯示最后一個經檢查無沖突的事務標識符。
Count_transactions_remote_in_applier_queue 此成員從復制組收到的等待應用的事務數(shù)。
Count_transactions_remote_applied 此成員從已應用的復制組收到的事務數(shù)。
Count_transactions_local_proposed 此成員發(fā)起并發(fā)送到復制組以進行協(xié)調的事務數(shù)。
Count_transactions_local_rollback 此成員發(fā)起的事務在發(fā)送到復制組后的回滾數(shù)。

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

以上就是簡述mysql監(jiān)控組復制的詳細內容,更多關于mysql監(jiān)控組復制的資料請關注腳本之家其它相關文章!

您可能感興趣的文章:
  • 詳解MySQL監(jiān)控工具 mysql-monitor
  • 詳解MySQL 表中非主鍵列溢出情況監(jiān)控
  • 使用Grafana+Prometheus監(jiān)控mysql服務性能
  • zabbix監(jiān)控Nginx/Tomcat/MySQL的詳細教程
  • mysql索引使用率監(jiān)控技巧(值得收藏!)
  • 關于對mysql語句進行監(jiān)控的方法詳解
  • zabbix監(jiān)控MySQL主從狀態(tài)的方法詳解
  • MySQL數(shù)據庫監(jiān)控軟件lepus使用問題以及解決辦法
  • 利用Prometheus與Grafana對Mysql服務器的性能監(jiān)控詳解
  • MySQL實時監(jiān)控工具orztop的使用介紹
  • 實戰(zhàn)模擬監(jiān)控MySQL服務shell腳本小結
  • 安裝配置Zabbix來監(jiān)控MySQL的基本教程

標簽:日照 鷹潭 貴州 阜新 北京 臺灣 鎮(zhèn)江 合肥

巨人網絡通訊聲明:本文標題《簡述mysql監(jiān)控組復制》,本文關鍵詞  簡述,mysql,監(jiān)控,組,復制,;如發(fā)現(xiàn)本文內容存在版權問題,煩請?zhí)峁┫嚓P信息告之我們,我們將及時溝通與處理。本站內容系統(tǒng)采集于網絡,涉及言論、版權與本站無關。
  • 相關文章
  • 下面列出與本文章《簡述mysql監(jiān)控組復制》相關的同類信息!
  • 本頁收集關于簡述mysql監(jiān)控組復制的相關信息資訊供網民參考!
  • 推薦文章
    泗水县| 庄河市| 饶平县| 盐池县| 九江县| 高尔夫| 行唐县| 弥渡县| 太白县| 宽甸| 新野县| 淮南市| 太湖县| 繁峙县| 哈密市| 濉溪县| 汉沽区| 广汉市| 莱西市| 顺义区| 邓州市| 临夏市| 依安县| 荔浦县| 南澳县| 楚雄市| 萨迦县| 同心县| 营口市| 右玉县| 松桃| 日喀则市| 东阳市| 沈阳市| 广东省| 揭西县| 盐津县| 四平市| 远安县| 普兰店市| 诏安县|