MySQL InnoDB Cluster 是 MySQL 官方推出的高可用集群解决方案，它整合了 Server、Shell 和 Router 三大核心组件，能够自动完成故障转移、成员管理与模式切换等关键运维任务。这里不展开理论，直接整理一份日常运维中最高频使用的命令清单，涵盖实例连接、集群状态检查、成员增删、主从切换等操作，所有命令均可直接复用。
一、基础准备：连接 MySQL 实例
所有集群管理操作都需通过 MySQL Shell 连接到集群中的某个实例。建议优先连接主节点（例如 192.168.184.151），命令格式非常直观：
# 格式：mysqlsh -u[用户名] -p'[密码]' -h[实例IP] -P[端口，默认3306可省略]mysqlsh -umgr_user -p'BgIka^123' -h192.168.184.151
小提示：实际使用中，请将 mgr_user、密码和 IP 替换为您自己的配置。为安全起见，避免在命令行直接明文输入密码，省略 -p 后通过交互方式手动输入更为稳妥。
二、集群状态与结构查询
连接成功后，第一步是定义集群变量，后续所有操作都通过该变量调用方法。先全面了解集群当前的健康状况。
1. 定义集群变量
使用集群名称（示例为 Cluster01）获取集群对象，后续命令直接通过 cluster 变量调用：
# 格式：var cluster = dba.getCluster('[集群名称]')var cluster = dba.getCluster('Cluster01')2. 查看集群整体状态
这是运维中最常用的检查命令。它能够一次性展示集群成员列表、角色（主/从）、健康状态以及复制同步状况：
cluster.status();
执行后，关键信息清晰呈现：
- 集群名称与版本
- 各成员实例的 IP:端口、角色（PRIMARY/SECONDARY）
- 复制同步状态（SYNCED/ERROR）
- 集群整体健康度（OK/WARNING/ERROR）
3. 显示集群详细结构
如需查看每个成员的具体配置——地址、权重、故障转移优先级等信息，可使用此命令：
cluster.describe();
4. 查看集群配置选项
全局配置比如故障转移超时时间、复制延迟阈值、多主模式开关等，均可通过以下命令查看：
cluster.options();
三、集群成员管理：增删实例
扩容或下线故障节点是日常运维的常见需求。操作前建议先使用 cluster.status() 确认目标实例状态，确保操作稳妥。
1. 移除集群成员
移除前需确保目标实例为 SECONDARY 角色（主节点需要先执行切换）。命令支持 IP:端口 或 主机名:端口 两种格式：
# 1. 先确认集群状态，找到目标实例（示例为 192.168.184.153）cluster.status();# 2. 移除实例（二选一，根据环境选择地址格式）cluster.removeInstance('mgr_user@192.168.184.153:3306');# 或使用主机名（需确保主机间能解析）cluster.removeInstance('mgr_user@maria-03:3306');# 3. 移除后再次确认状态，确保实例已从集群中删除cluster.status();
2. 添加集群成员
添加新实例前需满足若干前提：实例已初始化完毕、与集群其他节点网络互通、数据能够同步（或支持自动增量同步）。命令格式与移除类似：
# 二选一，添加 192.168.184.153 实例到集群cluster.addInstance('mgr_user@192.168.184.153:3306');# 或使用主机名cluster.addInstance('mgr_user@maria-03:3306');添加成功后，新实例自动加入复制集群，角色默认为 SECONDARY。
四、主节点管理：手动切换与模式切换
InnoDB Cluster 支持 单主模式（默认，仅一个 PRIMARY）和 多主模式（多个 PRIMARY，可并行写入）。根据不同业务需求切换模式，或手动指定主节点，都是常规操作。
1. 手动切换主节点（单主模式下）
当原主节点需要维护升级时，可手动将某个 SECONDARY 节点提升为主节点：
# 格式：cluster.setPrimaryInstance('管理用户@目标实例地址')cluster.setPrimaryInstance('mgr_user@192.168.184.153:3306');# 或使用主机名cluster.setPrimaryInstance('mgr_user@maria-03:3306');注意：切换过程中集群会短暂停止写入，建议在业务低峰期执行，并确保目标节点数据与原主节点完全同步。
2. 切换为多主模式
多主模式适用于分布式写入场景，前提是业务层面能够妥善处理写入冲突。切换命令在主节点的 MySQL Shell 中执行：
# 在 192.168.184.151（原主节点）的 MySQL Shell 中执行cluster.switchToMultiPrimaryMode();# 查看切换后状态（所有节点角色变为 PRIMARY）cluster.status();
3. 切换回单主模式
如果业务不再需要多主写入，切换回单主模式同样简单，同时需指定新的主节点（示例为 maria-01:3306）：
# 格式：cluster.switchToSinglePrimaryMode('目标主节点地址')cluster.switchToSinglePrimaryMode('maria-01:3306');# 查看切换后状态（仅指定节点为 PRIMARY，其余为 SECONDARY）cluster.status();
五、复制与成员信息深度查询
1. 查看复制统计信息
通过 performance_schema.replication_group_member_stats 系统表，可以监控组复制中单个成员的事务处理状态、冲突情况及队列信息。排查复制延迟和数据一致性问题时，这是关键的视图。结合示例数据理解各字段含义，会更加直观：
SELECT * FROM performance_schema.replication_group_member_statsG
- 基础标识字段（定位成员与复制通道）
| 字段名 | 含义 | 示例解读 |
|---|---|---|
| CHANNEL_NAME | 复制通道名称，组复制默认使用 group_replication_applier 通道（负责“应用”从其他成员同步过来的事务）。 | 示例值 group_replication_applier 表示该统计数据对应组复制的默认应用通道。 |
| VIEW_ID | 组复制的“视图ID”，标识当前集群的成员拓扑。成员加入或离开时，视图ID会更新（格式为 [集群初始化ID]:[视图版本号]）。 | 示例值 17648371625947332:7 表示：前半段是集群初始化时生成的唯一ID；后半段 7 表示当前是第7版成员视图（集群曾有6次成员变更）。 |
| MEMBER_ID | 组复制成员节点的唯一ID（UUID格式），与 performance_schema.replication_group_members 表的 MEMBER_ID 一一对应。 | 示例值 532e3c83-d0c0-11f0-8a53-000c29aab861，可通过它关联查询节点的IP、端口等基础信息。 |
- 事务队列与校验统计（监控事务流转效率）
| 字段名 | 含义 | 示例解读 |
|---|---|---|
| COUNT_TRANSACTIONS_IN_QUEUE | 已从其他成员接收、但尚未开始校验和应用的事务数量（队列长度）。 | 示例值 0 表示无待处理事务，复制延迟风险低。如果该值持续增长，则可能是CPU资源不足或事务执行缓慢。 |
| COUNT_TRANSACTIONS_CHECKED | 节点已接收并完成一致性校验的事务总数（含本地发起和远程同步的事务）。 | 示例值 6 表示累计校验了6个事务，全部通过冲突校验。 |
| COUNT_CONFLICTS_DETECTED | 校验过程中检测到的事务冲突总数（组复制核心指标，冲突会导致事务回滚或重试）。 | 示例值 0 表示无冲突，数据一致性良好。若大于0，需排查原因——是否多节点同时修改同一行数据？主键或唯一索引设计是否合理？ |
| COUNT_TRANSACTIONS_ROWS_VALIDATING | 校验时需要比对行数据的事务数量（仅当事务修改数据时触发，只读事务无需行校验）。 | 示例值 1 表示有1个事务在校验阶段需要比对具体行数据，其余5个可能是只读或无需行校验的操作。 |
- 事务提交与冲突历史（追溯数据一致性状态）
| 字段名 | 含义 | 示例解读 |
|---|---|---|
| TRANSACTIONS_COMMITTED_ALL_MEMBERS | 已在所有成员节点上成功提交的事务ID列表（格式为 [发起节点UUID]:[事务序列号范围]）。 | 示例值包含3段事务：节点A的事务1~1126；节点B的事务1~8；节点C的事务1~55和1000053。这意味着集群数据完全一致。 |
| LAST_CONFLICT_FREE_TRANSACTION | 最近一个无冲突提交的事务ID（若从未发生冲突，则为最新提交的事务）。 | 示例值 cc759266-d0eb-11f0-915e-000c295cba4b:55，与 COUNT_CONFLICTS_DETECTED=0 一致。 |
- 本地与远程事务细分（区分事务来源）
| 字段名 | 含义 | 示例解读 |
|---|---|---|
| COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE | 从其他成员同步过来、已进入应用队列但尚未应用的事务数量（COUNT_TRANSACTIONS_IN_QUEUE 的子集，仅统计远程事务）。 | 示例值 0 表示无远程事务积压。 |
| COUNT_TRANSACTIONS_REMOTE_APPLIED | 从其他成员同步过来并已成功应用的事务总数。 | 示例值 6，与 COUNT_TRANSACTIONS_CHECKED=6 一致，说明所有校验通过的事务均为远程事务。 |
| COUNT_TRANSACTIONS_LOCAL_PROPOSED | 当前节点本地发起并提交到集群的事务总数（本地事务需先“提议”给集群，经校验后同步到其他节点）。 | 示例值 1，该事务已通过校验并同步。 |
| COUNT_TRANSACTIONS_LOCAL_ROLLBACK | 当前节点本地发起但因冲突或错误被回滚的事务总数。 | 示例值 0，本地业务操作正常。 |
从示例数据可以得出以下结论：
- 集群状态健康：无队列积压（0）、无冲突（0）、无本地回滚（0）；
- 数据完全一致：所有校验通过的事务（6个远程+1个本地）均已在全集群提交；
- 复制效率正常：远程事务应用及时，无延迟风险。
2. 查看集群成员列表（全节点通用）
在任意集群实例中执行以下 SQL，所有成员的 ID、地址、角色与状态尽收眼底：
SELECT * FROM performance_schema.replication_group_members;
返回结果包含：
MEMBER_HOST：成员IP/主机名MEMBER_PORT：端口MEMBER_ROLE：角色（PRIMARY/SECONDARY）MEMBER_STATE：状态（ONLINE/OFFLINE/RECOVERING）
3. 列出关联的 MySQL Router 实例
MySQL Router 是集群的流量入口，负责分发请求。想知道当前哪些 Router 连接了集群？在主节点的 MySQL Shell 中执行：
cluster.listRouters();
六、组复制启停（应急操作）
组复制（Group Replication）是 InnoDB Cluster 的核心机制。当某节点需要临时下线修复时，可以手动启停该节点的组复制。
1. 关闭组复制（目标节点执行）
在需要下线的节点（示例为 192.168.184.153）的 MySQL Shell 中执行：
# 关闭当前节点的组复制STOP GROUP_REPLICATION;# 切换到主节点（192.168.184.151）查看集群状态，确认该节点已离线cluster.status();
2. 启动组复制（目标节点执行）
故障修复完成后，在该节点（192.168.184.152）的 MySQL Shell 中重启组复制，节点将自动重新加入集群：
# 启动当前节点的组复制START GROUP_REPLICATION;# 切换到主节点查看状态，确认该节点已重新上线（状态变为 ONLINE）cluster.status();
七、操作注意事项
- 权限与安全：集群管理用户（如
mgr_user）需要具备GROUP_REPLICATION_ADMIN、CLUSTER_ADMIN等权限。生产环境中，避免密码明文输入，推荐使用 MySQL 密钥文件或交互式输入方式。 - 数据备份：在执行成员删除、模式切换等关键操作前，务必对数据进行全量备份，以防误操作导致数据丢失。
- 网络与解析：确保节点间 3306（数据库端口）、33061（组复制端口）等端口互通。如果使用主机名（如
maria-03），需妥善配置/etc/hosts解析。 - 状态校验：所有操作前后，养成习惯执行
cluster.status()检查集群状态，确保没有ERROR或OFFLINE节点后再继续下一步。
结语
以上整理的这些命令，覆盖了 InnoDB Cluster 日常运维的核心场景——从连接查询到成员管理，再到模式切换，基本构成了一套随身工具箱。实际使用时，可结合业务场景（单主或多主、读写分离等）和集群规模灵活调整。当然，若要更深入理解底层原理，建议仔细研读 MySQL 官方文档，这样才能确保集群长期稳定运行。
