如何在从库配置复制_mysql slave设置方法

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),确认含以下参数:
log-bin = mysql-bin
server-id = 1
binlog-format = ROW # 推荐,兼容性与一致性更好

重启 MySQL 生效后,登录主库执行:

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

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

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

server-id = 2
# log-bin = mysql-bin # 如不作中间主库,可注释掉

重启从库后,执行复制源配置(以 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_RunningReplica_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 时,可能引发复制中断