mysql主从复制必须配置的5个关键参数是server-id、log-bin、binlog-format=row、read_only=on、relay_log_recovery=on；缺一即导致延迟或中断。
MySQL主从复制必须配置的5个关键参数
不配全这5个参数，主从延迟或中断是必然的。尤其在分布式场景下，网络抖动更频繁，遗漏任一参数都会让SHOW SLAVE STATUS反复显示Seconds_Behind_Master: NULL或IO_Running: No。
-
server-id：主库和从库必须不同，且不能为0（常见坑：Docker容器批量启动生成相同ID） -
log-bin：主库必须开启，建议指定绝对路径如/var/lib/mysql/mysql-bin，避免默认名被清理策略误删 -
binlog-format=ROW：强烈推荐，语句级（STATEMENT）在分布式事务中易丢数据，比如NOW()、UUID()等函数主从结果不一致 -
read_only=ON：从库务必启用，防止应用误写导致主从不一致（注意：SUPER权限用户仍可写，需配合super_read_only=ON） -
relay_log_recovery=ON：从库崩溃重启后自动重建中继日志，否则可能跳过部分binlog事件
Docker Compose快速部署主从集群的避坑写法
用docker-compose.yml起两个MySQL实例看似简单，但默认bridge网络+无显式时区/字符集配置，会导致主从同步失败或中文乱码。
- 主库
my.cnf挂载内容必须包含：default-time-zone='+08:00'和collation-server=utf8mb4_unicode_ci，从库配置需完全一致 - 不要用
image: mysql:8.0裸启动——8.0默认启用caching_sha2_password插件，从库CHANGE REPLICATION SOURCE TO会报错Plugin caching_sha2_password could not be loaded；改用mysql:8.0.33或启动时加--default-authentication-plugin=mysql_native_password - 主库初始化SQL中，创建复制用户必须显式指定IP范围：
CREATE USER 'repl'@'%' IDENTIFIED BY '123456'; GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';，@'localhost'在容器间不可达
验证主从是否真正可用的3个实操检查点
别只看Slave_IO_Running: Yes和Slave_SQL_Running: Yes，那只是线程活着，不代表数据一致。
- 在主库执行
INSERT INTO test_tbl VALUES (UUID(), NOW());，立刻在从库查SELECT * FROM test_tbl ORDER BY 2 DESC LIMIT 1;，对比UUID和时间戳是否完全一致——这是检验ROW格式和时钟同步的最简方式 - 运行
pt-table-checksum（Percona Toolkit）校验表级数据一致性，注意从库要关掉binlog_format=STATEMENT，否则checksum语句会被记录并回放，造成死循环 - 模拟网络分区：
docker pause mysql-slave停从库1分钟，再docker unpause，观察Seconds_Behind_Master是否能收敛到0；若持续增长，大概率是主库max_binlog_size太小（默认1GB），导致频繁切binlog文件，从库IO线程重建连接耗时增加
分布式环境下主从切换的硬约束条件
自动故障转移听着美好，但MySQL原生不支持高可用切换，任何基于mysqldump或GTID的脚本都必须满足三个前提，否则切完就是双主冲突或丢数据。
- 必须启用
gtid_mode=ON且enforce_gtid_consistency=ON，否则无法准确判断哪些事务已同步到从库 - 从库的
Executed_Gtid_Set必须完全包含主库Retrieved_Gtid_Set，用SELECT GTID_SUBSET('aaa-bbb-ccc', 'aaa-bbb-ccc,ddd-eee-fff')验证，返回1才可升主 - 切换前必须在原主库执行
SET GLOBAL read_only=ON并确认所有活跃事务结束（SHOW PROCESSLIST无Query状态），否则残留写入会与新主库产生GTID冲突
GTID的uuid:1-100这种格式看着简单，但跨机房部署时，如果主库机器重装后server-uuid变了，旧GTID就永远无法被新主识别——这个细节在K8s滚动更新或云主机重建时极容易被忽略。
