MySQL 8.0.22+可通过performance_schema元数据表查本机复制状态，但无法自动还原完整拓扑结构；需人工交叉比对server_id、连接配置及网络信息才能准确识别级联关系。
MySQL 8.0.22+ 可以直接从 performance_schema 和 replication_applier_status_by_coordinator 等元数据表查出当前复制链路的实时状态，但**不能自动还原完整拓扑结构（比如级联中的中间节点是否又连了下级从库）**——这些表只反映“本机作为从库时连接了谁”，不记录“本机作为主库时被谁连”。真正能拼出拓扑的，得靠人工交叉比对 + 外部运维信息。
查本机是否为从库：看 replication_connection_configuration
这张表存的是本机配置的主库连接参数，只要它有记录，就说明当前实例是 Slave：
SELECT CHANNEL_NAME, HOST, PORT, USER, AUTO_POSITION FROM performance_schema.replication_connection_configuration;
常见情况：
- 返回空结果 → 本机没配从库角色，可能是 Master 或独立实例
-
HOST是内网 IP（如192.168.10.21）→ 主库大概率在同机房，需登录该 IP 验证 -
AUTO_POSITION=1→ 使用 GTID 复制，后续查同步位点要依赖GTID_EXECUTED，不是File/Position
查本机作为主库被谁连：没有现成元数据表
MySQL 不在系统表里持久化 “谁连了我” 的连接关系。SHOW PROCESSLIST 能看到当前活跃的 Slave IO 线程（User 字段为 system user，Command 为 Connect），但这是瞬时快照，无法判断是否稳定接入、是否配置了多源或级联中转。
更实际的做法是查主库的错误日志或慢日志（如果开启 log_warnings = 2）：
grep "Replication" /var/log/mysql/error.log | tail -20
里面会出现类似 Started replication thread for channel '' from '192.168.10.22:3306' 的记录，可辅助确认从库来源。
查复制延迟和同步状态：优先用 replication_applier_status_by_worker
这张表比传统的 SHOW SLAVE STATUS\G 更细粒度，尤其对并行复制（slave_parallel_workers > 0）有效：
SELECT CHANNEL_NAME, WORKER_ID, LAST_APPLIED_TRANSACTION, LAST_APPLIED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP, APPLYING_TRANSACTION FROM performance_schema.replication_applier_status_by_worker;
关键点：
-
LAST_APPLIED_TRANSACTION是 GTID（如aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaa1:1042），可直接跟主库的SELECT GTID_EXECUTED;对比差值 - 若
APPLYING_TRANSACTION为空且LAST_APPLIED_TRANSACTION停滞不动 → SQL 线程卡住，不是网络延迟 - 多个
WORKER_ID显示不同 GTID 进度 → 并行复制下存在事务分发不均，可能拖慢整体同步
拓扑不是一张表能画出来的。真正可靠的拓扑图，必须把每台机器的 server_id、replication_connection_configuration 输出、以及人工确认的网络可达性串起来——漏掉任意一环，就可能把级联从库误判成直连主库。
