[mysql] 17.3 mysql MGR监控

假设已启用Performance Schema，请使用Perfomance Schema 表来监视组复制 。组复制将添加到以下下表：

performance_schema.replication_group_member_stats

performance_schema.replication_group_members

这些Performance Schema复制表还显示有关组复制的信息：

performance_schema.replication_connection_status ：显示有关组复制的信息，例如已从组接收并在应用程序队列（中继日志）中排队的事务。

performance_schema.replication_applier_status ：显示与组复制相关的通道和线程的状态。如果有许多不同的工作线程在应用事务，那么工作表也可以用来监视每个工作线程在做什么。

由组复制插件创建的复制通道被命名为：

group_replication_recovery -此通道用于与分布式恢复阶段相关的复制。

group_replication_applier-此通道用于来自组的传入更改。这是应用直接来自该组的事务的通道。

17.3.1 Group Replication Server States（组复制服务状态）

服务实例可能处于多种状态。如果服务器正常通信，则所有服务均报告相 同的状态。但是，如果存在网络分区，或者服务器离开了该组，可能会报告不同的信息，这个取决于要查询的服务器。如果服务已离开组，则它无法报告有关其他服务器状态信息。如果存在一个分区，导致仲裁丢失，则服务器将无法在它们之间进行协调。结果，他们无法知道不同服务的状态。而它们无法知道状态，会报告某些服务器不可达。

Table 17.1 Server State

状态

描述

组同步

ONLINE

该成员随时可以充当功能齐全的组成员，这意味着客户端可以连接并开始执行事务。

Yes

RECOVERING

该成员正在成为该组的活跃成员，并且正在接受恢复过程，正在从donor那里接收状态信息。

No

OFFLINE

插件已加载，但成员不属于任何组。

No

ERROR

成员的状态。每当恢复阶段发生错误或应用更改时，服务器都会进入此状态。

No

UNREACHABLE

每当本地故障检测器怀疑给定服务器无法访问时（例如由于非自愿断开连接），它将显示该服务器的状态为UNREACHABLE。

No

注意

一旦实例进入ERROR状态，super_read_only 选项将设置为ON。要退出ERROR 状态，必须使用手动配置实例 super_read_only=OFF。

请注意，组复制不是 同步的，但最终是同步的。更确切地说，事务以相同的顺序交付给所有组成员，但是它们的执行不同步，这意味着在接受了要提交的事务之后，每个成员都按照自己的进度进行事务。

17.3.2 The replication_group_members Table

performance_schema.replication_group_members 表用于监视属于该组成员的不同服务器实例的状态。只要有视图更改，表中的信息就会更新，例如，当新成员加入时动态更改组的配置时。此时，服务器交换一些元数据以同步自己并继续合作。该信息在属于复制组的所有服务器实例之间共享，因此可以从任何成员查询有关所有组成员的信息。该表可用于获取复制组状态的高级视图，例如，通过如下命令：

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

根据此结果，我们可以看到该组由三个成员组成，每个成员的客户端用于连接到该成员的主机和端口号，以及 server_uuid及MEMBER_STATE，在这种情况下，它显示该组中的所有三个成员均为 ONLINE，并且该MEMBER_ROLE 列显示有两个辅助服务器和一个主服务器。因此，该组必须在单主式下运行。MEMBER_VERSION，当您升级组并合并运行不同Mysql版本的成员时，该列将非常有用。

17.3.3 The replication_group_member_stats Table

复制组中的每个成员都认证并应用接收的事务。有关验证和应用过程的统计信息对于了解应用队列的增长，多少冲突被发现，多少事务被检查，什么事务被提交等很有用。

该 performance_schema.replication_group_member_stats 表提供了与认证过程相关的组级别信息，还提供了复制组的每个单独成员接收和发起的事务的统计信息。该信息在属于复制组的所有服务器实例之间共享，因此可以从任何成员查询有关所有组成员的信息。请注意，刷新远程成员的统计信息是由该group_replication_flow_control_period 选项中指定的消息周期控制的 ，因此，这些时间可能与进行查询的成员在本地收集的统计信息略有不同。要使用此表监视组复制成员，如下：

mysql> SELECT * FROM performance_schema.replication_group_member_stats\G

这些字段对于监视组中连接的成员的性能很重要。例如，假设与其他成员相比，该组的成员之一始终在其队列中报告大量事务。这意味着该成员被延迟，无法与该组的其他成员保持最新。根据此信息，可以决定从该组中删除该成员，或延迟对该组其他成员的事务处理，以减少排队的事务数。此信息还可以帮助您决定如何调整组复制插件的流控制。

MySQL

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。