COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE值只能通过重启才能释放？

请补充几个信息：
1、 有问题的这个节点机器硬件配置是否比其他节点更差；
2、 该节点是否还承担额外的负载，比如更多读写请求、备份请求、数据分析请求等；
3、 提供该节点上负载相关数据，执行下面几个命令采集：
数据库里执行：SHOW ENGINE INNODB STATUS\G
系统层执行：vmstat -S m 1 100

https://dev.mysql.com/doc/refman ... er-stats-table.html 中提到： TRUNCATE TABLE is not permittedfor the replication_group_member_statstable.  
如果InApplierQueueCount一直在增加，建议检查InnoDB集群中每个节点的系统资源，以确保它们能够处理复制负载。应该检查每个节点的CPU、内存、磁盘I/O和网络带宽利用率，以验证这些资源没有被过度利用。

该节点重启结束后，是否还会再次出现同样问题，及COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE队列越积越大？

从截图信息来看，似乎这个节点的层磁盘I/O能力出问题了，导致有大量事务处于等待被提交状态（事务是PREPARED状态）。

yejr 发表于 2023-12-12 14:43
该节点重启结束后，是否还会再次出现同样问题，及COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE队列越积越大 ...

1、重启该节点结束后没有再出同样的问题，队列也没越积越大
2、磁盘I/O我再去确认下，问题当天检查下来是没有任何问题的

chongzh 发表于 2023-12-12 14:03
https://dev.mysql.com/doc/refman/8.0/en/performance-schema-replication-group-member-stats-table.html ...

1、资源问题已补充到帖子中
2、我再研究下官网的解释

myron_mei 发表于 2023-12-12 22:57
1、资源问题已补充到帖子中
2、我再研究下官网的解释

2、开发侧修改了一部分replace into的逻辑。死锁不再继续增加。
===
可以尝试回滚这个工作，验证是否它引起的。
我认为大概率还是底层磁盘I/O问题导致的。