100 条命令系列文章专栏
Group Replication 是 MySQL 的组复制方案：成员通过组通信维持同一份成员视图，事务进入组后还要经过认证，再在成员上应用。单主模式下只有一个 PRIMARY 承接写入。值班时看到三台机器都能连，并不能直接说集群健康；成员是否 `ONLINE`、当前主节点是谁、认证队列与远端应用队列是否积压，都要分开看。
Group Replication 是 MySQL 的组复制方案：成员通过组通信维持同一份成员视图，事务进入组后还要经过认证，再在成员上应用。单主模式下只有一个 PRIMARY 承接写入。值班时看到三台机器都能连，并不能直接说集群健康；成员是否 ONLINE、当前主节点是谁、认证队列与远端应用队列是否积压，都要分开看。
这篇把成员状态、事务认证、流控和恢复通道的检查放在一起。遇到副本落后或主节点变化，先用组视图对齐各节点观察结果，再查队列和错误。建议收藏，切换窗口也方便逐项核对。
示例采用 Linux、MySQL 8.4 LTS、三节点单主模式。SQL 默认在任意在线成员执行，需要在特定成员执行的会逐条注明。实例名和地址按现场替换；修改成员状态的命令放在诊断之后。
MySQL Group Replication 单主模式成员视图、认证与远端应用示意
图中组通信、事务认证和各成员应用是不同步骤。PRIMARY 的业务写入不等于其他成员此刻已经应用完相同事务。
MEMBER_ID 用的就是成员 UUID。计划重建或重新加入成员时，先记录本节点身份；不要把主机名相同当成 UUID 相同。
正常三节点单主组应有一个 PRIMARY，其余成员为 SECONDARY 且 ONLINE。RECOVERING 还在补数据，UNREACHABLE 是本节点怀疑联系不上它；网络分区时，要在其他在线成员也取一次快照，不能只凭一台节点的视图宣称组已经完整。
无结果、多个结果或主成员不是 ONLINE，都不能继续按平时的写流量路径判断。先对照第 2 条的全员视图与各节点日志；客户端实际连接落点仍需另查。
RECOVERING 与 ERROR 处理方向不同：前者看恢复通道和待应用事务，后者要查该成员错误日志。视图里没有某节点，也可能是成员已离组；应核对预期三节点清单，而不是把空结果直接当成全组健康。
三节点组的在线数量下降时要关注是否仍有多数成员可通信。这里是本节点看到的成员视图，不是对所有网络分区的仲裁证明；须在其他成员上交叉核对，并检查组通信与业务写入状态。
COUNT_TRANSACTIONS_IN_QUEUE 是待认证事务，不是已经认证后待重放的队列。组成员变更时 VIEW_ID 会变化；跨节点比较统计前先确认它们看到的是同一个视图，并留意远端成员统计有刷新间隔。
某个成员的远端应用队列持续增长，说明它收到组事务后应用跟不上。和第 6 条的认证队列拆开看，才知道慢在认证前还是应用阶段；REMOTE_APPLIED 是累计计数，要看两次采样的增量。
冲突数与本地回滚数都要看增量。单主模式下频繁出现认证冲突或回滚，要核对是否发生了成员角色变化、应用重试或异常写入；仅凭一次累计数不能定性为正在冲突。
这列是组统计中的“所有成员已提交”GTID 集，按固定间隔更新，并非每次业务提交后立即同步刷新。切换前可用它作交叉依据，但还要核对各成员本地执行的 GTID 与当前组视图，不能把一次相同结果当成最终一致性验收。
SERVICE_STATE=ON 表示 applier 线程存在并处于活跃或空闲状态，不说明队列为零。COUNT_TRANSACTIONS_RETRIES 是累计重试次数，持续上升时再下探 worker 错误与锁等待。组通道由 Group Replication 管理，不要按普通副本随意 START REPLICA。
group_replication_recovery 是新成员补齐事务用的通道，和常规组事务的 group_replication_applier 不同。连接错误要去该成员的错误日志找上下文；通道没有当前错误，也要核对恢复是否仍在推进，不能只靠 SERVICE_STATE=ON 判断已追平。
恢复通道接收日志正常但成员长时间不进 ONLINE 时，再检查应用端是否停止或反复重试。第 11 条是接收，第 12 条是应用；两端都在运行，也可能只是待补事务量大，需要结合组成员状态和执行 GTID 的变化判断。
阈值单位是事务数，分别对应第 6 条的待认证队列和第 7 条的待应用队列。DISABLED 不会因队列增长自动限流；QUOTA 才会按流控机制调节。排障先看队列是否连续增长和哪个成员落后，不要把调高阈值当成清理积压。
第 12 条只看通道是否运行；这里能定位具体停下来的 worker。错误号为 0 仅表示没有记录到使 worker 停止的错误，恢复长期不推进时还要检查正在应用的事务和错误日志。不要把恢复通道当作普通异步复制通道重置。
一笔事务长时间停在同一 worker，先对照重试数、锁等待和错误日志。APPLYING_TRANSACTION 为空也可能是 worker 空闲，不能凭空值认定恢复完成；要看成员是否已进入 ONLINE。
最近应用的 GTID 和完成时间持续变化，说明恢复仍在推进。并行 worker 之间顺序不能简单按 WORKER_ID 推断；各 worker 都不变化时再查接收端是否有新事务，以及成员错误日志。
这是正常组事务应用通道，与第 14 条的分布式恢复通道分开查。应用错误可能令成员退出组；先保留错误日志和事务上下文，再决定重建或重新加入，不要为了清掉告警直接重置通道元数据。
驱逐超时是成员产生怀疑之后额外等待的秒数，不包括最初的故障检测时间。自动重入针对被驱逐或失去多数成员等场景，不会修复 applier 错误；尝试期间节点保持超级只读，读请求仍可能读到旧数据。
少数派无法取得仲裁，事务可能被阻塞。这个超时决定少数派等多久才转入错误状态；值为 0 时不会因等待超时自动退出。网络分区处理必须在所有成员上核对组视图，不能在单节点随意强制新成员列表。
本节点显示 ONLINE，不代表其他成员仍承认它在组内；成员被驱逐而通信尚未恢复时，本地视图可能滞后。把这条结果和其他在线成员的组视图交叉比对，再查是否真的有多数成员可通信。
三节点组维护一名成员后，剩下两名需要保持通信。这里仅是当前连接成员看到的组视图；两节点组若再停一名就没有多数派，不能拿旧截图作为停机依据。
维护主节点前先找当前 PRIMARY，确认接替节点都 ONLINE。滚动升级还要看版本：混合版本期间，主节点的可选范围受组复制兼容规则约束，不能只按服务器性能挑人。
单主模式的辅助成员通常是超级只读。若准备停的是主节点，先确认应用写入入口已经有切换方案；查询只说明该成员此刻的设置，不能证明代理已经改路由。
本文按单主模式写，前一项应为 ON，后一项应为 OFF。这两项是组级设置，不能在在线组里把普通 SET GLOBAL 当作切换模式的办法；模式变化另有组复制函数和全组影响。
主节点离组后，版本兼容性先影响候选资格，同版本候选之间再参考权重。member_weight 是自动选举偏好，不是当前主节点的身份；要做明确的计划切换，使用指定成员函数并做业务验收。
维护期间要知道 MySQL 进程重启后是否会自动重入。bootstrap_group 在普通成员上应为 OFF；只在明确的全组重启流程中短时启用，不能因为某成员掉线就自行 bootstrap，避免形成另一个组。
协议版本要兼顾组里最旧的成员版本。此表是组级信息，适合升级前记录；WRITE_CONCURRENCY 不是业务并发连接数，也不能用它推算这次维护一定不会降吞吐。
只在计划维护的这一名成员执行。停后从其他成员确认它已离组、剩余成员仍能写入；若该节点是主节点，会触发新主选举。命令返回不等于客户端连接都已迁移。
目标应显示 OFFLINE；随后在其他成员再查一次组视图。成员离组后，本地视图不再是全组现状的可靠来源，不能用这条替代剩余多数派确认。
停的是主节点时，应出现新的 PRIMARY，辅助节点仍 ONLINE。还要通过业务入口做实际写入检查，并确认被维护节点不再接收写流量；只看到选主完成，不代表客户端连接池已经切过来。
group_seeds 用的是组通信地址，至少要有一台仍 ONLINE 的成员可达。MySQL 通信栈和 XCom 的连接与权限规则不同；种子地址写对了，也要确认目标端口、防火墙与认证。
local_address 是成员间通信地址，不能拿它给业务连接数据库。它必须能被其他成员解析并访问；采用 MySQL 通信栈时还要与服务器监听地址相符。这里把 SQL 端口一起列出来，方便排除把两种地址写混的错误。
group_uuid 应一致，member_uuid 应各不相同。克隆或重建过实例时尤其要查这两个值；把旧配置复制到新机器，不能因此把两个 MySQL 实例变成同一个成员身份。
这是回到现有组，不是重新 bootstrap 全组。命令返回后成员可能先处于 RECOVERING，要等补齐事务并进 ONLINE；若恢复账号或网络有问题，继续查第 11、14 条及错误日志。
RECOVERING 表示还在分布式恢复，ONLINE 才进入组的正常成员视图。查询为空时先列全组成员，核对 UUID；不能因为待回归节点的本地 SQL 能连，就宣布它已重新入组。
队列下降、远端应用数增加，说明正在追赶。COUNT_TRANSACTIONS_REMOTE_APPLIED 是累计值，队列偶尔升高也可能只是组内新事务较多；要看连续几次采样，配合成员状态。
与合适 donor 的事务差超过阈值时，组复制可能使用远程克隆；低于阈值或克隆不可用则走 donor 二进制日志。阈值不等于“已经触发克隆”的证明，具体路径要看成员日志和 clone 状态。不要为了让它立即克隆就把活跃组阈值调得很低。
这两项分别控制连接 donor 的重试次数和没有合适 donor 时的等待间隔。它们不是成员应用事务的速度限制；连续失败应先查恢复通道错误、donor 可用性和网络，不能只把次数调大。
没有结果或不是 ACTIVE 时，不能假设远程克隆可用；组复制仍可能走增量恢复，但前提是合适 donor 保留了所需的二进制日志。Clone 是否真的发生，还要看分布式恢复日志。
增量恢复要能从 donor 取到回归成员缺的事务。列出文件只是第一步：还要对照回归成员的 GTID 缺口和 donor 的 GTID、日志保留情况。缺口已被清理掉时，单纯重试连接不会补回数据。
donor 已执行的 GTID 是判断回归成员缺口的基准。组在继续写入时它会变化，因此要记录取样时间；若几名 donor 的 GTID 差异很大，先查其成员状态和远端应用队列。
本地 GTID 里既可能有组事务，也可能有本地意外写入产生的事务。比较前先核对组 UUID 与成员身份；不能把所有额外 GTID 都简单解释成“备库领先”。
返回空集合表示这份 donor 快照中的 GTID 本地都已有，不等于此刻组里没有新提交。返回非空时，再看 donor 的 gtid_purged 和日志保留；不能凭一个 GTID 范围就猜所需二进制日志文件名。
gtid_purged 记录已执行但不在当前二进制日志中的 GTID。若回归成员缺的事务已落在 donor 的 purged 集里，该 donor 不能靠增量恢复提供这些日志；要找其他保留完整日志的 donor，或评估 Clone。
这张表只保留当前或上一次 Clone，不是历史审计表。source 是实际 donor 地址，Failed 后要读错误号和日志；无行不能据此认定增量恢复正常，继续查恢复通道。
FILE COPY、PAGE_COPY、REDO_COPY 等阶段耗时不同。进度停住时，看磁盘和网络，再查 Clone 错误；DATA 与 ESTIMATE 是阶段读数，不能把一个阶段的百分比直接当成整个成员恢复完成率。
Clone 会携带 donor 的复制坐标，之后回归成员还要继续补齐 Clone 期间产生的新事务。这里的 gtid_executed 是 Clone 时的基线，不是当前组最终 GTID；Completed 也不等于成员已经 ONLINE。
持续有心跳而事务不前进，重点转到应用 worker、GTID 缺口和 donor 日志；CONNECTING 或错误号非零，先查网络、账号和认证。心跳计数可能在重启或重置后清零，要看时间和增量。
这张表是有限大小的内存环形缓冲，旧日志会被覆盖。成员长期卡在 RECOVERING 时，按具体错误号到实例错误日志找完整上下文；不能因表里没有相关行就认为没有报错。
默认的 BEFORE_ON_PRIMARY_FAILOVER 会在新主仍有旧主事务待应用时暂缓新请求。某成员单独改了全局或会话级别，切换后客户端的等待和读到的数据可能与预期不同；核对配置，不要在切换窗口直接全组改成最强级别。
候选成员先要 ONLINE。混合版本升级期间，还需看 MySQL 的最低版本选主限制；这条排序只是方便人工核对，不能把第一个结果机械地当成合法新主。
指定新主函数会等待当前主节点正在运行的事务；给了超时还可能断开没有进入提交阶段的会话。长事务要提前和业务方处理，不能把函数长时间不返回直接归咎于组通信。
MySQL 8.4 的指定换主也会等待正在运行的 DDL。看到 ALTER TABLE 等操作，应先确认能否等它完成；直接断开或强制切换可能影响业务和结构变更。PROCESSLIST 是瞬时视图，必要时多次取样。
函数参数是成员 UUID，不是主机名。目标必须仍为在线辅助成员；查询无结果或本地仍在 RECOVERING，先处理成员状态，不能用旧维护记录里的 UUID 硬试。
第二个参数是当前主节点运行中事务的等待上限，单位秒；设置后新事务也不能再从旧主开始。函数会等事务和 DDL，返回文本要读具体结果。它只改变组内 PRIMARY，客户端路由还得由 Router、代理或应用处理。
预期只有目标成员为 PRIMARY，原主变成 SECONDARY，其余成员仍 ONLINE。换个成员回读是为了确认成员视图已传播；单台节点一瞬间的结果不代表路由已切完。
目标应是组视图里的 PRIMARY 且允许写入。若仍超级只读，先查组成员状态和选主动作，不要手工关掉 super_read_only 来掩盖未完成的切换。
旧主应不再接受写入。offline_mode 可能由现场成员退出动作控制，不能要求它一定为某个固定值；关键是组角色、只读状态与业务入口一致，避免旧连接继续向它发送写请求。
新主若仍在补旧主事务，一致性级别可能让新请求等待。看队列是否继续下降，远端应用数是否前进；ONLINE 和 PRIMARY 两个状态本身不说明 backlog 已清零。
用只读账号就能检查新连接落点，无需为验收额外写业务表。还要检查应用连接池的旧连接和真实写请求是否按预期完成；组内选主成功并不会自动替客户端换连接。
JSON 里每个成员地址对应被本节点怀疑的次数。某节点持续升高时，去查两端组通信日志、网络丢包和端口，而不是仅凭当前 ONLINE 状态说网络没问题；计数是本地视角，须与其他成员比较。
持续增长可能表示成员对提案响应慢或网络有问题。与第 61 条怀疑次数和组通信延迟一起看；单次非零值只是历史累计，不是此刻故障。该类状态值在成员重启或重新入组后会重置。
time_sum 是累计耗时，不能直接拿总时间除以一次采样的提案数。两次采样都没有重置时，用耗时增量除以提案增量，才能看近期共识耗时是否上升；组中没有提案时不要硬算平均值。
这个时间长时间不变，结合业务事务是否真的进入组、队列是否增长判断。空闲组没有新提案时不变化也正常；若业务持续写入而认证队列和时间都停住，才值得转查通信和多数派。
XCom 走成员通信地址与 IP allowlist；MYSQL 栈走服务器监听与成员认证。协议栈配置不一致时，新成员可能连不上种子；当前组仍在线，也不代表下一次重入不会失败。
使用 XCom 时，其他成员要允许这台成员的组通信地址。若现场用 MYSQL 通信栈，此允许列表不参与成员认证；要改查成员账号与 TLS。不能把 SQL 客户端白名单和组通信白名单当成一回事。
force_members 是丢失多数派时人工强制重建组视图的特殊入口，不应作为日常修复手段。若非空，先查此前操作记录和各节点组视图；在网络分区未查清前随意强制成员列表，可能造出另一份不一致的组。
这里读到的是当前节点的视图。网络分区时，不同节点可能给同一成员标出不同状态；把各节点结果放在一起，才能判断是成员真正停机，还是组通信被隔断。UNREACHABLE 只说明当前节点联系不到它，不能据此直接认定它已停机。
三节点组只有一名成员可通信时，原视图已失去多数派，事务提交会停住。这个统计仍需和其他节点的视图、主机状态一起看。计划内逐个退出的成员与突发失联，组视图的变化也不一样。
能连接 SQL 端口，不等于还属于原组。特别是 Router 或业务直连失联节点时，要确认它是否处于超级只读或离线状态。准备人工重建组前，所有将被排除的节点必须确认停机，不能只凭客户端连接失败判断。
unreachable_majority_timeout=0 时，少数派上的提交可能一直等待。事后再修改超时值，不能解除已经发生的多数派丢失；先查故障原因与节点去向，再选恢复路径。
组通信地址和客户端 SQL 地址不一定相同。XCom 网络分区排查要核对这里的地址、端口和允许列表；MYSQL 通信栈还要核对服务器监听和成员认证。人工 force_members 所需的是组通信地址，不能拿业务连接地址代替。
这是“排除成员前”的物理确认，不是组内状态检查。若机器失联，不能因为 systemctl 无法执行就写成“已停机”；需要由主机、网络或存储负责人确认隔离，保留证据。Oracle 官方文档明确提醒：被排除的成员若实际形成另一份多数派，强制新视图会造成人工脑裂。
单主模式分区时，原主可能有其他节点尚未拿到的事务。若打算把原主排除，先比 GTID；它带着新组没有的事务回来时会被拒绝。GTID 只能说明事务集合，仍需结合应用队列与业务写入记录判断。
全组重启选引导节点时，不能只比较 gtid_executed。Group Replication 还可能有已经认证、尚未应用的事务，官方重启步骤要求把这部分一并比较。原主或最后关机的节点，都不一定是事务最完整的节点。
全组停机后的恢复不是单节点重入。比较事务集合期间，先在各节点的配置文件把 group_replication_start_on_boot 设为 OFF，确保 MySQL 启动后不会抢先加入组；任何节点都不能预先把 bootstrap_group=ON 写进配置文件。实际修改配置和启停 MySQL 要按现场维护流程进行。
组复制插件已安装但未运行时，本地成员状态应为 OFFLINE。若仍见 ONLINE 或 RECOVERING，不要开始比较事务集合；先按维护方案停止组复制并确认停止。全组恢复期间还要隔离业务写入，避免 GTID 集合边查边变化。
这是第 74、75 条在全组重启时的联合留存。选引导节点看的是两份事务集合的并集，不是仅看已执行 GTID。若某成员查不到应用通道记录，不能把空结果当作零事务；先查插件、通道状态和日志。
这部分事务已经认证，尚未列入 gtid_executed。比较成员完整事务集合时，要把它和已执行 GTID 一起算进去。若应用通道没有返回记录，先查状态和日志，不能直接把它判成空集合。
只要 only_on_a 与 only_on_b 同时非空，两台成员就不是简单的“谁更新”。这通常提示额外事务、分叉或数据来源异常，需要先查原因。选引导节点应找事务集合覆盖其他所有成员的节点；不能凭 GTID 数量或节点角色排序。
这是全组重启的关键步骤，三句要连续执行并检查每句返回。引导开关只应临时打开一次，绝不能留在 my.cnf 中。若中途失败，先把开关复位，查错误日志、事务集合和当前组视图；不要换台节点再盲目重试。
引导成功后应先看到单成员组，并确认该节点角色和状态。若出现另一名成员，先查它是否自动启动或已加入，暂缓后续节点回归。SQL 返回成功也不能代替组视图核对。
回归成员不能再次引导同名组。bootstrap_group 必须为 OFF；如果 start_on_boot 已打开，先查它是否在比较事务集合期间自行启动过组复制。只有创始成员的组视图确认无误，才让其他成员逐台加入。
这几个值在重启期间被改错，成员可能连不上创始成员，或误进另一组。尤其注意 XCom 组通信端口与 SQL 客户端端口的区别。若创始成员地址变过，先按官方配置步骤修正，再启动回归成员。
先等这台成员进入 ONLINE，再处理下一台。加入过程中可能走分布式恢复或 Clone；START 返回不代表数据已经追平。若成员带有创始组没有的额外事务，不能删 GTID 硬塞回组，先核对分叉和恢复方案。
目标应逐台变为 ONLINE，单主组始终只有一名 PRIMARY。若成员长时间留在 RECOVERING，回头查它的恢复通道和错误日志。这里只证明组视图，业务入口与读写路由仍要另查。
ONLINE 之后仍需看是否追上业务需要的事务点。结果为空说明这两个已执行集合在该方向上无缺口，但不能单凭它证明 Router 路由、写入权限或应用一致性。若有额外事务，还要做反向差集核对。
bootstrap_group 应为 OFF，没有人工重建组视图时 force_members 应为空。运行时读数还要与配置文件核对：bootstrap_group=ON 留在配置文件里，下次重启可能形成另一份同名组。
全组重启期间临时关闭了 start_on_boot，恢复后要按现场原策略重新设置；官方文档允许恢复为 ON。这项只影响下次服务启动，不是本次成员是否已追平的证据。别忘了核对配置文件，否则运行时和下一次启动行为可能不同。
全组视图恢复后，还要从业务所用入口连一次。写入口应落到新主，读入口落到允许服务的在线成员；这条只检查连接落点，不替代业务读写验收。若代理仍指向故障前的主节点，先修正路由，再宣告恢复。
单主组也可能因认证或事务来源问题出现本地回滚。这里的累计数不能直接当错误率；要看同一节点、同一组视图中两次采样的增量，并对照应用收到的具体失败信息。频繁增加时，先查热点行、长事务和客户端重试。
rows_validating 是仍留在冲突检测结构里的行数，不是表的实际行数。若认证队列已降下来但它仍持续攀升，再查认证垃圾回收和事务负载；不要把它误读成业务表膨胀。
下一条内存统计依赖这些仪表。若 enabled=NO，不能把空结果解释为组复制没有内存开销。需要长期观测时，再按现场监控策略启用相应仪表。
这只统计 Group Replication 仪表记录的内存，不是 mysqld 进程的总 RSS。大事务、消息缓存和认证数据都可能推高峰值；如果进程内存上升而这里没有变化，要检查仪表是否开启并结合操作系统读数。
总量高只是现象。这张表能进一步区分认证结构、事务传输和消息缓存的开销。若相应仪表没启用，排序结果会缺项；先确认第 93 条，再结合当时的事务队列和网络负载判断。
耗时累计值的单位是微秒。看单次平均耗时要用同一节点两次采样的增量相除；只有总耗时涨了、而执行次数也涨了，并不能说明回收变慢。与第 92 条认证结构的行数一起看更有意义。
往返耗时统计同样以微秒累计。某节点的平均耗时突然升高，结合成员失联怀疑和网络读数，才能判断是通信慢还是业务事务大。不同节点重启或重新入组后计数可能重置，不能直接比较绝对值。
同一时间窗的消息数、字节数和往返耗时放在一起看。消息变大而往返时间同步升高，先查大事务和网络带宽；消息大小没变而耗时飙升，再查组通信、主机调度和成员状态。累计计数并不等于瞬时吞吐。
这些计数说明二级成员上的事务因为 AFTER 或 BEFORE_AND_AFTER 一致性保证而等待。事务延迟不一定是认证冲突：先核对第 50 条当前级别，再比较两次采样的等待次数与总耗时。如果级别不同，不能把这组读数直接当成整个组的事务延迟。
这里返回的是当前组协议支持的最低 MySQL 版本，不一定等于本机版本。混合版本升级后，要确认协议是否仍停留在旧级别；消息分片等能力取决于组协议，不只取决于新节点安装的版本。未加入组时函数可能返回错误字符串，不能把它当作正常协议版本。
组复制故障先看每台机器自己的成员视图，别只在一台上看到 ONLINE 就以为全组一致。写入卡住，沿认证、组通信和远端应用往下查；遇到全组停机，先比较已执行和已认证的事务，再决定由谁引导。恢复完成还得从业务入口确认主节点，避免组里恢复了，连接仍落在旧地址上。
这类场景命令会继续整理到 ORA100 · DBA100：
微信里搜索小程序 「三笠的百令册」，值班时可以直接按场景查。
1SELECT @@version AS mysql_version,2 @@server_uuid AS member_uuid,3 @@hostname AS member_host;1SELECT member_id, member_host, member_port,2 member_state, member_role, member_version,3 member_communication_stack4FROM performance_schema.replication_group_members5ORDER BY member_host, member_port;1SELECT member_id, member_host, member_port,2 member_state, member_version3FROM performance_schema.replication_group_members4WHERE member_role = 'PRIMARY';1SELECT member_id, member_host, member_port,2 member_state, member_role3FROM performance_schema.replication_group_members4WHERE member_state <> 'ONLINE';1SELECT COUNT(*) AS visible_members,2 SUM(member_state = 'ONLINE') AS online_members,3 SUM(member_role = 'PRIMARY' AND member_state = 'ONLINE')4 AS online_primaries5FROM performance_schema.replication_group_members;1SELECT member_id, view_id,2 count_transactions_in_queue,3 count_transactions_checked4FROM performance_schema.replication_group_member_stats5ORDER BY member_id;1SELECT member_id,2 count_transactions_remote_in_applier_queue,3 count_transactions_remote_applied4FROM performance_schema.replication_group_member_stats5ORDER BY count_transactions_remote_in_applier_queue DESC;1SELECT member_id,2 count_transactions_checked,3 count_conflicts_detected,4 count_transactions_local_rollback5FROM performance_schema.replication_group_member_stats6ORDER BY member_id;1SELECT member_id, view_id,2 transactions_committed_all_members3FROM performance_schema.replication_group_member_stats4ORDER BY member_id;1-- 在目标成员执行，尤其是应用队列增长的成员2SELECT channel_name, service_state,3 count_transactions_retries4FROM performance_schema.replication_applier_status5WHERE channel_name = 'group_replication_applier';1-- 在 RECOVERING 成员执行2SELECT channel_name, service_state, source_uuid,3 received_transaction_set, last_error_number,4 last_error_message, last_error_timestamp5FROM performance_schema.replication_connection_status6WHERE channel_name = 'group_replication_recovery';1-- 在 RECOVERING 成员执行2SELECT channel_name, service_state,3 count_transactions_retries4FROM performance_schema.replication_applier_status5WHERE channel_name = 'group_replication_recovery';1-- 各成员分别执行；参数可因成员而异2SELECT @@GLOBAL.group_replication_flow_control_mode3 AS flow_control_mode,4 @@GLOBAL.group_replication_flow_control_certifier_threshold5 AS certifier_threshold,6 @@GLOBAL.group_replication_flow_control_applier_threshold7 AS applier_threshold,8 @@GLOBAL.group_replication_flow_control_period9 AS flow_control_period_seconds;1-- 在 RECOVERING 成员执行2SELECT worker_id, service_state, last_error_number,3 last_error_message, last_error_timestamp4FROM performance_schema.replication_applier_status_by_worker5WHERE channel_name = 'group_replication_recovery'6 AND last_error_number <> 0;1-- 在 RECOVERING 成员执行2SELECT worker_id, service_state,3 applying_transaction,4 applying_transaction_start_apply_timestamp,5 applying_transaction_retries_count6FROM performance_schema.replication_applier_status_by_worker7WHERE channel_name = 'group_replication_recovery';1-- 在 RECOVERING 成员执行；隔一段时间采两次2SELECT worker_id, last_applied_transaction,3 last_applied_transaction_end_apply_timestamp4FROM performance_schema.replication_applier_status_by_worker5WHERE channel_name = 'group_replication_recovery'6ORDER BY worker_id;1-- 在应用队列增长或成员进入 ERROR 的节点执行2SELECT worker_id, service_state, last_error_number,3 last_error_message, last_error_timestamp4FROM performance_schema.replication_applier_status_by_worker5WHERE channel_name = 'group_replication_applier'6 AND last_error_number <> 0;1-- 每个成员分别执行，比较配置是否一致2SELECT @@GLOBAL.group_replication_member_expel_timeout3 AS expel_timeout_seconds,4 @@GLOBAL.group_replication_autorejoin_tries5 AS autorejoin_tries,6 @@GLOBAL.group_replication_exit_state_action7 AS exit_state_action;1-- 每个成员分别执行；用于理解网络分区时本节点的行为2SELECT @@GLOBAL.group_replication_unreachable_majority_timeout3 AS unreachable_majority_timeout_seconds,4 @@GLOBAL.group_replication_exit_state_action5 AS exit_state_action;1-- 在怀疑被驱逐或自动重入的成员执行2SELECT member_id, member_host, member_state,3 member_role, member_version4FROM performance_schema.replication_group_members5WHERE member_id = @@GLOBAL.server_uuid;1-- 从至少两名成员执行并对照结果2SELECT member_state, COUNT(*) AS members3FROM performance_schema.replication_group_members4GROUP BY member_state;1SELECT member_id, member_host, member_port,2 member_state, member_role, member_version3FROM performance_schema.replication_group_members4ORDER BY member_role, member_host;1-- 直接连接要维护的成员，勿经代理自动路由2SELECT @@GLOBAL.server_uuid AS member_id,3 @@GLOBAL.read_only AS read_only,4 @@GLOBAL.super_read_only AS super_read_only;1-- 在每名在线成员执行2SELECT @@GLOBAL.group_replication_single_primary_mode3 AS single_primary_mode,4 @@GLOBAL.group_replication_enforce_update_everywhere_checks5 AS update_everywhere_checks;1-- 每个候选成员分别执行，并记录 server_uuid2SELECT @@GLOBAL.server_uuid AS member_id,3 @@GLOBAL.group_replication_member_weight AS member_weight,4 @@GLOBAL.version AS mysql_version;1-- 在准备停机或升级的成员执行2SELECT @@GLOBAL.group_replication_start_on_boot3 AS start_on_boot,4 @@GLOBAL.group_replication_bootstrap_group5 AS bootstrap_group;1SELECT protocol_version, write_concurrency2FROM performance_schema.replication_group_communication_information;1-- 已核对剩余成员仍有多数派，应用已摘除此节点2STOP GROUP_REPLICATION;1-- 在停组复制的成员执行2SELECT @@GLOBAL.server_uuid AS member_id,3 member_state4FROM performance_schema.replication_group_members5WHERE member_id = @@GLOBAL.server_uuid;1-- 从剩余在线成员执行2SELECT member_id, member_host, member_state, member_role3FROM performance_schema.replication_group_members4ORDER BY member_role, member_host;1-- 在待回归成员执行；不是 SQL 客户端的主机与端口2SELECT @@GLOBAL.group_replication_group_seeds AS group_seeds,3 @@GLOBAL.group_replication_communication_stack AS communication_stack;1-- 在待回归成员执行2SELECT @@GLOBAL.group_replication_local_address AS local_address,3 @@GLOBAL.bind_address AS sql_bind_address,4 @@GLOBAL.port AS sql_port;1-- 待回归成员、剩余在线成员分别执行并比较2SELECT @@GLOBAL.group_replication_group_name AS group_uuid,3 @@GLOBAL.server_uuid AS member_uuid;1-- 只在待回归成员执行；确认 bootstrap_group=OFF、组里仍有在线成员2START GROUP_REPLICATION;1-- 在未离组的在线成员执行；member_id 换成第 33 条记录的 UUID2SELECT member_id, member_host, member_state,3 member_role, member_version4FROM performance_schema.replication_group_members5WHERE member_id = '2c6f5c9e-1111-2222-3333-444444444444';1-- 在刚回归的成员执行，隔一段时间再取样2SELECT member_id, count_transactions_in_queue,3 count_transactions_remote_in_applier_queue,4 count_transactions_remote_applied5FROM performance_schema.replication_group_member_stats6WHERE member_id = @@GLOBAL.server_uuid;1-- 待回归成员执行；阈值是事务数2SELECT @@GLOBAL.group_replication_clone_threshold AS clone_threshold,3 @@GLOBAL.gtid_executed AS local_gtids;1-- 待回归成员执行2SELECT @@GLOBAL.group_replication_recovery_retry_count AS retry_count,3 @@GLOBAL.group_replication_recovery_reconnect_interval AS retry_interval_seconds;1-- 待回归成员执行；只显示已安装的插件2SELECT plugin_name, plugin_status3FROM information_schema.plugins4WHERE plugin_name = 'clone';1-- 在候选 ONLINE donor 成员执行2SHOW BINARY LOGS;1-- 在候选 ONLINE donor 执行；与回归成员同一时段取样2SELECT @@GLOBAL.server_uuid AS donor_uuid,3 @@GLOBAL.gtid_executed AS donor_gtids;1-- 在回归成员执行；与第 41 条取样时间尽量接近2SELECT @@GLOBAL.server_uuid AS joining_uuid,3 @@GLOBAL.gtid_executed AS joining_gtids;1-- 在回归成员执行；donor 集合换成第 41 条的实际输出2SET @donor_gtids = 'aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee:1-100';3SELECT GTID_SUBTRACT(@donor_gtids, @@GLOBAL.gtid_executed)4 AS missing_gtids;1-- 在候选 ONLINE donor 执行；与第 43 条 missing_gtids 交叉比较2SELECT @@GLOBAL.gtid_purged AS purged_gtids,3 @@GLOBAL.gtid_executed AS executed_gtids;1-- 在回归成员执行；Clone 插件未启用时表可能不存在2SELECT id, state, source, begin_time, end_time,3 error_no, error_message4FROM performance_schema.clone_status;1-- 在回归成员执行；按阶段顺序看当前或上一次 Clone2SELECT stage, state, begin_time, end_time,3 estimate, data, data_speed, network_speed4FROM performance_schema.clone_progress5ORDER BY id, begin_time;1-- 在回归成员执行；仅在 Clone 有记录时有意义2SELECT state, source, binlog_file,3 binlog_position, gtid_executed4FROM performance_schema.clone_status;1-- 在 RECOVERING 成员执行2SELECT service_state, source_uuid,3 last_heartbeat_timestamp, count_received_heartbeats,4 last_error_number, last_error_message5FROM performance_schema.replication_connection_status6WHERE channel_name = 'group_replication_recovery';1-- 在回归成员执行；表为空时到实例实际错误日志找2SELECT logged, prio, error_code, subsystem,3 LEFT(data, 300) AS message4FROM performance_schema.error_log5WHERE data LIKE '%Group Replication%'6 OR data LIKE '%Clone%'7ORDER BY logged DESC8LIMIT 30;1-- 每名 ONLINE 成员分别执行2SELECT @@GLOBAL.server_uuid AS member_id,3 @@GLOBAL.group_replication_consistency AS global_consistency,4 @@SESSION.group_replication_consistency AS session_consistency;1-- 在当前 ONLINE 成员执行2SELECT member_id, member_host, member_port,3 member_version, member_state, member_role4FROM performance_schema.replication_group_members5WHERE member_state = 'ONLINE'6ORDER BY member_version, member_host;1-- 直连当前 PRIMARY 执行；包括可能长时间不提交的事务2SELECT trx_mysql_thread_id, trx_started,3 trx_state, LEFT(trx_query, 160) AS sql_text4FROM information_schema.innodb_trx5ORDER BY trx_started;1-- 直连当前 PRIMARY 执行；按实际 INFO 列核对 DDL2SHOW FULL PROCESSLIST;1-- 直连候选 SECONDARY 执行；不能经 Router 自动切到别的成员2SELECT @@GLOBAL.server_uuid AS target_uuid,3 @@GLOBAL.version AS mysql_version,4 member_state, member_role5FROM performance_schema.replication_group_members6WHERE member_id = @@GLOBAL.server_uuid;1-- 任一 ONLINE 成员执行；业务已准备换主，目标 UUID 为第 54 条2SELECT group_replication_set_as_primary(3 '2c6f5c9e-1111-2222-3333-444444444444', 300) AS switch_result;1-- 不用执行第 55 条的同一条连接回读2SELECT member_id, member_host, member_state, member_role3FROM performance_schema.replication_group_members4ORDER BY member_role, member_host;1-- 直连目标成员，不经 Router2SELECT @@GLOBAL.server_uuid AS member_id,3 @@GLOBAL.read_only AS read_only,4 @@GLOBAL.super_read_only AS super_read_only;1-- 直连旧 PRIMARY 执行2SELECT @@GLOBAL.server_uuid AS member_id,3 @@GLOBAL.super_read_only AS super_read_only,4 @@GLOBAL.offline_mode AS offline_mode;1-- 在新 PRIMARY 执行，间隔数秒再取一次2SELECT member_id, count_transactions_in_queue,3 count_transactions_remote_in_applier_queue,4 count_transactions_remote_applied5FROM performance_schema.replication_group_member_stats6WHERE member_id = @@GLOBAL.server_uuid;1# 在应用主机执行；地址是 Router/代理的写端口，不是成员组通信端口2mysql --host=db-writer.internal --port=6446 --user=app_readonly \3 --execute="SELECT @@server_uuid AS connected_member, @@super_read_only AS super_read_only"1-- 各成员分别执行；JSON 是该成员本地观察2SELECT member_failure_suspicions_count3FROM performance_schema.replication_group_communication_information;1-- 在每个 ONLINE 成员执行，比较两次采样2SHOW GLOBAL STATUS LIKE 'Gr_extended_consensus_count';1-- 同一成员连续取样；两项都取增量后再相除2SHOW GLOBAL STATUS WHERE Variable_name IN3 ('Gr_all_consensus_proposals_count', 'Gr_all_consensus_time_sum');1-- 在怀疑组停滞的成员执行2SHOW GLOBAL STATUS LIKE 'Gr_last_consensus_end_timestamp';1-- 各成员分别执行；升级或重建后尤其要核对2SELECT @@GLOBAL.server_uuid AS member_id,3 @@GLOBAL.group_replication_communication_stack AS stack,4 @@GLOBAL.group_replication_local_address AS local_address;1-- 仅用于 XCOM 通信栈；各成员分别执行2SELECT @@GLOBAL.group_replication_ip_allowlist AS ip_allowlist,3 @@GLOBAL.group_replication_local_address AS local_address;1-- 各成员分别执行；这里只读取，不修改组成员列表2SELECT @@GLOBAL.server_uuid AS member_id,3 @@GLOBAL.group_replication_force_members AS force_members;1-- 每个仍可登录的成员分别执行，记录查询节点和时间2SELECT @@GLOBAL.server_uuid AS local_member,3 m.member_id, m.member_host, m.member_state, m.member_role4FROM performance_schema.replication_group_members AS m5ORDER BY m.member_host;1-- 在每个存活成员分别执行；不要只查一台机器2SELECT @@GLOBAL.server_uuid AS local_member,3 COUNT(*) AS members_in_view,4 SUM(member_state = 'ONLINE') AS online_members,5 SUM(member_state = 'UNREACHABLE') AS unreachable_members6FROM performance_schema.replication_group_members;1-- 在每个失联节点的 SQL 端口直连；连接失败另查主机、端口与进程2SELECT @@GLOBAL.server_uuid AS member_id,3 @@GLOBAL.super_read_only AS super_read_only,4 @@GLOBAL.offline_mode AS offline_mode,5 @@GLOBAL.group_replication_start_on_boot AS start_on_boot;1-- 各成员分别执行；只读配置，不临时调整2SELECT @@GLOBAL.server_uuid AS member_id,3 @@GLOBAL.group_replication_unreachable_majority_timeout AS timeout_seconds,4 @@GLOBAL.group_replication_autorejoin_tries AS autorejoin_tries,5 @@GLOBAL.group_replication_exit_state_action AS exit_action;1-- 对每个预计保留或排除的节点分别执行并留存结果2SELECT @@GLOBAL.server_uuid AS member_id,3 @@GLOBAL.group_replication_local_address AS local_address,4 @@GLOBAL.group_replication_communication_stack AS stack;1# 每个计划从新组排除的节点上执行；按现场服务名替换 mysqld2systemctl status mysqld --no-pager1-- 每个可登录成员直连执行，结果按 server_uuid 留存2SELECT @@GLOBAL.server_uuid AS member_id,3 @@GLOBAL.gtid_executed AS executed_gtids;1-- 每个可登录成员分别执行；与上一条 GTID 一起保存2SELECT @@GLOBAL.server_uuid AS member_id,3 received_transaction_set4FROM performance_schema.replication_connection_status5WHERE channel_name = 'group_replication_applier';1-- 全组已停止、且各成员仍可连接时，逐台核对；这里不直接修改配置文件2SELECT @@GLOBAL.server_uuid AS member_id,3 @@GLOBAL.group_replication_start_on_boot AS start_on_boot,4 @@GLOBAL.group_replication_bootstrap_group AS bootstrap_group;1-- 全组重启比较事务集合前，在每台 MySQL 实例直连执行2SELECT @@GLOBAL.server_uuid AS local_member,3 member_id, member_state4FROM performance_schema.replication_group_members;1-- 全组停止后，每台成员直连执行；保留 server_uuid 和完整结果2SELECT @@GLOBAL.server_uuid AS member_id,3 @@GLOBAL.gtid_executed AS executed_gtids,4 c.received_transaction_set AS certified_gtids5FROM performance_schema.replication_connection_status AS c6WHERE c.channel_name = 'group_replication_applier';1-- 在各成员直连执行；与第 78 条原始结果一起留存2SELECT @@GLOBAL.server_uuid AS member_id,3 GTID_SUBTRACT(c.received_transaction_set,4 @@GLOBAL.gtid_executed) AS certified_not_executed5FROM performance_schema.replication_connection_status AS c6WHERE c.channel_name = 'group_replication_applier';1-- 在独立核对会话执行，替换成第 78、79 条合并核对后的完整 GTID 集合2SELECT GTID_SUBTRACT('候选节点A的完整GTID集合',3 '候选节点B的完整GTID集合') AS only_on_a,4 GTID_SUBTRACT('候选节点B的完整GTID集合',5 '候选节点A的完整GTID集合') AS only_on_b;1-- 仅在已确认事务集合最完整的成员执行；执行前确认其他成员未建组2SET GLOBAL group_replication_bootstrap_group = ON;3START GROUP_REPLICATION;4SET GLOBAL group_replication_bootstrap_group = OFF;1-- 在第 81 条的引导成员上执行2SELECT @@GLOBAL.server_uuid AS local_member,3 member_id, member_state, member_role4FROM performance_schema.replication_group_members;1-- 每台待回归成员直连执行，暂不启动组复制2SELECT @@GLOBAL.server_uuid AS member_id,3 @@GLOBAL.group_replication_bootstrap_group AS bootstrap_group,4 @@GLOBAL.group_replication_start_on_boot AS start_on_boot;1-- 在每台待回归成员直连执行；种子地址按现场原组配置核对2SELECT @@GLOBAL.server_uuid AS member_id,3 @@GLOBAL.group_replication_group_name AS group_name,4 @@GLOBAL.group_replication_group_seeds AS group_seeds,5 @@GLOBAL.group_replication_local_address AS local_address;1-- 仅在已通过第 83、84 条核对的回归成员执行；一次只处理一台2START GROUP_REPLICATION;1-- 每启动一台成员后，在创始成员执行2SELECT member_id, member_host, member_state, member_role3FROM performance_schema.replication_group_members4ORDER BY member_host;1-- 在核对会话中替换两个节点实时留存的 gtid_executed2SELECT GTID_SUBTRACT('创始成员当前GTID集合',3 '回归成员当前GTID集合') AS still_missing;1-- 所有成员回归后逐台执行2SELECT @@GLOBAL.server_uuid AS member_id,3 @@GLOBAL.group_replication_bootstrap_group AS bootstrap_group,4 @@GLOBAL.group_replication_force_members AS force_members;1-- 各成员直连执行；配置文件也需同步核对2SELECT @@GLOBAL.server_uuid AS member_id,3 @@GLOBAL.group_replication_start_on_boot AS start_on_boot,4 @@GLOBAL.group_replication_autorejoin_tries AS autorejoin_tries;1-- 使用业务实际的 Router/代理入口连接，执行只读核对2SELECT @@GLOBAL.server_uuid AS connected_member,3 @@GLOBAL.super_read_only AS super_read_only,4 @@GLOBAL.group_replication_single_primary_mode AS single_primary_mode;1-- 在承接写入的 PRIMARY 上执行；留存两次采样计算增量2SELECT member_id,3 count_transactions_local_proposed AS proposed,4 count_transactions_local_rollback AS rolled_back5FROM performance_schema.replication_group_member_stats6WHERE member_id = @@GLOBAL.server_uuid;1-- 各成员分别执行，观察数值是否在持续增长2SELECT member_id,3 count_transactions_rows_validating AS rows_validating,4 count_transactions_checked AS transactions_checked5FROM performance_schema.replication_group_member_stats;1-- 每台成员检查；这里只读，不临时打开仪表2SELECT name, enabled3FROM performance_schema.setup_instruments4WHERE name LIKE 'memory/group_rpl/%'5ORDER BY name;1-- 在每台成员直连执行；仪表未开启时结果可能不完整2SELECT ROUND(SUM(current_number_of_bytes_used) / 1024 / 1024, 2) AS current_mb,3 ROUND(SUM(high_number_of_bytes_used) / 1024 / 1024, 2) AS high_mb4FROM performance_schema.memory_summary_global_by_event_name5WHERE event_name LIKE 'memory/group_rpl/%';1-- 在内存增长的成员执行，按当前占用排序2SELECT event_name,3 ROUND(current_number_of_bytes_used / 1024 / 1024, 2) AS current_mb,4 ROUND(high_number_of_bytes_used / 1024 / 1024, 2) AS high_mb5FROM performance_schema.memory_summary_global_by_event_name6WHERE event_name LIKE 'memory/group_rpl/%'7ORDER BY current_number_of_bytes_used DESC8LIMIT 10;1-- 写入负载正常时在各成员留存两次采样，计算计数及耗时增量2SHOW GLOBAL STATUS WHERE Variable_name IN3('Gr_certification_garbage_collector_count',4 'Gr_certification_garbage_collector_time_sum');1-- 各成员采样两次，再计算同一时间窗的增量2SHOW GLOBAL STATUS WHERE Variable_name IN3('Gr_control_messages_sent_count',4 'Gr_control_messages_sent_roundtrip_time_sum');1-- 在写入节点及慢节点分别留存两次采样2SHOW GLOBAL STATUS WHERE Variable_name IN3('Gr_data_messages_sent_count',4 'Gr_data_messages_sent_bytes_sum',5 'Gr_data_messages_sent_roundtrip_time_sum');1-- 使用 AFTER 或 BEFORE_AND_AFTER 一致性级别时，在相关成员采样2SHOW GLOBAL STATUS WHERE Variable_name IN3('Gr_transactions_consistency_after_sync_count',4 'Gr_transactions_consistency_after_sync_time_sum');1-- 在当前 ONLINE 成员执行；不修改组协议2SELECT @@GLOBAL.version AS server_version,3 group_replication_get_communication_protocol() AS group_protocol;