




不能。MySQL Router 仅是路由代理,不参与数据复制与主从同步,必须先配置好主从复制(如 binlog 复制或 InnoDB Cluster),Router 才能基于元数据路由请求。
不能。MySQL Router 本身不复制数据,也不参与主从同步逻辑。它只是个轻量级的路由代理,负责把客户端请求按策略转发到后端的 MySQL 实例上。主从复制(比如基于 binlog 的异步/半同步复制)必须先手动或通过 MySQL Shell 的 dba.configureReplicationAsPrimary() 等方式配好,Router 才有东西可路由。
Router 启动时会连接后端 MySQL 实例并读取元数据(如 replication_asynchronous_connection_failover 表),如果主从关系没建好、IO_THREAD 或 SQL_THREAD 是 Connecting / Slave_IO_Running: No,Router 会报错退出,并在日志里出现类似:
Failed to fetch metadata from server 'mysql1': ERROR 1146 (42S02): Table 'mysql_innodb_cluster_metadata.routers' doesn't exist
实际使用前务必检查:
SHOW SLAVE STATUS\G 中 Slave_IO_Running 和 Slave_SQL_Running 都是 Yes
SHOW MASTER STATUS 有有效 File 和 Position
telnet master_ip 3306 或 mysql -h master_ip -u repl -p -e "SELECT 1")cluster.status() 返回 "status": "OK"
在 mysqlrouter.conf 的 [routing] 段里,routing_strategy 决定流量怎么分发,直接影响高可用效果:
first-available:只发给列表里第一个 healthy 的实例——适合读写分离场景下的「写节点」路由,但单点故障后不会自动切到新主,需配合外部故障转移工具
next-available:轮询跳过不可用节点,适合只读池(read-only pool),但不感知主从角色变化round-robin-with-fallback:推荐用于读写分离架构;写请求固定走
round-robin:纯负载均衡,不区分角色——绝不能用于写请求,否则会写入从库导致数据分裂示例片段(读写分离):
[routing:read-write] bind_address = 127.0.0.1:6446 destinations = metadata-cache://mycluster/?role=PRIMARY mode = read-write routing_strategy = first-available [routing:read-only] bind_address = 127.0.0.1:6447 destinations = metadata-cache://mycluster/?role=SECONDARY mode = read-only routing_strategy = round-robin-with-fallback
Router 要自动把写请求切到新主,不是靠心跳或自定义脚本,而是依赖两个硬性条件:
metadata_cache 插件(InnoDB Cluster 场景下默认开启),且 Router 配置中 destinations 使用 metadata-cache://... 协议而非静态 IP 列表mysqlrouter --bootstrap 重新拉取集群拓扑(生产环境建议关闭自动 bootstrap,改用 mysqlsh 的 cluster.rescan())GTID_EXECUTED 变化,也不解析 SHOW SLAVE HOSTS——它只信任 mysql_innodb_cluster_metadata 库里的当前视图如果用的是传统主从(非 InnoDB Cluster),Router 无法自动识别主从切换,只能靠外部工具(如 MHA、Orchestrator)修改 Router 配置并重载(mysqlrouter --reload)。
最常被忽略的一点:Router 进程本身没有“选主”能力,它只是个状态消费者。主从切换是否成功、元数据是否及时更新、应用连接是否断开重连——这三个环节漏掉任何一个,高可用就断在中间。