mysql如何配置主从复制环境_mysql复制部署说明

必须开启主库binlog并设置唯一server-id；创建专用repl用户授权replication slave；记录show master status的file和position；从库执行change replication source to配置连接参数；启动start replica后检查replica_io_running和replica_sql_running均为yes。

确认主库是否开启 binlog 并设置唯一 server-id

mysql 主从复制依赖于主库的二进制日志（binlog），如果没开，从库根本无法获取变更事件。执行 SHOW VARIABLES LIKE 'log_bin'; 确认返回 ON；若为 OFF，需在主库配置文件（如 /etc/my.cnf 或 /etc/mysql/mysql.conf.d/mysqld.cnf）中添加：

log-bin = mysql-bin server-id = 1

注意：server-id 必须是 1–4294967295 范围内的整数，且主从不能重复；主库设为 1 是常见做法，但不是强制——只要全局唯一即可。

修改后必须重启 MySQL（systemctl restart mysql 或 service mysqld restart），仅重载配置不生效。

创建专用复制用户并授权

从库连接主库时，需要一个具备 REPLICATION SLAVE 权限的账号。不要复用 root 或应用账号，避免权限过大风险：

CREATE USER 'repl'@'%' IDENTIFIED BY 'StrongPass123!'; GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%'; FLUSH PRIVILEGES;

常见错误包括：

• 漏掉 FLUSH PRIVILEGES，导致授权不生效
• 账号绑定过于严格（如 'repl'@'192.168.1.10'），而从库 IP 动态变化或走 NAT，建议用 'repl'@'%' + 防火墙控制访问源
• MySQL 8.0+ 默认认证插件为 caching_sha2_password，部分旧客户端不兼容，可显式指定： CREATE USER 'repl'@'%' IDENTIFIED WITH mysql_native_password BY 'StrongPass123!';

获取主库当前 binlog 位置并配置从库

主库执行 SHOW MASTER STATUS;，记录 File 和 Position 值（例如 mysql-bin.000003, 154）。这是从库启动复制的起点。

从库上执行 CHANGE REPLICATION SOURCE TO（MySQL 8.0.23+）或 CHANGE MASTER TO（旧版本）：

CHANGE REPLICATION SOURCE TO   SOURCE_HOST='192.168.1.5',   SOURCE_USER='repl',   SOURCE_PASSWORD='StrongPass123!',   SOURCE_LOG_FILE='mysql-bin.000003',   SOURCE_LOG_POS=154;

关键点：

• MySQL 8.0.23 起命令名变更，旧写法会报错 Unknown system variable 'master_host'
• SOURCE_LOG_FILE 和 SOURCE_LOG_POS 必须与 SHOW MASTER STATUS 输出完全一致，大小写、空格、数字都不能错
• 若主库已运行一段时间，建议先 FLUSH TABLES WITH READ LOCK; 再查位点，锁表期间禁止写入，确保一致性；但生产环境慎用，可用 mysqldump --single-transaction --master-data=2 替代

启动复制并验证状态

从库执行 START REPLICA;（8.0.22+）或 START SLAVE;（旧版）。然后立刻检查：

SHOW REPLICA STATUSG

重点关注两行：

• Replica_IO_Running: Yes —— 表示从库能连上主库并读取 binlog
• Replica_SQL_Running: Yes —— 表示从库能解析并执行 relay log 中的事件

若任一为 No，看 Last_IO_Error 或 Last_SQL_Error 字段。典型问题有：

• Could not find first log file name in binary log index file：主库 binlog 文件被清理，SOURCE_LOG_FILE 已不存在，需重新做全量同步
• Slave failed to initialize relay log info structure：从库 relay-log.info 损坏，可停复制后删掉该文件再重启（MySQL 8.0+ 默认用表存储，影响较小）
• 主从时间不同步导致 GTID 冲突（若启用了 GTID），此时需跳过事务或重置复制

GTID 模式下，CHANGE REPLICATION SOURCE TO 不要指定 SOURCE_LOG_FILE/SOURCE_LOG_POS，改用 SOURCE_AUTO_POSITION = 1。

主从延迟和数据一致性不是配完就完事的事，Seconds_Behind_Master 的波动、网络抖动、大事务、从库硬件性能都会持续影响复制质量，得盯住监控，而不是只看启动那一刻的 Yes。