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滚动更新或云主机重建时极容易被忽略。
