MySQL Router 能不能直接替代主从复制？
不能。
MySQL Router本身不复制数据，也不参与主从同步逻辑。它只是个轻量级的路由代理，负责把客户端请求按策略转发到后端的
MySQL实例上。主从复制（比如基于
binlog的异步/半同步复制）必须先手动或通过
MySQL Shell的
dba.configureReplicationAsPrimary()等方式配好，Router 才有东西可路由。
配置 MySQL 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"） 如果用 InnoDB Cluster 模式，确保
cluster.status()返回
"status": "OK"
Router 配置文件中 routing_strategy 关键区别
在
mysqlrouter.conf的
[routing]段里，
routing_strategy决定流量怎么分发，直接影响高可用效果：
first-available：只发给列表里第一个
healthy的实例——适合读写分离场景下的「写节点」路由，但单点故障后不会自动切到新主，需配合外部故障转移工具
next-available：轮询跳过不可用节点，适合只读池（read-only pool），但不感知主从角色变化
round-robin-with-fallback：推荐用于读写分离架构；写请求固定走主库，读请求轮询所有从库，主库宕机时自动将写请求 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 自动感知主从切换的前提条件
Router 要自动把写请求切到新主，不是靠心跳或自定义脚本，而是依赖两个硬性条件：
后端必须启用metadata_cache插件（InnoDB Cluster 场景下默认开启），且 Router 配置中
destinations使用
metadata-cache://...协议而非静态 IP 列表 主从拓扑变更后，必须触发元数据刷新：要么等 Router 默认 5 秒缓存过期，要么手动执行
mysqlrouter --bootstrap重新拉取集群拓扑（生产环境建议关闭自动 bootstrap，改用
mysqlsh的
cluster.rescan()） 注意：Router 不监听
GTID_EXECUTED变化，也不解析
SHOW SLAVE HOSTS——它只信任
mysql_innodb_cluster_metadata库里的当前视图
如果用的是传统主从（非 InnoDB Cluster），Router 无法自动识别主从切换，只能靠外部工具（如 MHA、Orchestrator）修改 Router 配置并重载（
mysqlrouter --reload）。
最常被忽略的一点：Router 进程本身没有“选主”能力，它只是个状态消费者。主从切换是否成功、元数据是否及时更新、应用连接是否断开重连——这三个环节漏掉任何一个，高可用就断在中间。
