MySQL迁移任务中的数据流向监控_使用流量分析工具排查

主从复制流量突增但延迟不涨大概率是代理或应用直连从库读取、或从库被误写入INSERT ... SELECT 和 LOAD DATA LOCAL INFILE 会绕过复制监控并放大负载。MySQL主从复制流量突增但延迟不涨SHOW SLAVE STATUS 看不出问题这种情况大概率是网络层或中间件在“悄悄转发”流量比如代理ProxySQL、MaxScale或应用直连了从库做读请求而监控只盯着复制线程本身。复制延迟低 ≠ 从库负载低更不等于数据流向受控。实操建议用 tcpdump 抓取从库 3306 端口的入向流量过滤非复制线程来源 tcpdump -i any port 3306 and not host [主库IP]检查 information_schema.PROCESSLIST 中非 system user 的连接重点关注 Host 字段是否大量来自应用服务器而非主库确认是否有 read_onlyOFF 的从库被误写入这类写入不会进复制流但会污染数据一致性用 pt-query-digest 分析慢日志时发现大量 INSERT ... SELECT但业务没这么用迁移过程中常有人用 INSERT INTO t1 SELECT * FROM t2 类语句批量导数据这类操作在源库记为一条语句但在从库会放大成逐行写入极易打满 IO 和复制线程。更麻烦的是它不触发 binlog_row_imageFULL 的完整镜像可能让基于行的复制丢失上下文。实操建议在源库开启 binlog_rows_query_log_eventsON让 mysqlbinlog 能还原原始语句方便定位是谁在跑这类操作检查 SHOW VARIABLES LIKE binlog_row_image迁移期间建议设为 FULL避免 UPDATE/DELETE 因缺失旧值导致从库校验失败禁用从库的 sql_log_bin0 临时写入后务必手动补 binlog 或跳过事件否则后续 DDL 可能卡住Wireshark 里看到大量 COM_QUERY 包含 LOAD DATA INFILE但 MySQL 错误日志没报错LOAD DATA INFILE 在主从架构中默认被禁止secure_file_priv 不同 从库 read_only但如果客户端走的是 LOAD DATA LOCAL INFILE它实际由客户端读文件、分片发 INSERT服务端根本看不到“文件路径”也就不会校验权限——这种行为绕过所有服务端管控且无法被 binlog 完整记录。 橙篇 百度文库发布的一款综合性AI创作工具