orchestrator是专为mysql主从架构设计的高可用管理工具，具备自动拓扑发现、智能故障检测与安全重构能力，支持raft集群部署、多步校验自动切换、拖拽式拓扑重构及pseudo-gtid兼容等核心功能。
Orchestrator 是专为 MySQL 主从架构设计的高可用管理工具，它不依赖 VIP 或外部仲裁，而是通过自动拓扑发现、智能故障检测与安全重构能力，让主从集群真正具备“自愈”能力。关键在于配置得当、节点协同、切换可控。
自动发现与可视化拓扑
Orchestrator 启动后会主动扫描已录入的任意一个 MySQL 实例，基于 SHOW SLAVE HOSTS 或复制 I/O 线程信息，递归发现整个主从链路。它实时绘制出带状态标记的拓扑图：主库标为绿色，延迟超阈值的从库变黄，断连或 IO/SQL 线程停止的节点标红。即使主库宕机，拓扑图仍保留历史结构，方便快速定位问题点。
建议启用以下配置确保发现稳定：
- DiscoverByShowSlaveHosts: true（适用于传统 binlog position 复制）
- InstancePollSeconds: 5–10（缩短轮询间隔，提升响应速度）
- UnseenInstanceForgetHours: 240（4天未通信才清理，避免误删临时下线节点）
Raft 模式保障 Orchestrator 自身高可用
单点 Orchestrator 是风险源。必须部署至少 3 个节点组成 Raft 集群，由 Raft 协议选举 Leader 对外提供服务，Follower 同步元数据。Leader 故障时秒级完成新选举，整个过程对上层切换逻辑无感。
核心配置项需在每个节点的 orchestrator-raft-env.conf.json 中统一设置：
- RaftEnabled: true
-
RaftDataDir: 独立目录（如
/var/lib/orchestrator/raft），不可共用 -
RaftBind: 绑定本机 IP+唯一端口（如
192.168.1.10:10007） - RaftNodes: 列出全部节点地址（含自己），顺序无关，但必须完全一致
主库故障时的安全自动切换
Orchestrator 不是简单地“选一个从库提主”，而是执行多步校验：确认候选从库的 SQL 线程已追平、无未执行 relay log、复制坐标可比对；再根据权重（ReplicationDepth、BinlogServer 是否启用等）选出最优目标；最后原子性地重置复制关系，并更新 ProxySQL 或 DNS（若已集成）。
为防止误切，推荐配置：
- FailureDetectionPeriodBlockMinutes: 1（故障确认需持续 1 分钟异常，避免瞬断干扰）
- RecoveryPeriodBlockSeconds: 3600（1 小时内只允许一次恢复操作）
- RecoverMasterClusterFilters: ["*"]（对所有匹配集群启用主库恢复）
手动干预与拓扑重构能力
Web 界面支持拖拽调整从库归属，Orchestrator 会在后台自动计算 GTID 或 binlog position 差异，注入 SET GLOBAL gtid_purged 或 CHANGE MASTER TO MASTER_LOG_FILE 命令，确保移动后复制不中断。对于不支持 GTID 的 MySQL 5.7，它还能启用 Pseudo-GTID 注入机制，实现位置精准追踪。
日常运维中常用操作包括：
- 将某从库临时设为只读（
set read_only=1），用于备份或审计 - 启用维护模式（
begin-maintenance），屏蔽该节点的自动恢复行为 - 调用 HTTP API 触发
/api/recover手动触发指定实例恢复流程
