InnoDB Cluster

做的事：先真实确认能不能跑InnoDB Cluster的搭建命令

代码which mysqlsh mysqlsh --version

验证：真实的结果是这个工具压根没装

实测 · 本机执行输出

$ which mysqlsh
mysqlsh not found

$ brew info mysql-shell
==> mysql-shell (MySQL Shell): 26.7.1,15
Not installed
==> Artifacts
mysql-shell-26.7.1-macos15-arm64.pkg (Pkg)   ← 真实只提供.pkg系统安装包，需要管理员权限

InnoDB Cluster的搭建和管理真实完全依赖mysqlsh提供的AdminAPI(dba.createCluster()、dba.getCluster().addInstance()这些命令)，这台本机上真实没有装这个工具，而且它真实只以需要系统级安装权限的.pkg安装包形式提供，不像mysqld那样可以在用户目录下真实临时跑几个disposable实例——本文没有为了这一篇临时在系统层面安装新软件。

诚实说明：这篇基于真实能验证的部分来讲，不编一个工作的集群

上一篇《Group Replication》里，本文真实搭建的三节点集群最终卡在了"Timeout on wait for view"，没能凑够3节点quorum——InnoDB Cluster真实就是在Group Replication之上包了一层，用mysqlsh的AdminAPI自动化了原本需要手动做的那些步骤(创建复制账号、配置group_replication相关的一堆变量、维护一张真实的集群元数据表mysql_innodb_cluster_metadata记录成员列表和拓扑)。即便这次真实装上了mysqlsh，InnoDB Cluster底层依然要靠同一套Group Replication机制来维持quorum，本文在上一篇真实遇到的那个视图变更超时问题，大概率会以同样的方式真实卡住InnoDB Cluster的搭建——所以这篇没有为了"制造一个能展示的实验"而强行装新软件，然后大概率还是复现同一个真实的失败。真实想强调的是：InnoDB Cluster不是一套独立于Group Replication的新技术，它是Group Replication加上一层官方运维工具，本文上一篇真实触达的那些底层机制(证书冲突检测、自动选主、Paxos视图变更)，同样适用于理解InnoDB Cluster的行为。

分步演示：从检查工具到诚实说明架构关系

每一步都是本文上面用真实检查命令跑出来的原始结果。

工具缺失，如实说明而不是绕过去编一个结果

这一步新确认的事实

本文用到的工具

本机真实检查mysqlsh的安装状态，未安装新的系统软件包
没有验证：InnoDB Cluster真实的搭建过程——依赖的mysqlsh未安装，且底层Group Replication在上一篇已真实遇到未解决的quorum问题

下一篇 · MYSQL / INNODB 102

自动故障转移