主从同步前必须确认log-bin已开启且路径可写、server-id主从不能相同、binlog-format设为mixed或row；change replication source to需注意source_ssl和source_auto_position；从库须设read_only=1并限制账号权限。
主从同步前必须确认的 3 个 MySQL 配置项
宝塔面板里点几下就配主从？不行。很多同步失败，根源都在主库没开 binlog 或从库没设 server-id。这两个值不是“可选”，是强制要求。
-
log-bin必须开启，且路径可写（宝塔默认在/www/server/mysql/data/下，但实际日志名是mysql-bin.000001这类，别只看配置文件写了就以为生效） -
server-id主库和从库**绝对不能相同**，常见错误是两台机器都用宝塔默认的1，结果 IO 线程直接拒绝连接 -
binlog-format建议显式设为MIXED或ROW；STATEMENT在含NOW()、UUID()等函数时极易导致主从数据不一致
用 CHANGE REPLICATION SOURCE TO 配从库时的参数陷阱
宝塔界面“数据库→主从复制”里填的字段，最终会转成这条 SQL。但界面不暴露所有参数，容易漏掉关键项，比如 SOURCE_SSL 和 SOURCE_AUTO_POSITION。
- 如果主库启用了 SSL（宝塔 8.x 默认开启），从库必须加
SOURCE_SSL=1，否则报错ERROR 2003 (HY000)或SSL connection error - 主库开了 GTID（
gtid_mode=ON），从库必须用SOURCE_AUTO_POSITION=1，不能手动填SOURCE_LOG_FILE和SOURCE_LOG_POS，否则启动 IO 线程就报ERROR 1777 - 账号权限要单独给：仅
REPLICATION SLAVE不够，还得REPLICATION CLIENT（否则SHOW REPLICA STATUS查不到完整状态）
同步卡住时优先查 Seconds_Behind_Master 和 SQL_Delay
宝塔面板显示“已连接”不代表数据实时同步。真正要看的是延迟秒数，以及有没有人为设置延迟。
-
Seconds_Behind_Master: NULL表示 IO 线程没连上，先查Source_IO_State（是不是Connecting to master）和网络连通性（telnet 主库IP 3306） -
Seconds_Behind_Master: 0也不代表完全一致——可能刚追平，下一秒就因大事务打满 relay log 磁盘而卡住 - 宝塔界面没暴露
SQL_Delay设置项，但如果你或同事手动执行过CHANGE REPLICATION SOURCE TO SOURCE_DELAY=3600，那延迟就是一小时，面板不会提醒
从库只读模式不是默认开启的，read_only=1 必须手动设
很多人以为“从库”天然不能写，其实 MySQL 默认允许写入。一旦误操作更新了从库表，后续主库同表再更新，就会触发主键冲突或唯一索引冲突，同步直接中断。
- 在从库 my.cnf 里加
read_only=1（注意不是set global read_only=1，重启后失效） - 超级用户仍能绕过
read_only，所以还要限制账号权限：给应用账号只授SELECT，别给INSERT/UPDATE/DELETE - 宝塔备份脚本若连的是从库地址，且用了 root 账号，
mysqldump可能因锁表失败报Access denied; you need (at least one of) the PROCESS privilege(s)——这不是权限不足，是read_only拦住了元数据锁
主从同步最麻烦的从来不是配通，而是配通之后没人盯 SHOW REPLICA STATUS\G 里的 Until_Log_File 和 Exec_Source_Log_Pos 是否在动。一停就是半天，还查不出哪条语句卡住。
