MySQL Router 的读写口
MySQL Router 是 InnoDB Cluster 的官方接入中间件：它读取集群元数据后，把 6446 端口上的连接送到当前主库（读写），把 6447 上的连接按策略分发到从库（只读）。应用只改连接串指向 Router，主库切换时不用改配置。默认端口在首次 bootstrap 时写入配置，classic 协议占 6446/6447，X 协议另占 6448/6449。
基本信息
| 服务 | MySQL Router（InnoDB Cluster 接入层） |
|---|---|
| 协议 | TCP（MySQL classic 协议） |
| 默认端口 | 6446 读写 / 6447 只读 |
| X 协议端口 | 6448 读写 / 6449 只读 |
| 暴露面 | 仅应用网段 |
典型使用场景
- 应用连接串改指向 Router，主库故障切换对业务透明
- 报表、备份、离线分析流量走 6447，避免压到主库
- Java/PHP 老应用不愿改配置：只换 host:port 就能跟随主库漂移
- 读多写少业务做读写分离，按端口而非按代码分支
- 灰度验证新从库：先用只读口把部分读流量引上去
路由核对
路由核对
mysql -hrouter01 -P6446 -uapp -p -e 'SELECT @@hostname, @@port' # 应落在主库
mysql -hrouter01 -P6447 -uapp -p -e 'SELECT @@hostname, @@read_only' # 只读口应从库
ss -lntp | grep -E '644[6-9]' # 监听核对
mysqlrouter --bootstrap admin@mgmt01:3306 --user=mysqlrouter # 首次生成配置排障与核对
| 检查项 | 做法 | 异常表现 |
|---|---|---|
| 端口监听 | ss -lntp | grep 644[6-9] | 端口不在：Router 进程未起或被防火墙拦 |
| 落点核对 | SELECT @@hostname | 两个端口落到同一台：策略配置未生效 |
| 元数据缓存 | mysqlrouter 日志与 bootstrap 结果 | 主库已切换但 6446 仍指向旧节点 |
| 连接上限 | Router 日志中的连接拒绝 | 后端健康却报连接过多：瓶颈在中间件 |
6447 只按策略分发读流量，不保证一致性：复制延迟大的从库上做只读查询会读到旧数据，需要强一致的读仍要走 6446。Router 自身不做鉴权，账号权限仍由 MySQL 用户体系裁决。
把 6446 暴露到应用网段之外，等于给数据库开了第二扇没人审计的门：来源限制、账号白名单、审计日志要按数据库入口的标准来做。
中间件也要高可用
Router 不解析 SQL、不缓存结果，但所有应用连接都要先经过它，因此进程、端口与元数据缓存都得按生产组件对待：多实例加 VIP、健康检查、版本与后端 MySQL 保持一致，才能避免出现「后端健康、入口不可用」这类假故障。
配置由 bootstrap 生成，集群拓扑变化后 Router 靠元数据缓存感知；升级前先确认目标版本与后端 MySQL 版本兼容，并保留可回滚的配置与证书，避免升级当天同时失去入口和回退路径。