主从搭建实操：从零配出一主两从

动真格：给订单库配从库

原理铺垫了十篇，这回动真格——老王的订单库要做读写分离，第一步先搭一主两从。环境约定：主库 192.168.2.101，从库 A 192.168.2.102，从库 B 192.168.2.103，MySQL 8.0，GTID 全程护航。每一步都能照抄，最后附一份翻车排查清单。

第一步：主库配置

# 主库 my.cnf
[mysqld]
server_id = 101                  # 集群内唯一，绝不能重复
log_bin = mysql-bin              # 开 binlog（第 10 篇的主角）
binlog_format = ROW              # 行格式，主从一致性的基石
gtid_mode = ON                   # GTID 开启
enforce_gtid_consistency = ON    # 拒绝破坏 GTID 一致性的写法

GTID（全局事务标识）= 实例标识 + 事务序号，开启后每个事务有了全球唯一身份证，从库不用再记「复制到主库哪个文件哪个位点」，缺什么补什么，换主切换也省心。

第二步：主库建复制账号

CREATE USER "repl"@"192.168.2.%" IDENTIFIED WITH caching_sha2_password BY "Repl@2026";
GRANT REPLICATION SLAVE ON *.* TO "repl"@"192.168.2.%";

权限只给 REPLICATION SLAVE，网段限定内网——复制账号是链路命脉，最小权限 + 最小可达。caching_sha2_password 是 8.0 默认认证方式，非 SSL 连接需要在后面配置里带上 GET_SOURCE_PUBLIC_KEY。

第三步：从库配置

# 从库 A my.cnf（从库 B 把 server_id 改成 103）
[mysqld]
server_id = 102
relay_log = relay-bin            # 中继日志前缀
read_only = ON                   # 普通账号只读
super_read_only = ON             # 连有 SUPER 权限的也只读（除复制线程）

两层 read_only 都打开——从库的只读不靠自觉，靠配置。复制线程拥有豁免权，正常回放不受影响。

第四步：初始数据对齐

# 主库导出（--source-data=2 会把备份时的位点写进文件，仅作注释留档）
mysqldump -h 192.168.2.101 --single-transaction --source-data=2 --triggers --routines --all-databases > full.sql

# 从库导入
mysql -h 192.168.2.102 < full.sql

--single-transaction 用一致性快照导 InnoDB，不锁全表（原理第 21 篇讲）。传统方案要精确对齐 binlog 位点，GTID 模式下省了这一步：START REPLICA 后从库自动比对 GTID 集合，缺哪个事务补哪个。

第五步：启动复制

CHANGE REPLICATION SOURCE TO
  SOURCE_HOST = "192.168.2.101",
  SOURCE_PORT = 3306,
  SOURCE_USER = "repl",
  SOURCE_PASSWORD = "Repl@2026",
  SOURCE_AUTO_POSITION = 1,     -- GTID 自动定位
  GET_SOURCE_PUBLIC_KEY = 1;    -- 配合 caching_sha2_password
START REPLICA;
SHOW REPLICA STATUS;            -- 关注两行 Running 是否都是 Yes

8.0.22 起 CHANGE MASTER TO 更名为 CHANGE REPLICATION SOURCE TO，SHOW SLAVE STATUS 改叫 SHOW REPLICA STATUS，旧语法仍兼容——看到老文章用旧词别慌，一个意思。

第六步：验收

SHOW REPLICA STATUS 的输出几十行，日常盯这几个字段：

最后做端到端验证：主库插一条测试数据，两个从库立刻能查到；再从业务账号试着往从库写，应被 read_only 拒绝——链路和防护双确认。

翻车排查清单

• server_id 重复：IO 线程连上就断，主库错误日志写明 duplicate server id；
• 3306 没放行：IO_Running = Connecting，telnet 通了再谈复制；
• 先 START 后导数据：GTID 缺口导致 SQL 线程报错，重新对齐初始数据（RESET REPLICA 后重来）；
• 从库被误写：super_read_only 忘了开，数据冲突后复制中断；
• 主键冲突 1062：多数是有人绕过复制直接改了从库——从库纪律问题。

一主两从跑起来了，但「跑起来」和「跑得好」之间隔着一个字：延迟。主从延迟从哪来、并行复制和半同步怎么救，下一篇拆解。

咖啡凉了，记得趁热喝。