组复制官方翻译四、Monitoring Group Replication

简介: https://dev.mysql.com/doc/refman/8.0/en/group-replication-monitoring.html使用Perfomance Schema来监控MGRMGR主要添加了这两个表performance_schema.

https://dev.mysql.com/doc/refman/8.0/en/group-replication-monitoring.html

使用Perfomance Schema来监控MGR

MGR主要添加了这两个表

  • performance_schema.replication_group_member_stats
  • performance_schema.replication_group_members

关于MGR复制相关的表

  • performance_schema.replication_connection_status
  • performance_schema.replication_applier_status

MGR创建了两个复制通道

  • group_replication_recovery: 主要是分布式恢复阶段的replication changes
  • group_replication_applier:主要用作来组group的 incoming changes

18.3.1 Group Replication Server States

如果servers之间协作正常,那么看到的state都是一样的
但是,一旦发生网络分区,或者有server挂掉并脱离group,那么不同信息就会被报告出来
如果一个server离开了这个group,那么它就不能上报其他server的状态信息
如果发生了网络分区,那么仲裁法定人数就缺少,servers之间就不能很好的协作,他们只能猜测其他server的状态并报告为unreachable

  • Table 18.1 Server State
字段 描述 组同步
ONLINE 用户可正常连接和执行事务 yes
RECOVERING 正在从donar服务器同步数据 no
OFFLINE 插件已经装载,但是该成员不属于任何组 no
ERROR 无论是recovery阶段,还是应用事务更新,表示遇到错误了 no
UNREACHABLE 失联了 no

重要:一旦实例的状态变成了ERROR,super_read_only 会被设置成on
如果ERROR状态消失,需要人工介入调整super_read_only=OFF

注意:MGR不是强同步的,但是最终会一致的
确切的说:事务会按照相同的顺序发送给这个group的所有成员,但是事务的执行、commit完全由成员自行处理,并不是同步进行的

18.3.2 The replication_group_members Table

performance_schema.replication_group_members 这个表主要用来监控不同成员的状态
表里面的信息会自动更新,如果有新成员的加入或离开
每个成员的元数据信息都是共享的,可以被其他成员随时查到
这个表主要是在比较高的层面来看复制group的一些状态信息,比如:

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         |
+---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+----------------+

从上面的输出可以看出: 这个组由3个成员组成,每个成员的host、port、server-uuid一清二楚
MEMBER_STATE显示他们都是online状态
MEMBER_ROLE这列显示 有2个secondaries,1个primary,因此这个group是一个single-primary 模式的GR
MEMBER_VERSION这列在某些场景对你非常重要,比如:你需要升级一个group,或者将不同mysql版本的server组合在一起的时候

18.3.3 Replication_group_member_stats

每个组的成员认证和执行事务两步
关于认证和执行事务的一些统计信息对明白applier queue(有多少冲突被发现了,多少事务被check了,哪些事务被commit了 等等)的增长非常有用

performance_schema.replication_group_member_stats 提供了group-level 级别的认证、统计等很多信息
这里面的信息是所有成员共享的,任何成员都能查得到
值得注意的是:刷新远程成员的统计信息是根据 group_replication_flow_control_period选项,所以在本地查的信息可能互相有点延迟,有点差异是正常现象

  • Table 18.2 replication_group_member_stats
字段 描述
Channel_name GR通道的名称
View_id group的当前view id
Member_id 成员的uuid
Count_transactions_in_queue 需要被检测的冲突事务数量
Count_transactions_checked 已经被检测为冲突的事务数量
Count_conflicts_detected 没有通过冲突检测的事务数量
Count_transactions_rows_validating 冲突检测数据库的大小
Transactions_committed_all_members 所有成员都commit成功的事务集
Last_conflict_free_transaction The transaction identifier of the last conflict free transaction checked.
Count_transactions_remote_in_applier_queue 有多少远程事务在队列里面需要被执行
Count_transactions_remote_applied 已经被执行过的远程事务数量
Count_transactions_local_proposed 本地产生的需要被其他远程成员执行的事务数量
Count_transactions_local_rollback 本地产生的事务,有多少是发送给其他成员,后面又被自己rollback的事务数量

