17370845950

MySQL主从复制中，从库账号必须显式授予REPLICATION SLAVE权限；主库需执行SHOW MASTER STATUS获取binlog文件名和位置；从库配置server-id须唯一且非1；启动同步需执行START SLAVE；检查状态应使用SHOW SLAVE STATUS\G并关注Seconds_Behind_Master等关键字段。

CREATE USER 时必须显式指定 REPLICATION SLAVE 权限

MySQL 主从复制中，从库连接主库所用的账号不是普通用户，它需要能读取二进制日志（binlog）并拉取事件。仅授予 SELECT 或 REPLICATION CLIENT 不够，必须明确赋予 REPLICATION SLAVE 权限。

常见错误是沿用旧习惯建用户后补授权，但忘记刷新权限或漏掉该权限，导致从库报错：ERROR 2003 (HY000): Can't connect to MySQL server on 'xxx' (1130) 或更隐蔽的 ERROR 1236 (HY000): Got fatal error 1236 from master。

• 创建用户时直接授权比先建再授更可靠：

  CREATE USER 'repl_user'@'%' IDENTIFIED BY 'strong_pass_2025';
  GRANT REPLICATION SLAVE ON *.* TO 'repl_user'@'%';
  FLUSH PRIVILEGES;

• 若使用 MySQL 8.0+，注意默认认证插件为 caching_sha2_password，某些旧版客户端不兼容，可显式指定：

  CREATE USER 'repl_user'@'%' IDENTIFIED WITH mysql_native_password BY 'strong_pass_2025';

• 主机名建议用具体 IP 或子网（如 'repl_user'@'192.168.1.%'），避免开放 '%' 带来的安全风险

SHOW MASTER STATUS 输出的 File 和 Position 是 CHANGE MASTER TO 的关键参数

配置从库前，必须在主库执行 SHOW MASTER STATUS 获取当前 binlog 文件名和位置点。这两个值会作为 CHANGE MASTER TO 语句中的 MASTER_LOG_FILE 和 MASTER_LOG_POS 参数。

容易忽略的是：这个快照只代表「执行时刻」的状态，如果主库持续写入，从库启动延迟会导致跳过部分事件；若主库已切换 binlog（比如 FLUSH LOGS），而你仍用旧的 File 名，就会报错 Could not find first log file name in binary log index file。

• 务必在主库低峰期或已停写时执行 SHOW MASTER STATUS
• 记录输出中的 File（如 mysql-bin.000012）和 Position（如 154），不要手输，避免空格或大小写错误
• 从库执行 CHANGE MASTER TO 后，必须运行 START SLAVE; 才真正开始同步；仅 CHANGE MASTER TO 不会自动启动

从库 my.cnf 中 server-id 必须唯一且不能为 1

MySQL 复制依赖 server-id 区分节点身份。主库通常设为 1，所有从库必须设为其他非零整数（如 2、101），且彼此不能重复。否则会出现 Slave I/O thread not running 或日志循环写入问题。

另一个易错点是修改了 my.cnf 却未重启 mysqld，或重启后未确认生效：SELECT @@server_id; 返回仍是旧值。

• 编辑 /etc/my.cnf 或 /etc/mysql/mysql.conf.d/mysqld.cnf，在 [mysqld] 段落下添加：

  server-id = 2
  log_bin = /var/lib/mysql/mysql-bin
  read_only = ON

• log_bin 在从库上非必需，但开启有助于后续做级联复制；read_only = ON 可防误操作写入从库（注意：SUPER 用户仍可绕过）
• 重启后务必验证：mysql -u root -p -e "SELECT @@server_id, @@log_bin;"

检查复制状态要用 SHOW SLAVE STATUS\G，别只看 Slave_IO_Running

SHOW SLAVE STATUS\G 输出字段多，新手常只扫一眼 Slave_IO_Running 和 Slave_SQL_Running 都是 Yes 就认为 OK。但实际同步异常往往藏在 Seconds_Behind_Master 持续增长、Until_Log_File 非空、或 Retrieved_Gtid_Set 与 Executed_Gtid_Set 不一致里。

尤其当主库启用了 GTID（gtid_mode = ON），从库必须用 CHANGE MASTER TO ... MASTER_AUTO_POSITION = 1，否则即使线程显示运行，也可能卡在事件解析阶段。

• 用 \G 而非分号结尾，让字段垂直显示，便于定位关键项
• 重点关注：Seconds_Behind_Master（应为 0 或稳定小值）、Relay_Master_Log_File（应与主库当前 File 接近）、Exec_Master_Log_Pos（是否持续前进）
• 若出现 SQL_Delay > 0，说明人为设置了延迟复制，此时 Seconds_Behind_Master 显示的是延迟值而非真实滞后

配置复制不是一次性的操作，server-id 冲突、GTID 模式不匹配、binlog 位置漂移，任何一个细节出错都会让同步静默失败。最麻烦的是错误日志里没报错，但数据就是不同步——这时候得回到 SHOW SLAVE STATUS\G 逐行比对字段含义。