最近在MGR 8.0.27中发现一个问题：

mysql> select a.member_id,a.member_host,a.member_role,b.COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE from performance_schema.replication_group_members a,        performance_schema.replication_group_member_stats b where a.MEMBER_ID=b.member_id;
+--------------------------------------+-------------+-------------+--------------------------------------------+
| member_id                            | member_host | member_role | COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE |
+--------------------------------------+-------------+-------------+--------------------------------------------+
| 6f450880-5e0c-11ec-9998-000c29e4ec4a | mgr10       | PRIMARY     |                                          1 |
| 97a04402-5dae-11ec-9190-000c29a8c42a | mgr11       | SECONDARY   |                                          0 |
+--------------------------------------+-------------+-------------+--------------------------------------------+

我们发现主节点的COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE值长期为1（或者大于1），不会变为0，即便没有压力也是如此。因为这是单主，这个地方我们前面的文章已经说过，这个值的定义和所取的值为

• COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE（m_transactions_waiting_apply） 来自于m_transactions_waiting_apply.load()，这个值在Applier_handler::handle_event函数增加，当pipeline的Applier_handler处理完成，也就是写入了relay log后增加。这个值在hook group_replication_trans_before_commit处进行减少，函数首先就会判断提交的事务是不是来自applier通道，如果是则进行减少。当然如果是主库我们事务提交是前台线程自己，而不是applier通道，所以不会影响这个值。

对于主节点来讲，应该是不会存在这种值的，因为主节点没有远端过来的GTID事务（注意不是消息是事务），并且偶尔这个值还会大于1，不会降低为0。

开始我最担心的是这个值不为1会影响节点的上线（online），但是在查看节点上线的逻辑后，应该是没什么影响的。把对这个BUG分析了一下，发现这个和8.0.27修复的一个BUG有关。

• BUG#33067441: COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE IS NOT UPDATED DURING RECOVERY

然后将分析过程，提交给官方

• https://bugs.mysql.com/bug.php?id=105938

详细分析过程也可以参考BUG。当然如果有依赖这个值做的监控，可能需要稍微注意一下。

其次。。。其次，，就祝大家新年快乐吧！