MySQL 26.10 把 REST Service 塞进 server：省掉一个 Router 进程后需要权衡的代价
MySQL 26.10 Innovation（2026-10-21 发布，同期还有 9.7.4 LTS 和 8.4.13 LTS）里，对我影响最大的一条不是版本号，而是 REST Service 变成了 MySQL Server 的一个 component。以前想对外暴露 HTTPS 端点，需要单独部署一个 MySQL Router 进程；现在应用可以直接连接 MySQL Server 上的 HTTPS 端点。
少一个进程，也少了一层故障隔离
最直观的变化是部署拓扑少了一个需要单独安装、单独升级、单独监控的进程。随之而来的是：REST 服务随 MySQL Server 一起升级，版本不会出现 server 已经升级、Router 还停留在旧版本的不一致；它也少了 Router 与 server 之间那一跳连接，连接池和线程模型都合并到 server 内部。
代价出现在故障隔离上。Router 独立部署时，REST 层崩溃不会影响数据库本体；现在两者在同一个进程内，REST 侧的配置错误、线程耗尽、大请求打满内存，都会直接落在数据库实例上，故障范围与 server 完全重合。worker 线程数、连接上限、请求和响应大小这几项配置，因此从“Router 机器的容量规划”变成“数据库实例的容量规划”，需要在分配 server 资源时提前预留。
另一个容易忽略的点：这种变化只解决“单实例对外提供 REST”的场景。如果还需要多实例路由、读写分离、主备切换后的流量重定向，Router 依然要部署。它相当于减少了场景，并不等于 Router 可以彻底下线。
component 能配什么
按官方博客的描述，这个 component 暴露的配置项覆盖：HTTPS 端口、TLS 证书与私钥、worker 线程数、连接上限、请求与响应大小；另有一组 SQL 函数用于启动、停止、重启服务，一组状态变量报告运行时状态。
具体的变量名，我没有在手上的资料里逐条核对过，这类新增 component 的变量命名在 Innovation 版本里也可能调整，配置前建议直接以官方手册里 REST component 那一节为准。流程上可执行的检查方式是：升级到 26.10.0 之后，先用 SHOW VARIABLES LIKE '%rest%' 看实例实际暴露了哪些项，再对照手册确认默认值和取值范围，避免按博客里模糊的类别名猜变量。
TLS 这部分要有心理准备：证书和私钥现在由 server 进程读取，文件权限、SELinux 上下文、证书轮换后的重启动作，都要按数据库服务的方式管理，不能再沿用 Router 那套。
四段版本号会先让监控脚本出错
26.10 引入 update 组件，完整发布标识变成 MAJOR.MINOR.PATCH.UPDATE，用来区分同一 patch line 上分批交付的更新。
兼容性上做了取舍：VERSION() 和 @@version 仍然是三段格式，现有依赖数字比较的标识符含义不变。要拿完整版本，得用新函数 VERSION_WITH_UPDATE()、只读全局变量 version_with_update，或 mysqld --version-with-update。
真正的风险在自动化脚本。监控采集、CMDB 上报、升级流水线里那些用正则匹配三段版本号的逻辑，在默认情况下不会立即出错；但一旦需要判断“这个实例装的是哪一批更新”，三段版本号就区分不出来，只能靠新接口。更麻烦的是有人把三段版本当作唯一标识做幂等判断，同一 patch line 的两次 update 会被当成同一个版本，升级动作被静默跳过。
mysql_upgrade_history 文件记录了精确的 update 历史，排查“这台机器到底是什么版本、怎么升上来的”时，它比 VERSION() 可靠。
顺带两件
Health Monitor 进入 Community Edition：通过 Performance Schema 可以查到磁盘、内存、CPU 和 MySQL 进程信息，还有磁盘预测样本与预测摘要，配套 error log 消息和诊断报告。以前这类容量数据要靠外部采集，现在能用 SQL 直接查历史和预测。
Connector/C++ 移除了 mysql-connector-c++-compat RPM。这个包是为 9.0 之前的 ABI 提供兼容库的，依赖旧 ABI 的程序升级后会直接起不来，要么装回旧包，要么针对受支持的 ABI 重新编译。常规 Connector/C++ API 本身没变。
上线前建议执行的验证清单
- 在测试实例执行
SELECT VERSION(), VERSION_WITH_UPDATE(), @@version, @@version_with_update;，确认前三段与四段格式的差异符合预期。 - 全线搜索监控和流水线脚本里的版本号正则，把只匹配
x.y.z的部分改成兼容四段，别等 update 发布后才发现漏报。 - 升级后检查
mysql_upgrade_history是否写入了本次 update 记录。 SHOW VARIABLES LIKE '%rest%'对照手册确认 REST component 的端口、TLS、worker、连接上限、请求响应大小等变量的实际名称与默认值。- 演练 server 重启与崩溃：确认 REST 端点随进程一起不可用，评估该故障域能否接受。
- 仍需读写分离或多实例路由的服务，保留 Router 部署，不要在这次升级里顺手裁掉。
- 运行
rpm -q mysql-connector-c++-compat，有输出的机器要安排重编。 - 升级前跑 MySQL Shell Upgrade Checker，并在测试环境验证行为与性能；新功能用 26.10.0，9.7 LTS 用 9.7.4，8.4 LTS 用 8.4.13。