我要评论innodb cluster 是 mysql 官方推出的高可用解决方案，整合了 mysql server、mysql shell 和 mysql router 等组件，能实现集群的自动故障转移、成员管理与模式切换，极大简化了 mysql 高可用架构的部署与运维。本文基于实际操作场景，整理了 innodb cluster 日常管理中高频使用的命令，涵盖连接、状态查询、成员管理、主从切换等核心操作，助力运维人员高效管控集群。
一、基础准备：连接 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（集群管理用户）、bgika^123（用户密码）和 192.168.184.151（实例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. 查看复制统计信息
通过查询 mysql 系统表 performance_schema.replication_group_member_stats，可监控 mysql 组复制（group replication）中单个成员节点的事务处理状态、冲突情况及队列信息，是排查复制延迟、数据一致性问题的关键视图。以下逐字段解析含义，并结合示例数据说明实际意义：
select * from performance_schema.replication_group_member_stats\g
- 基础标识字段（定位成员与复制通道）
| 字段名 | 含义 | 示例解读 |
|---|---|---|
| channel_name | 复制通道名称，组复制默认使用 group_replication_applier 通道（负责“应用”从其他成员同步过来的事务）。 | 示例值 group_replication_applier 表示该统计数据对应组复制的默认应用通道，无自定义通道配置。 |
| view_id | 组复制的“视图id”，用于标识当前集群的成员拓扑（成员加入/离开会导致视图id更新，格式为 [集群初始化id]:[视图版本号]）。 | 示例值 17648371625947332:7 表示： - 前半段 17648371625947332 是集群初始化时生成的唯一id； - 后半段 7 表示当前是第7版成员视图（集群曾有6次成员变更，如节点加入/退出）。 |
| member_id | 组复制成员节点的唯一id（uuid格式），与 performance_schema.replication_group_members 表的 member_id 一一对应，用于定位具体节点。 | 示例值 532e3c83-d0c0-11f0-8a53-000c29aab861 是当前查询节点的uuid，可通过它关联查询节点的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段事务： 1. 1c783805-d0da-11f0-87d1-000c295cba4b:1-1126：来自节点a的事务1~1126； 2. aec1a885-d0c0-11f0-84c1-000c295cba4b:1-8：来自节点b的事务1~8； 3. cc759266-d0eb-11f0-915e-000c295cba4b:1-55:1000053：来自节点c的事务1~55和1000053（可能是间隙事务或特殊标记）。 这些事务已在所有节点提交，集群数据完全一致。 |
| last_conflict_free_transaction | 最近一个无冲突提交的事务id（若从未发生冲突，则为最新提交的事务）。 | 示例值 cc759266-d0eb-11f0-915e-000c295cba4b:55 表示：最近一次无冲突提交的事务是节点c的第55号事务，后续无新冲突（与 count_conflicts_detected=0 一致）。 |
- 本地与远程事务细分（区分事务来源）
| 字段名 | 含义 | 示例解读 |
|---|---|---|
| count_transactions_remote_in_applier_queue | 从其他成员同步过来、已进入应用队列但尚未应用的事务数量（count_transactions_in_queue 的子集，仅统计远程事务）。 | 示例值 0 表示无远程事务积压，远程事务应用及时。 |
| count_transactions_remote_applied | 从其他成员同步过来并已成功应用的事务总数。 | 示例值 6 表示当前节点累计应用了6个来自其他节点的事务（与 count_transactions_checked=6 一致，说明所有校验通过的事务均为远程事务）。 |
| count_transactions_local_proposed | 当前节点本地发起并提交到集群的事务总数（本地事务需先“提议”给集群，经校验后同步到其他节点）。 | 示例值 1 表示当前节点发起过1个本地事务，且该事务已通过校验并同步到其他节点（因 transactions_committed_all_members 包含本地事务id）。 |
| 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 实例信息（如 router 名称、地址、版本）：
# 在主节点（如 192.168.184.151）的 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 官方文档 深入理解命令背后的原理，确保集群长期稳定运行。
到此这篇关于mysql innodb cluster 常见管理命令的文章就介绍到这了,更多相关mysql innodb cluster 管理命令内容请搜索代码网以前的文章或继续浏览下面的相关文章希望大家以后多多支持代码网！
发表评论