这些信息对监控MGR非常重要
举个例子:假设这个group中的一个成员延迟了,无法跟上其他成员,那么你会看到queue里面有很多事务
通过以上信息,你可以决定是要移除这个成员,还是延迟在其他成员中处理这些事务来减少这个队列中的事务数量
通过以上信息,也能帮助你决定是否需要开启MGR的流控措施

目录
相关文章
|
4月前
|
存储 安全
【Azure Policy】使用deployIfNotExists 把 Azure Activity logs 导出保存在Storage Account
本文描述了如何使用 Azure Policy 对订阅下的所有 Activity Log 配置 Diagnostic Setting。具体要求包括:在 Subscription 或 Management Group 级别启用 Activity Log 功能、纠正已启用 Activity Log 的订阅参数配置、将日志存储在特定 Storage Account 中并保留 6 个月,以及收集特定类型的日志(如 Administrative、Security、Alert、Recommendation 和 ResourceHealth)。文章还介绍了常见错误及解决方法,并提供了相关参考链接。
61 9
|
5月前
【Azure 环境】如果Azure中的某一个资源被删除后是否可以查看到删除的记录呢?如Resource Group
【Azure 环境】如果Azure中的某一个资源被删除后是否可以查看到删除的记录呢?如Resource Group
|
NoSQL MongoDB
《MongoShake -- Multi Active-Active and Cross-Region Disaster Recoverable MongoDB Service》电子版地址
MongoShake -- Multi Active-Active and Cross-Region Disaster Recoverable MongoDB Service
92 0
《MongoShake -- Multi Active-Active and Cross-Region Disaster Recoverable MongoDB Service》电子版地址
|
关系型数据库 MySQL
组复制官方翻译六、Upgrading Group Replication
https://dev.mysql.com/doc/refman/8.0/en/group-replication-upgrade.html 这个章节主要描述升级MGR的计划基本的升级MGR成员的方法基本跟单独的实例升级一样(可参考 Section 2.
1569 0
|
监控 安全 关系型数据库
组复制官方翻译一、Group Replication
https://dev.mysql.com/doc/refman/8.0/en/group-replication.html 目录 18.1 Group Replication Background 18.
1687 0
|
网络协议 网络安全
组复制官方翻译五、Group Replication Security
https://dev.mysql.com/doc/refman/8.0/en/group-replication-security.html 18.5.1 IP Address Whitelisting MGR有个配置项可以决定哪些server可以被GR接受,它就是group_replicati...
1520 0
|
SQL 关系型数据库 MySQL
组复制官方翻译九、Group Replication Technical Details
https://dev.mysql.com/doc/refman/8.0/en/group-replication-technical-details.html 这一章主要描述MGR的更多细节 18.
1777 0
组复制官方翻译二、Group Replication Background
https://dev.mysql.com/doc/refman/8.0/en/group-replication-background.html 这一章主要描述一些组复制的背景 构建一个容错系统最常用的方法就是让组件冗余,换句话说就是组件即便被移除掉,整个系统还是能够正常对外提供服务这无疑在不同...
1544 0
|
关系型数据库 MySQL
组复制官方翻译三、Getting Started
https://dev.mysql.com/doc/refman/8.0/en/group-replication-getting-started.html MGR 作为一个Server插件提供支持的,每个group的server都需要配置和加载这个插件这一章主要教大家在三节点的MGR环境下,怎么一步步搭建起来的 18.
1390 0
|
前端开发
组复制官方翻译八、Frequently Asked Questions
https://dev.mysql.com/doc/refman/8.0/en/group-replication-frequently-asked-questions.html 一、MGR的成员数量最大是多少 最大9个 二、group中的成员是如何连接的 他们直接是通过peer-to-peer ...
1562 0