Shirone

分流方式#

主从、主主、多主结构#

• 一主多从：写只有一个入口，不存在写冲突，是最省心的形态；缺点是写节点仍是单点（靠切换解决）。
• 双主（主主）：两边都开 binlog 且互为主从，可以做写冗余，但同一行同时被两边写入会产生冲突，通常配合 VIP 只让一个节点对外写。
• 多主 / 组复制：由集群层做写冲突检测（MGR、Galera），见第二篇。

binlog 方式#

MySQL 的复制是基于 binlog（binary log）的逻辑复制：binlog保存了数据库的增删改事务操作（SQL语句），主库把数据变更写进 binlog，从库拉取后在本地重放。

1
[mysqld]
2
server_id              = 1          # 集群内必须唯一，0 会被拒绝
3
log_bin                = mysql-bin  # 开启 binlog
4
binlog_format          = ROW        # 高可用场景一律用 ROW
5
binlog_row_image       = FULL       # 记录变更前后完整行镜像
6
sync_binlog            = 1          # 每次提交都刷盘，不丢已提交事务
7
innodb_flush_log_at_trx_commit = 1  # 双 1 配置，崩溃不丢数据
8
expire_logs_days       = 7          # 或用 binlog_expire_logs_seconds

1
-- 主库执行，最小权限即可
2
CREATE USER 'repl'@'10.0.0.%' IDENTIFIED BY 'StrongPassw0rd!';
3
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'10.0.0.%';
4
FLUSH PRIVILEGES;

1
-- 主库：记录当前 binlog 位点（传统方式）
2
SHOW MASTER STATUS;
3
-- +------------------+----------+--------------+------------------+
4
-- | File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
5
-- +------------------+----------+--------------+------------------+
6
-- | mysql-bin.000003 |     1571 |              |                  |
7
-- +------------------+----------+--------------+------------------+

1
[mysqld]
2
server_id        = 2
3
relay_log        = relay-bin
4
read_only        = ON      # 普通账号只读（super 与复制线程不受限）
5
super_read_only  = ON      # 连 super 也禁写，防止误操作
6
log_replica_updates = ON   # 双主级联时必须开，保证 binlog 连续

1
-- 从库：8.0 起 CHANGE MASTER TO 已更名为 CHANGE REPLICATION SOURCE TO
2
CHANGE REPLICATION SOURCE TO
3
  SOURCE_HOST     = '10.0.0.11',
4
  SOURCE_PORT     = 3306,
5
  SOURCE_USER     = 'repl',
6
  SOURCE_PASSWORD = 'StrongPassw0rd!',
7
  SOURCE_LOG_FILE = 'mysql-bin.000003',
8
  SOURCE_LOG_POS  = 1571;
9

10
START REPLICA;
11
SHOW REPLICA STATUS\G

GTID 方式#

binlog 位点复制的痛点是位点错一下就全错：首次同步、切换、重建从库、级联拓扑变更时都要人工找 File + Position。

GTID（Global Transaction Identifier，全局事务ID）给每个已提交事务发一个全局唯一编号，格式为 source_uuid:transaction_id，例如 3f2b1c8e-...-9a01:1-100。

• source_uuid：标识事务最初提交的源服务器。通常是 MySQL 实例唯一的 server_uuid，在实例首次启动时生成并保存。
• transaction_id：一个从 1 开始的自增序列号，代表该事务在源服务器上的提交顺序。

流程：

• 从库同步：从库连接主库，告知已执行的 GTID 集合。
• 差集计算：主库计算主库 GTID 集合和从库 GTID 的差集，推送差集事务给从库。
• 事务应用：从库接收事务并应用，同时记录GTID。

因此，从库只需知道”我执行过哪些事务”，这种机制使复制不再依赖易变的文件名和位置，简化了主从同步和故障切换操作。

1
[mysqld]
2
gtid_mode                 = ON
3
enforce_gtid_consistency  = ON
4
log_replica_updates       = ON

1
-- 从库：不再需要 File/Pos，直接自动定位
2
CHANGE REPLICATION SOURCE TO
3
  SOURCE_HOST = '10.0.0.11',
