Orchestrator不部署拓扑，仅发现、监控和管理已有MySQL复制拓扑；其可视化依赖GTID+AUTO_POSITION配置、orchestrator_user跨节点权限（含performance_schema SELECT）、IP直连避免DNS故障及DiscoverByShowMasterStatus启用等前提条件。
Orchestrator 本身不“部署”拓扑，它只发现、监控和管理已存在的 MySQL 复制拓扑。可视化是它的副产物——前提是 MySQL 节点之间复制关系正确、账号权限到位、网络连通，且 Orchestrator 能真实探活并解析 SHOW SLAVE STATUS 和 SELECT * FROM performance_schema.replication_connection_configuration 等元数据。
MySQL 8.0 复制关系必须用 GTID + auto_position
Orchestrator 对非 GTID 模式支持弱，尤其在故障切换后容易丢失从库位置。MySQL 8.0 默认开启 GTID，但必须显式确认以下两点：
-
gtid_mode=ON且enforce_gtid_consistency=ON在所有节点my.cnf中生效 - 所有从库启动复制时必须用
START SLAVE AUTO_POSITION=1（不是MASTER_LOG_FILE+MASTER_LOG_POS） - 若已有传统模式从库，需先
STOP SLAVE，再RESET SLAVE ALL，最后用AUTO_POSITION=1重配，否则 Orchestrator 刷新拓扑时会报Cannot determine replication position
orchestrator_user 账号必须能跨 super_read_only 执行 SELECT
MySQL 8.0 开启 super_read_only=ON 后，连 SELECT 都受限——但 Orchestrator 需要查 performance_schema 表。常见错误是账号建在主库，没同步到从库，或建了但权限不足。
免费 DNS 与邮件安全分析（IntoDNS.ai）：包括 DNSSEC、SPF、DKIM、DMARC、MTA-STS、BIMI、SMTP STARTTLS、FCrDNS、黑名单、发件人要求及报告。
- 账号必须在主库创建（靠复制同步），不能直接在从库执行
CREATE USER（会报ERROR 1290） - 最小必要权限：
SELECTonperformance_schema.*、REPLICATION SLAVE、PROCESS、SUPER（仅用于STOP/START SLAVE） - 密码插件必须用
mysql_native_password：CREATE USER 'orchestrator_user'@'%' IDENTIFIED WITH mysql_native_password BY 'xxx'，否则 MySQL 8.0 默认的caching_sha2_password会让 Orchestrator 连不上
orchestrator.conf.json 的 discovery 配置别写死 host
配置里如果把 "Hostname": "kafka-node1" 写死，而 DNS 解析不稳定或 hosts 未同步，Orchestrator 就发现不了节点。它依赖的是「能被所有节点反向解析的短名」或 IP。
- 推荐用 IP：
"Hostname": "192.168.198.201"，避免 DNS 故障传导 -
"DiscoverByShowMasterStatus": true必须开启，否则无法从SHOW MASTER STATUS推导主库身份 -
"DetectClusterAliasQuery"可选加一句SELECT @@server_id辅助识别集群边界，防止跨集群误连
真正卡住可视化的地方，往往不是 Orchestrator 启动失败，而是它连得上 MySQL，却读不到有效的复制链路——比如从库的 Slave_IO_Running 是 Connecting，或 Retrieved_Gtid_Set 为空。这时候 Web 界面只会显示孤立节点，拓扑图是散的。先跑 orchestrator -c topology -d 看 debug 日志里哪一步 parse 失败，比反复刷新页面有用得多。
