MySQL主从复制从5.6版本开始稳定支持，因其引入GTID、多线程复制和更准确的延迟监控；8.0与5.7不支持反向复制，且需注意认证插件、binlog格式、server_id等兼容性限制。
MySQL 主从复制从哪个版本开始稳定支持
MySQL 主从复制在 5.0 版本已基本可用，但真正具备生产级稳定性、易用性和监控能力是从 5.6 开始。尤其是 5.6 引入了 GTID（Global Transaction Identifier）、多线程复制（slave_parallel_workers > 0）、复制延迟监控（Seconds_Behind_Master 更准确）等关键改进。
如果你还在用 5.5 或更早版本，建议升级——它们缺乏自动故障转移基础、不支持基于 GTID 的切换，且 binlog 格式（如 MIXED）行为不够一致，容易导致主从不一致。
MySQL 8.0 的主从兼容性有哪些实际限制
8.0 和 5.7 之间**不支持反向复制**（即 8.0 主库 + 5.7 从库 是允许的，但 5.7 主库 + 8.0 从库 会失败），因为 8.0 默认启用 caching_sha2_password 认证插件，而 5.7 客户端不原生支持；同时 8.0 的 DDL 原子性、数据字典变更无法被旧版本从库解析。
- 主库为
8.0.26+时，需显式设置default_authentication_plugin = mysql_native_password才能兼容老客户端或5.7从库 -
binlog_format必须设为ROW：STATEMENT在8.0中对 JSON、窗口函数等操作不安全，从库可能报错Could not execute Write_rows event -
server_id必须全局唯一，且不能为0；8.0对该值校验更严格，启动时即拒绝非法配置
跨大版本搭建主从时最常踩的坑
不是所有“能连上、能启 IO/SQL 线程”的组合都真正可靠。常见断裂点集中在权限、字符集、SQL 模式和系统表结构上。
- 主库
my.cnf中若含skip_slave_start，从库重启后复制自动停止，但日志里无明显错误，只表现为Slave_SQL_Running: No - 主从
collation_server或character_set_server不一致，会导致CREATE TABLE ... SELECT类语句在从库因隐式转换失败 -
sql_mode差异引发问题：例如主库是STRICT_TRANS_TABLES，从库是空或宽松模式，插入超长字符串时主库报错、从库静默截断，造成数据不一致 - 使用
mysqldump --single-transaction --master-data=2导出时，若主库为8.0而未加--set-gtid-purged=OFF，导入到5.7从库会因 GTID 语句报错
云厂商 RDS 的主从是否遵循同样规则
不完全。阿里云 RDS MySQL、腾讯云 CDB、AWS RDS 都屏蔽了底层 CHANGE MASTER TO 操作，也不开放 super 权限，因此你无法手动配置跨版本复制链路。它们内部主从通常强制同版本（如主 8.0.32 → 从 8.0.32），升级时采用滚动替换而非逻辑复制切换。
这意味着：如果你依赖 RDS，就别试图用 5.7 实例去拉 8.0 RDS 的 binlog；想做异构同步，得走 DTS、Canal 或 Debezium 这类中间层，而不是原生复制协议。
真正容易被忽略的是：RDS 的「只读实例」虽然显示为从库，但它不暴露 SHOW SLAVE STATUS 全字段，Seconds_Behind_Master 可能滞后数十秒才更新，不能当作实时延迟指标来告警。
