mysql如何配置一主一从复制_mysql主从异步复制基本步骤

主库需开启binlog并配置唯一server-id：在my.cnf的[mysqld]段添加log-bin=mysql-bin、server-id=1、binlog-format=row，重启后用show variables确认生效。

主库怎么开 binlog 并配好唯一 server-id

MySQL 主从复制的前提是主库必须开启二进制日志（binlog），否则从库根本没东西可拉。默认很多安装包（比如某些 docker 镜像或一键脚本）会关掉 binlog，或者压根没配 server-id —— 这会导致从库启动时报错 Error 1236 (HY000): Could not find first log file name in binary log index file 或直接拒绝连接。

实操建议：

• 编辑主库配置文件（通常是 /etc/mysql/my.cnf 或 /etc/my.cnf），在 [mysqld] 段下确保有：

  log-bin = mysql-bin<br>server-id = 1<br>binlog-format = ROW

• server-id 必须是正整数，且主从不能重复；主库设为 1 是常见做法，但不是强制，只要全局唯一就行
• binlog-format 推荐用 ROW，语句级（STATEMENT）在函数、时间戳、自增等场景下容易主从不一致
• 改完重启 MySQL（systemctl restart mysql），然后进 MySQL 执行 SHOW VARIABLES LIKE 'log_bin'; 和 SHOW VARIABLES LIKE 'server_id'; 确认生效

从库怎么连上主库并指定起始位置

从库靠 CHANGE REPLICATION SOURCE TO（MySQL 8.0.23+）或旧版 CHANGE MASTER TO 命令告诉自己“去哪拉日志、从哪开始拉”。很多人卡在这步，不是账号没权限，就是位点（source_log_file / source_log_pos）填错了。

实操建议：

• 主库上先创建复制专用账号：

  CREATE USER 'repl'@'%' IDENTIFIED WITH mysql_native_password BY 'your_strong_pass';<br>GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';<br>FLUSH PRIVILEGES;

• 主库执行 SHOW MASTER STATUS; 记下当前 File 和 position（比如 mysql-bin.000002 和 154）
• 从库执行：

  CHANGE REPLICATION SOURCE TO<br>  SOURCE_HOST='主库IP',<br>  SOURCE_USER='repl',<br>  SOURCE_PASSWORD='your_strong_pass',<br>  SOURCE_LOG_FILE='mysql-bin.000002',<br>  SOURCE_LOG_POS=154;<br>START REPLICA;

• 注意：MySQL 8.0.23+ 用 SOURCE_* 前缀，旧版本用 MASTER_*；命令里不能漏掉分号，START REPLICA（非 START SLAVE）是新语法

怎么确认复制真跑起来了，而不是假活

执行 START REPLICA 后，很多人只看 SHOW REPLICA STATUSG 里 Replica_IO_Running 和 Replica_SQL_Running 都是 Yes 就以为完事了。其实这两项可能短暂为 Yes 又变 No，或者卡在某个错误上不动，而 Seconds_Behind_Master 显示 NULL 或一直不变。

实操建议：

• 重点盯三个字段：Replica_IO_Running（网络连接和日志接收）、Replica_SQL_Running（本地回放）、Seconds_Behind_Master（延迟秒数）
• 如果任一为 No，立刻查 Last_IO_Error 或 Last_SQL_Error 字段，常见如 access denied（账号权限问题）、Could not parse relay log Event entry（格式不兼容）、Duplicate entry（主从数据不一致导致冲突）
• 用 SHOW PROCESSLIST; 看有没有 Replica_IO 和 Replica_SQL 线程在运行
• 最稳的验证方式：主库建个测试表、插一行，等几秒后去从库查，别只信状态字段

为什么从库写入后主从就裂开了

异步复制本身不阻止你在从库写数据，但一旦你执行了 INSERT、UPDATE 或 DROP，后续主库发来的同表同行操作大概率报错（比如 Duplicate entry 或 Can't find record），Replica_SQL_Running 直接挂掉。这不是 bug，是设计如此。

实操建议：

• 生产环境从库务必加 read_only = ON（写在 my.cnf 的 [mysqld] 下），它能拦住普通用户写操作（root 仍可写，所以还要配合账号权限控制）
• 如果真需要从库临时写，先 SET GLOBAL read_only = OFF;，操作完立刻关回去，且要清楚后果：之后得人工跳过错误或重搭从库
• 不要依赖 skip_slave_start 或盲目用 SET GLOBAL sql_slave_skip_counter = 1 跳错——这相当于把病灶捂住，下次还犯
• 异步复制没有强一致性保障，高并发写 + 网络抖动时，Seconds_Behind_Master 拉到几十秒甚至几分钟都正常，别一看到延迟就 panic

主从复制看着步骤少，真正麻烦的是位点对齐、权限闭环、错误归因和只读防护——这些地方松一扣，后面排查起来全是时间黑洞。