orchestrator可直接接管已运行mysql主从集群，但须满足硬性前提：所有实例配置report_host且非localhost，主库启用log-bin与唯一server-id，从库io/sql线程均运行，gtid模式需开启并强制一致性，配置文件参数须与实际环境严格匹配。
Orchestrator 能直接接管已运行的 MySQL 主从集群，无需重建复制关系，但必须满足几个硬性前提——否则会发现失败、切换卡住或元数据错乱。
确认 MySQL 实例已正确暴露复制状态
Orchestrator 依赖 SHOW SLAVE STATUS 和 SHOW MASTER STATUS 输出来识别拓扑。常见失效场景是：从库 IO 线程未运行、主库未开启 log_bin、或 report_host 配置缺失。
- 所有 MySQL 实例（主+从）必须配置
report_host，且值为可被 Orchestrator 服务器解析的 IP 或主机名（不能是localhost或127.0.0.1） - 主库需启用 binlog：
log-bin=mysql-bin，并设置server-id（全局唯一） - 从库必须处于
Slave_IO_Running: Yes+Slave_SQL_Running: Yes状态；若仅 SQL 线程运行，Orchestrator 会将其识别为“孤立实例”而非从库 - 使用 GTID 时，确保
gtid_mode=ON且enforce_gtid_consistency=ON，否则orchestrator在故障转移时可能拒绝操作
orchestrator.conf.json 中关键参数必须匹配现有集群
配置文件不是模板填空，而是与实际环境强耦合。填错一个字段，就可能导致发现超时或权限拒绝。
-
MySQLOrchestratorHost和MySQLOrchestratorPort指向 Orchestrator 自己的元数据库（MySQL），不是被管集群的地址 -
MySQLConnectTimeoutSeconds建议设为2，避免因网络抖动导致批量发现失败 -
DiscoveryIntervalSeconds控制主动扫描频率，默认60秒；生产环境可调至10，但会增加被管 MySQL 的SHOW PROCESSLIST查询压力 -
DatabaselessMode设为false（默认），否则无法持久化拓扑快照和审计日志 - 若被管 MySQL 使用非标准端口（如
3307），必须在DiscoverByShowSlaveHosts为true时，确保所有从库的report_port显式配置，否则 Orchestrator 只会尝试连接:3306
手动切换（switchover）前必须验证前置条件
Web 界面点“Promote to master”看似简单，但底层会执行一连串校验。跳过检查等于把集群推向不可逆分裂。
- 目标从库的
Seconds_Behind_Master必须 ≤1（单位：秒），否则 Orchestrator 直接拒绝操作；可通过orchestrator-client -c relocate -d source:port -u dest:port强制等待追平 - 原主库必须仍可连通（即使只读），Orchestrator 需从中读取最新 binlog position 或 GTID set，用于重置新主库的复制起点
- 若使用 Pseudo-GTID，需确认所有实例已启用：
SELECT @@pseudo_gtid_enabled;返回1，否则切换后可能丢失部分事务 - 切换命令实际是原子操作：
orchestrator-client -c graceful-master-takeover -a old-master:3306 -d new-master:3306，其中-a是原主，-d是目标从库 —— 参数顺序反了会导致“降级失败”错误
切换后最易忽略的三件事
切换完成不等于高可用生效。很多团队卡在最后一步：应用连不上新主库。
- 原主库不会自动停止写入，它只是被降级为从库；必须人工执行
STOP SLAVE; RESET SLAVE ALL;，否则它可能继续接收旧应用的写请求，造成双写 - Orchestrator 不修改 DNS 或 VIP；如果应用直连 IP，需同步更新连接字符串；若用 ProxySQL，需调用其 API 刷新
mysql_servers表 - 被降级的原主库在 Web 界面显示为红色，点击 “Start replication” 后，仍需检查其
Seconds_Behind_Master是否持续增长 —— 若一直为NULL，说明新主库未开启log_slave_updates，导致级联复制中断
