监控组复制
可以使用performance_schema来监控组复制,performance_schema中的表展示了组复制的特定的信息:
replication_group_member_stats:参考 第20.4.4节
replication_group_members:参考 第20.4.3节
replication_group_communication_information:参考 第29.12.11.15节
如下的这些performance_schema复制表也展示了组复制的相关信息:
replication_connection_status展示了组复制的相关信息,如从组接收并在应用者队列(relay log)中排队的事务。
replication_applier_status展示了和组复制相关的channel和线程的状态。这个也可以监控独立的worker线程在做什么
组复制插件创建的复制通道如下:
group_replication_recovery:此通道用于与分布式恢复阶段复制相关的变更数据 。
group_replication_applier:此通道用于组状态正常的情况下,复制(接收)来自组的变更数据。
有关影响组复制的系统变量信息,参考第 20.9.1 节 “组复制系统变量”。有关提供组复制信息的状态变量,参考第 20.9.2 节 “组复制状态变量”。
从 MySQL 8.0.21 开始,与组复制生命周期事件相关的消息(除错误外)被分类为系统消息;这些消息始终写入组复制成员的错误日志。您可以使用该信息来查看某个服务器在复制组中的成员资格历史。(在之前,这些事件被分类为信息消息(information messages);对于 MySQL 8.0.21之前的版本,可以通过将log_error_verbosity设置为3将其添加到错误日志中。)
影响整个组的一些生命周期事件会在每个组成员上记录,例如新成员进入ONLINE状态或进行主节点选举。其他事件仅在事件发生的成员上记录,例如在成员上启用或禁用超级只读模式,或成员离开组。如果发生频繁,一些可能指示问题的生命周期事件将记录为警告消息,包括成员变得无法访问然后再次可访问,以及成员通过从二进制日志进行状态传输或通过远程克隆操作开始分布式恢复。
注意
如果您正在使用mysqladmin监视一个或多个secondary实例,该实用程序执行的FLUSH STATUS语句会在本地实例上创建一个 GTID 事件
,这可能会影响未来的组操作。