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.0RDS 的 binlog；想做异构同步，得走 DTS、Canal 或 Debezium 这类中间层，而不是原生复制协议。
真正容易被忽略的是：RDS 的「只读实例」虽然显示为从库，但它不暴露
SHOW SLAVE STATUS全字段，
Seconds_Behind_Master可能滞后数十秒才更新，不能当作实时延迟指标来告警。
