最近有点头疼MGR （MYSQL 5.7.23，三台+proxysql） 的某个库出了点问题，整体散架了，经过查询了错误日志后，发现一个问题。
发现故障的时候，三台中的一台是可以登录的，经过查询时没有问题，至少显示上是没有问题的。
但实际上另外两台，已经连登录都无法登录了，理解查看错误日志，在错误日志中，并未发现有什么报错的信息
既然没有什么太有用的信息，则只能根据这个信息来看看能查到点什么。
[Note] Multi-threaded slave statistics for channel 'group_replication_applier': seconds elapsed = 76446; events assigned = 3953665; worker queues filled over overrun level = 0; waited due a Worker queue full = 0; waited due the total size = 0; waited at clock conflicts = 44549846300 waited (count) when Workers occupied = 0 waited when Workers occupied = 0
Worker queues filled over overrun level
MTS倾向于在所有并行worker之间加载平衡事件，slave_parallel_workers变量决定worker的数量。这个统计数据显示了工人们所承受的饱和程度。如果并行工作队列接近满，则此计数器将递增，并延迟工作复制事件，以避免达到工作队列限制
Waited due to a Worker queue full
当协调线程必须等待(因为工作队列已满)时，此统计值将递增
Waited due to the total size
此统计数据显示了协调器线程由于达到工作队列中可用内存的极限以容纳未应用的事件而休眠的次数。如果这个统计量在MySQL错误日志中不断增加，那么应该将slave_pending_jobs_size_max变量调整为更大的值，以避免协调线程等待时间
Waited at clock conflicts
在事务之间可能存在依赖关系的情况下，此统计信息显示与逻辑时间戳冲突检测和解决对应的等待时间
Waited (count) when used occupied
一个计数器，显示协调器看到worker被“足够”的任务填满的次数。
Waited when workers occupied
统计数据用于计算空闲WORKER的协调线程等待时间，并且仅适用于提交时钟调度程序
下面是错误信息
原文作者：；如有侵权，请联系管理员删除。
最新文章
- 没有谁是垮掉的一代--记 第四届 OceanBase 数据库大赛
- MongoDB 大俗大雅，高端知识讲“庸俗” --3 奇葩数据更新方法
- MongoDB 学习建模与设计思路--统计数据更新案例
- 在被厂商围剿的DBA 求生之路 --我是老油条
- MongoDB 大俗大雅，高端的知识讲“通俗” -- 2 嵌套和引用
- MongoDB 大俗大雅，高端的知识讲“低俗” -- 1 什么叫多模
- OceanBase4.0 跟我学--分布式到底可靠不可靠，到底丢不丢数--终于学完了
- POLARDB 添加字段 “卡” 住---这锅Polar不背
- PostgreSQL 运维的难与“难” --上海PG大会主题记录
- PostgreSQL 变成"户外人士",后的自救的方法
