主从搭建前必须确认主库server_id唯一且非1、log_bin=ON、binlog_format=ROW；从库datadir必须为空；xtrabackup备份需加--slave-info、--no-timestamp或--target-dir，GTID模式还需--gtid。
主从搭建前必须确认的 3 个检查点
不验证这三项，xtrabackup 恢复后大概率从库起不来或数据不一致。
- 主库
server_id必须唯一且非 1（从库不能和主库相同），log_bin必须为ON，否则SHOW MASTER STATUS会报错或返回空 - 主库需开启
binlog_format = ROW，MIXED在某些 DDL 场景下会导致从库解析失败，STATEMENT则无法支持部分函数和 UDF - 从库的
datadir必须为空，且不能残留ibdata1、ib_logfile*等文件——xtrabackup的--apply-log不会覆盖已有 InnoDB 文件，强行恢复会卡在崩溃恢复阶段
用 xtrabackup 备份时最容易漏掉的参数
只跑 xtrabackup --backup 是不够的；缺了关键参数，备份出来的数据无法用于主从搭建。
- 必须加
--slave-info：它会在备份目录里生成xtrabackup_slave_info，里面包含CHANGE MASTER TO所需的MASTER_LOG_FILE和MASTER_LOG_POS - 必须加
--no-timestamp或明确指定--target-dir，否则默认按时间戳建子目录，后续--prepare和拷贝容易路径出错 - 如果主库用了
gtid_mode = ON，还得加--gtid，否则xtrabackup_slave_info不会写入Executed_Gtid_Set，从库启动后无法自动定位同步位点
示例命令：xtrabackup --backup --slave-info --no-timestamp --target-dir=/backup/full --user=backup --password=xxx
恢复到从库后 set global read_only=on 不生效？
这是常见假象——read_only 确实生效了，但复制线程（SQL_THREAD）被允许绕过它。真正要防写入的是 super_read_only。
-
read_only=ON只限制普通用户，replication slave权限用户（如复制账号）仍可执行INSERT/UPDATE - 必须设
super_read_only=ON，它会同时锁住所有用户（包括拥有SUPER权限的用户），但注意：MySQL 5.7.20+ 才支持该变量，低版本只能靠权限控制 - 设完别忘了
STOP SLAVE; START SLAVE;，否则已有的 SQL 线程可能还在跑旧任务，导致位点错乱
从库启动后 Seconds_Behind_Master 一直为 NULL
不是延迟高，而是复制根本没跑起来。最常卡在两个地方：
-
SHOW SLAVE STATUS\G中Slave_IO_Running: No→ 检查主库网络连通性、复制账号权限（至少需要REPLICATION SLAVE）、主库bind_address是否监听了从库可访问的 IP -
Slave_SQL_Running: No且Last_SQL_Errno: 1062→ 多半是备份时主库有未提交事务，--apply-log后残留了部分 binlog event，导致从库重放时主键冲突；此时应清空从库datadir，重新--prepare并START SLAVE - 如果
Seconds_Behind_Master显示为NULL且Slave_IO_Running和Slave_SQL_Running都是Yes，说明复制已就绪但尚未开始追赶（比如主库当前没新写入），可手动在主库执行INSERT INTO test.t1 VALUES (now());触发一次日志写入观察变化
物理备份恢复主从，最难的从来不是命令怎么敲，而是每一步的“状态是否真的符合预期”——SHOW SLAVE STATUS 要逐字段看，SELECT @@global.gtid_executed 和 SELECT @@global.gtid_purged 在 GTID 模式下必须对得上，差一个字符都会让 START SLAVE 失败。