4
  SOURCE_USER = 'repl',
5
  SOURCE_PASSWORD = 'StrongPassw0rd!',
6
  SOURCE_AUTO_POSITION = 1;
7

8
START REPLICA;

1
-- 观察 GTID 复制进度
2
SELECT @@GLOBAL.gtid_executed;    -- 本机已执行
3
SELECT @@GLOBAL.gtid_purged;      -- 已清理、不再需要的历史
4
SHOW REPLICA STATUS\G             -- Retrieved / Executed / Auto_Position

1
RESET MASTER;
2
SET GLOBAL gtid_purged = '3f2b1c8e-...-9a01:1-1000';
3
CHANGE REPLICATION SOURCE TO ... SOURCE_AUTO_POSITION = 1;
4
START REPLICA;

复制中断的常见错误#

跳过事务的正确姿势（GTID 模式）：

1
STOP REPLICA;
2
SET GTID_NEXT = '3f2b1c8e-...-9a01:1001';
3
BEGIN; COMMIT;
4
SET GTID_NEXT = 'AUTOMATIC';
5
START REPLICA;

延迟测量#

Seconds_Behind_Master 的取值为”从库 SQL 线程正在重放的事件时间戳”与”从库当前时间”的差值，因此：

• 主库空闲时它必然为 0，即使从库已经落后了几小时没重放（IO 线程断了它反而变 NULL）。
• 主从机器时钟不同步时数值无意义。
• 粒度为整秒，小于1s的延迟均记为0。

更可靠的做法：

延迟来源#

1. 天然串行：传统复制只有一个 SQL 线程，主库并发写入会在这里排队堆积。
2. 大事务：一次性 DELETE 百万行、ALTER TABLE 重建表，重放耗时长且无法拆分。
3. DDL 与锁：从库重放时如果被长查询/长事务阻塞，整个重放链路停住。
4. 从库自身压力：从库同时扛着大量读请求，CPU、IO 被抢占。
5. 硬件与网络：binlog 传输带宽不足，或磁盘 fsync 能力弱于主库。
6. 行锁竞争：READ COMMITTED 之外的隔离级别下行锁竞争更重，重放更慢。

治理方式#

并行复制相关参数的取舍：

1
[mysqld]
2
replica_parallel_type        = LOGICAL_CLOCK
3
replica_parallel_workers     = 8     # 建议 4~16，与从库 CPU 核数相关
4
replica_preserve_commit_order = ON   # 保证提交顺序与主库一致，避免并行导致的可见性异常

延迟的兜底思路#

即使做了上述优化，异步复制在极端情况下仍会延迟，因此必须承认：延迟是”降低”而不是”消除”的。工程上的兜底是：

• 业务侧定义可接受的最大延迟（例如 1 秒），超过就降级为读主库。
• 监控告警盯住延迟，而不是等业务报错。
• 切换时校验 GTID，避免”延迟中切换”造成部分事务永丢（详见第二篇）。

垂直拆分#

按业务域把不同表拆到不同库（用户库、订单库、商品库）。

• 优点：业务边界清晰、单库压力下降、后续可独立扩容。
• 代价：跨库 JOIN 消失，需要改为多次查询或数据冗余。

水平拆分#

把同一张表按规则拆成多张（同库多表或分到多库）。

选定分片键的原则：高频查询条件里必须带分片键，否则就是全分片扫描。

中间件选型#

引入分库分表后的新问题#

• 分布式事务：跨分片写入无法用本地事务，要么 2PC/TCC，要么用”本地消息表 + 补偿”走向最终一致。
• 全局唯一 ID：AUTO_INCREMENT 不再全局唯一，需要雪花算法、号段模式或 Redis INCR。
• 跨分片分页与排序：LIMIT 100000, 10 变成每个分片取 100010 行再归并，性能极差，应改为”按游标/上次最大 ID 翻页”。
• 扩容迁移：分片数翻倍时的数据搬迁与双写切换，是分库分表最痛的一步，最好在设计时就把分片数放大（例如分成 1024 个逻辑分片再映射到物理库）。
• 运维复杂度：备份、DDL、监控、故障排查都要按”分片 × 副本”维度放大。