不能随便选节点做mysqldump，因为MGR多主下各节点事务视图不同、存在未传播的本地写入，单独使用--single-transaction仅保证本节点MVCC一致，无法确保全局一致性。
直接备份 MGR（MySQL Group Replication）多主集群时，不能随便挑一个节点执行 mysqldump 或物理备份——因为各节点可能处于不同事务视图，且存在未传播的本地写入。必须选一个能代表全局一致状态的节点，否则备份出来的是“逻辑撕裂”的快照。
为什么不能随便选节点做 mysqldump？
MGR 多主模式下，每个节点可独立接受写入，靠 group replication 协议达成最终一致性，但不是强实时同步。执行 mysqldump 时若没加锁或没等事务收敛，会出现：
-
mysqldump --single-transaction只保证本节点 MVCC 一致性，不感知其他节点尚未传播到本节点的事务 - 备份过程中其他节点仍在写入，而 dump 不包含这些变更，导致备份与集群当前全局状态不匹配
- 若用
FLUSH TABLES WITH READ LOCK，会阻塞整个组的写入（MGR 中该命令会广播并等待所有节点确认），业务中断风险高
如何选出真正可用的一致性备份节点？
核心是找一个已应用完所有已提交组事务、且无本地未同步写入的节点——即满足 MEMBER_STATE = 'ONLINE' 且 COUNT_TRANSACTIONS_IN_QUEUE = 0 和 COUNT_TRANSACTIONS_CHECKED = COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE 的节点。实操步骤如下：
- 连接任意节点，查
SELECT * FROM performance_schema.replication_group_members，筛选MEMBER_STATE = 'ONLINE'的节点 - 对每个 ONLINE 节点，执行
SELECT * FROM performance_schema.replication_group_member_stats WHERE member_id = '<node_id>'; - 确认该节点的
COUNT_TRANSACTIONS_IN_QUEUE = 0且COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE = 0（表示无待应用远程事务） - 再查
SELECT VARIABLE_VALUE FROM performance_schema.global_status WHERE VARIABLE_NAME = 'GROUP_REPLICATION_PRIMARY_MEMBER';，优先选被标记为 primary 的节点（仅限单主模式；多主下此项为空，需跳过）
备份时必须加的关键参数
即使选对了节点，mysqldump 默认行为仍不足以保障 MGR 全局一致性。必须组合以下参数：
- 强制使用
--set-gtid-purged=OFF：MGR 中 GTID 是组级的，mysqldump自动注入的SET @@GLOBAL.GTID_PURGED语句在多主下会出错或误导恢复 - 显式加
--master-data=2并配合SHOW BINLOG EVENTS手动校验起始位点：MGR 不依赖传统 binlog file/pos，但物理恢复时需知道从哪个组事务开始重放 - 避免
--single-transaction单独使用；应搭配START TRANSACTION WITH CONSISTENT SNAPSHOT+SELECT GROUP_REPLICATION_GET_WRITE_CONCURRENCY()确认无并发写入后再 dump - 如需最小停机，改用
xtrabackup：它支持--galera-info类似机制，但对 MGR 需启用group_replication_consistency = BEFORE_ON_COMPLETION后再备份
备份后必须验证的三项指标
dump 文件本身无法反映 MGR 一致性状态，必须立刻验证：
- 检查备份 SQL 中是否含
SET @@SESSION.GTID_NEXT语句——若有，说明 dump 过程中发生了跨节点事务写入，备份无效 - 用
mysqlbinlog --base64-output=decode-rows -v解析最近 binlog，确认GTID_LOG_EVENT中的group_id与SELECT * FROM performance_schema.replication_group_members中的MEMBER_ID匹配 - 在另一台干净环境导入后，执行
SELECT MEMBER_HOST, MEMBER_STATE FROM performance_schema.replication_group_members;，若出现RECOVERING或ERROR，说明备份时漏掉了某个组成员的元数据变更
最易被忽略的一点：MGR 多主下没有“主库”概念，mysqldump 的 --master-data 输出的 CHANGE MASTER TO 语句完全不可用——恢复时必须用 START GROUP_REPLICATION，而不是传统复制启动方式。
