17370845950

MySQL主从复制核心是从库连接主库并重放binlog事件：主库需启用binlog、设唯一server-id、创建复制用户并记录binlog文件与位置；从库配置不同server-id，执行CHANGE REPLICATION SOURCE TO指定主库信息后启动复制，并检查IO和SQL线程状态及延迟。

在从库配置 MySQL 主从复制，核心是让从库连接到主库、获取二进制日志（binlog），并重放其中的事件。关键步骤包括：主库开启 binlog 并创建复制用户，从库执行 CHANGE REPLICATION SOURCE TO（MySQL 8.0.23+）或 CHANGE MASTER TO（旧版本），再启动复制线程。

主库准备：启用 binlog 并授权复制用户

确保主库已启用二进制日志，并记录当前 binlog 文件名和位置（用于从库起点）。同时创建专用复制账号，限制仅允许复制连接：

• 检查主库配置文件（如 /etc/my.cnf 或 /etc/mysql/mysql.conf.d/mysqld.cnf），确认含以下参数：

重启 MySQL 生效后，登录主库执行：

• FLUSH BINARY LOGS;（可选，生成新 binlog 文件便于定位）
• SHOW MASTER STATUS; 记下 File 和 Position 值（例如 mysql-bin.000003, 154）
• 创建复制用户：
  CREATE USER 'repl'@'%' IDENTIFIED BY 'your_secure_password';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
FLUSH PRIVILEGES;

从库配置：设置复制源并启动同步

从库需有唯一 server-id（不能与主库冲突），且建议关闭 binlog（除非要级联复制）。编辑从库配置文件，加入：

重启从库后，执行复制源配置（以 MySQL 8.0.23+ 语法为例）：

• CHANGE REPLICATION SOURCE TO
    SOURCE_HOST='主库IP',
    SOURCE_USER='repl',
    SOURCE_PASSWORD='your_secure_password',
    SOURCE_LOG_FILE='mysql-bin.000003',
    SOURCE_LOG_POS=154;

• 启动复制：START REPLICA;（旧版本用 START SLAVE;）
• 查看状态：SHOW REPLICA STATUS\G（旧版为 SHOW SLAVE STATUS\G），重点关注：
  – Replica_IO_Running 和 Replica_SQL_Running 是否均为 Yes
  – Seconds_Behind_Master 是否逐渐归零

常见问题排查要点

若复制未正常运行，优先检查这几项：

• 网络连通性：从库能否 telnet 主库 IP + 3306 端口？防火墙是否放行？
• 账号权限与密码：从库连接测试：mysql -h 主库IP -u repl -p，确认能登录
• binlog 位置是否有效：主库上执行 SHOW BINARY LOGS;，确认指定的 SOURCE_LOG_FILE 仍存在；若主库已 purge，需重新导出全量数据+新 binlog 位点
• GTID 模式差异：若主从启用了 GTID（gtid_mode=ON），则不能用 SOURCE_LOG_FILE/POS，应改用：
  CHANGE REPLICATION SOURCE TO SOURCE_AUTO_POSITION = 1;

补充建议：提升稳定性与可观测性

生产环境建议增加基础防护和监控习惯：

• 从库设为只读：SET GLOBAL read_only = ON;（不影响复制线程，但阻止普通写入）
• 定期校验主从数据一致性，可用 pt-table-checksum 工具
• 监控 Seconds_Behind_Master 波动，突增可能预示 SQL 延迟或主库压力过大
• 避免在从库执行 DDL（如 ALTER TABLE），尤其未加 SQL_LOG_BIN=0 时，可能引发复制中断