动真格：给订单库配从库
原理铺垫了十篇，这回动真格——老王的订单库要做读写分离，第一步先搭一主两从。环境约定：主库 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 是否都是 Yes8.0.22 起 CHANGE MASTER TO 更名为 CHANGE REPLICATION SOURCE TO，SHOW SLAVE STATUS 改叫 SHOW REPLICA STATUS，旧语法仍兼容——看到老文章用旧词别慌，一个意思。
第六步：验收
SHOW REPLICA STATUS 的输出几十行，日常盯这几个字段：
| 字段 | 健康值 | 异常排查方向 |
|---|---|---|
| Replica_IO_Running | Yes | No 则看 Last_IO_Error：网络、防火墙、账号密码、server_id 重复 |
| Replica_SQL_Running | Yes | No 则看 Last_SQL_Error：从库数据冲突、GTID 缺口、表结构不一致 |
| Seconds_Behind_Source | 0 | 持续大于 0 就是延迟，治理方案第 12 篇专讲 |
| Retrieved / Executed_Gtid_Set | 两边一致 | 差距大说明回放跟不上拉取 |
最后做端到端验证：主库插一条测试数据，两个从库立刻能查到；再从业务账号试着往从库写，应被 read_only 拒绝——链路和防护双确认。
翻车排查清单
- server_id 重复：IO 线程连上就断，主库错误日志写明 duplicate server id；
- 3306 没放行：IO_Running = Connecting，telnet 通了再谈复制；
- 先 START 后导数据：GTID 缺口导致 SQL 线程报错，重新对齐初始数据（RESET REPLICA 后重来）；
- 从库被误写：super_read_only 忘了开，数据冲突后复制中断；
- 主键冲突 1062：多数是有人绕过复制直接改了从库——从库纪律问题。
一主两从跑起来了，但「跑起来」和「跑得好」之间隔着一个字：延迟。主从延迟从哪来、并行复制和半同步怎么救，下一篇拆解。
咖啡凉了，记得趁热喝。
评论 (0)