怎样在不停止主库的情况下为MySQL新增一个从库？-mysql教程-PHP中文网

能，但必须满足三个硬性前提——主库已开log_bin、binlog_format='row'，且新从库能拿到主库上尚未被purge的binlog位点或有效gtid集合；不满足任一条件，复制启动即失败。

怎样在不停止主库的情况下为mysql新增一个从库？

直接说结论：能，但必须满足三个硬性前提——主库已开 log_bin、binlog_format = 'ROW'，且新从库能拿到一个主库上尚未被 purge 的 binlog 位点（或有效的 GTID 集合）。不满足任一条件，复制启动即失败，所谓“在线”只是假象。

很多线上环境主库虽开了 binlog，但格式仍是 STATEMENT，或压根没设 server-id，这会导致后续从库重放 SQL 时丢数据、跳过非确定性函数、甚至主键冲突。

检查是否启用 binlog：SHOW VARIABLES LIKE 'log_bin'; —— 返回 ON 才行
检查 binlog 格式：SHOW VARIABLES LIKE 'binlog_format'; —— 必须是 'ROW'，不是 'MIXED' 或 'STATEMENT'
SET GLOBAL binlog_format = 'ROW'; 只影响后续日志，已写入的不会变；若主库长期用 STATEMENT，建议先切一次日志再操作
server-id 必须非零且唯一，主库设为 1，旧从库 2，新从库就得设 3 或其他未占用值

取决于你的数据量、引擎类型和停机容忍度。两者都支持“不停主库”，但行为差异极大：

mysqldump --single_transaction --master-data=2：
- 仅适用于 InnoDB 表，MyISAM 会锁表
- --master-data=2 会在 dump 文件开头生成带注释的 CHANGE MASTER TO 语句，位置来自执行时刻的 SHOW MASTER STATUS
- 缺点：dump 文件大、恢复慢、网络传输耗时长，期间主库持续写入，新从库启动后要追很久
xtrabackup（推荐）：

MySQL
编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载
- 物理备份，不锁表，对主库压力小
- 备份完成时自带 xtrabackup_binlog_info 文件，记录精确的 binlog 文件名和 position
- 恢复后需执行 xtrabackup --apply-log，再拷到从库 datadir 并 chown
- 注意：MySQL 8.0+ 要用 percona-xtrabackup-80，版本不匹配会报 Unknown table engine 'InnoDB'

填错任意一项，START SLAVE 后 Slave_IO_Running 立刻为 No，错误日志里常出现：

Could not find first log file name in binary log index file → MASTER_LOG_FILE 名字拼错，或该文件已被 PURGE BINARY LOGS 清掉
Client requested master to start replication from position > file size → MASTER_LOG_POS 超出当前文件实际长度，说明位点无效
Access denied for user 'repl'@'xxx' (using password: YES) → 主库上 GRANT REPLICATION SLAVE ON <em>.</em> 没生效，或密码含特殊字符没加引号

正确做法：

主库执行 SHOW MASTER STATUS;，取 File 和 Position（用 xtrabackup 就取备份目录里的 xtrabackup_binlog_info）
从库执行：CHANGE MASTER TO MASTER_HOST='192.168.12.161', MASTER_USER='repl', MASTER_PASSWORD='xxx', MASTER_LOG_FILE='mysql-bin.000054', MASTER_LOG_POS=204194092;
若用 GTID，直接：CHANGE MASTER TO MASTER_AUTO_POSITION = 1;，但主从都得开启 gtid_mode=ON 且 enforce_gtid_consistency=ON

START SLAVE 不等于复制就通了。真正要看的是线程是否跑起来、有没有延迟、有没有跳过错误：

SHOW SLAVE STATUS\G 中：
- Slave_IO_Running: Yes 且 Slave_SQL_Running: Yes —— 两个线程都活
- Seconds_Behind_Master: 0 或缓慢下降 —— 正在追平，不是卡死
- Exec_Master_Log_Pos 应随时间递增，若长时间不动，查 Last_IO_Errno 或 Last_SQL_Errno
常见静默陷阱：slave_skip_errors 设为 all 或具体错误号，会让复制跳过主键冲突等致命错误，表面正常实则数据不一致
新从库上线后，别急着切读流量，先用 pt-table-checksum 对比主从表一致性，尤其注意 TIMESTAMP、AUTO_INCREMENT 字段