MySQL如何获取主从复制的实时拓扑结构：利用元数据表查询
从MySQL 8.0.22版本开始，事情变得方便了一些。你可以直接从performance_schema里的replication_applier_status_by_coordinator等元数据表，查到当前复制链路的实时状态。但这里有个关键限制：这些表无法自动还原出完整的拓扑结构。比如，你无法直接知道一个级联复制中的中间节点，是否又连接了下级从库。原因很简单，这些表只记录“本机作为从库时连接了谁”，却不会记录“本机作为主库时被谁连接”。所以，真想拼出一张准确的拓扑图，最终还是得靠人工交叉比对，再结合外部的运维信息。
查本机是否为从库：看replication_connection_configuration
这张表存放的是本机配置的主库连接参数。只要里面有记录，那就基本可以断定，当前实例扮演着Sla ve的角色。
SELECT CHANNEL_NAME, HOST, PORT, USER, AUTO_POSITION FROM performance_schema.replication_connection_configuration;
查询结果怎么解读？通常有这么几种情况：
- 如果返回空结果，那说明本机没有配置从库角色，它可能是一个主库，或者干脆就是个独立实例。
- 如果
HOST字段显示一个内网IP（比如192.168.10.21），那意味着它的主库大概率在同一个机房，下一步就需要登录这个IP去核实。 - 如果
AUTO_POSITION=1，说明复制使用了GTID模式。这一点很重要，意味着后续查看同步位点时，你得依赖GTID_EXECUTED，而不是传统的File/Position。
查本机作为主库被谁连：没有现成元数据表
这是目前的一个盲点。MySQL的系统表里，并不会持久化存储“谁连接了我”这种关系。虽然你可以通过SHOW PROCESSLIST命令，看到当前活跃的Sla ve 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 SLA VE STATUS\G，更推荐使用replication_applier_status_by_worker这张表。它的粒度更细，对于开启了并行复制（sla ve_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的输出、以及人工确认的网络可达性信息全部串联起来。漏掉其中任何一环，都可能把一台级联从库，错误地判断成直连主库。
