MySQL数据库笔记——主从复制

大家好，这里是Good Note，关注 公主号：Goodnote，本文详细介绍 MySQL的主从复制，从原理到配置再到同步过程。

简介

MySQL 主从复制（Replication）是一种数据分布和同步的技术，通过将主库（Master）的数据和操作复制到一个或多个从库（Slave），实现数据的同步和备份。它常用于读写分离、数据容灾、数据分布等场景。

核心组件

1. 主库（Master）：

   • 负责记录所有数据变更操作到 Binary Log 中。
   • 通过网络将 Binary Log 提供给从库。

2. 从库（Slave）：

   • 负责从主库获取 Binary Log，并通过中继日志（Relay Log）将其重放在本地，最终实现与主库的数据同步。

3. 二进制日志（Binary Log）：

   • 主库记录所有数据变更的日志文件。
   • 包含数据变更的具体操作（语句或行数据）。

4. 中继日志（Relay Log）：

   • 从库将主库发送的 Binary Log 存储为中继日志。
   • 从库 SQL 线程根据中继日志执行对应的操作。

---

主从复制的原理

1. 基于二进制日志（Binary Log）：

   • MySQL 主从复制依赖主库的二进制日志（Binary Log）。主库将所有数据变更操作（如 INSERT、UPDATE、DELETE）记录到 Binary Log 中。

2. 复制过程：

   • 日志同步：从库向主库请求二进制日志，从主库读取日志文件中最近的更新操作。
   • 日志重放：从库接收到二进制日志后，存储到自己的中继日志（Relay Log），并重放这些操作以保持与主库数据一致。

3. 主从独立运行：

   • 主库和从库的操作相互独立，从库的备份操作不会干扰主库，主库可以继续处理写操作。

---

作用

1. 数据冗余，宕机保护：

   • 数据冗余：在从库上保存主库的数据副本，防止数据丢失。
   • 宕机保护：主库宕机时，可以快速启用从库，保障业务连续性。

2. 读写分离，性能提升：

   • 支持读写分离：主库处理写操作，从库处理读操作。
   • 流量分担：多台从库分担主库的查询压力，提升系统性能。

3. 扩展性：

   • 易于扩展：通过增加从库节点应对流量增长。
   • 平滑升级：可以优先升级从库，验证新版本的稳定性后再升级主库。

4. 负载均衡：

   • 多从库分担读流量，实现负载均衡，提升并发能力。

---

主从复制的线程模型

主从复制主要涉及以下线程：

1. 主库线程：

   • Binlog Dump 线程：主库为每个从库分配一个 Binlog Dump 线程，将 Binary Log 发送到从库。

2. 从库线程：

   • I/O 线程：从库从主库拉取 Binary Log 并保存为 Relay Log。
   • SQL 线程：从库读取 Relay Log，并将日志中的操作在从库中重放。

---

主从复制的模式

1. 异步复制（Asynchronous Replication）：

   • 主库提交事务后立即返回客户端，从库异步同步数据。延迟低，但存在数据丢失风险。
   • 默认复制模式。
   • 主库不等待从库的确认即完成事务提交。
   • 延迟低，但如果主库崩溃，可能会导致从库数据不一致。

2. 半同步复制（Semi-Synchronous Replication）：

   • 主库在事务提交后会等待至少一个从库确认接收 Binary Log。，才返回客户端。
   • 特点：
     • 提高数据安全性。
     • 延迟较低，但仍比异步复制稍高。
     • 从 MySQL 5.5 开始支持（需要插件）。

3. 全同步复制（Synchronous Replication）：

   • 主库必须等待从库同步完成后，才向客户端返回写入成功。延迟较高，但数据一致性强。
   • 所有从库都确认接收到 Binary Log 后，主库才提交事务。
   • 数据一致性最高，但性能损耗较大。

---

形式

1. 一主一从：

   • 简单高效的主从架构，适用于小型系统或简单业务场景。
   • 特点：
     • 支持基本的高可用性。
     • 从库可用于查询、备份等，主库专注写操作。

2. 一主多从：

   • 主库将数据同步到多个从库，适合读多写少的场景。
   • 特点：
     • 提升并发能力，实现负载均衡。
     • 每个从库可以分配特定任务，如查询或备份。

3. 多主一从：

   • 多个主库的数据同步到一台从库。
   • 特点：
     • 用于整合不同业务线的数据到一个中心数据库。
     • 对从库的存储性能要求较高。
   • 补充：由于主库间没有自动同步，需确保主库之间的写操作不会冲突。

4. 双主复制：

   • 两台服务器互为主从，支持双机热备。
   • 特点：
     • 任一主库宕机后，另一主库可继续提供服务。
     • 双向同步，数据一致性需谨慎处理，防止循环复制或冲突。
   • 适用场景：
     • 高可用场景，如业务不允许服务中断。

5. 级联复制：

   • 一些从库直接从主库同步数据，其他从库通过这些从库同步。
   • 特点：
     • 缓解主库压力。
     • 降低主库对网络带宽的依赖。
   • 适用场景：
     • 大规模分布式系统。

一主一从和一主多从是我们现在见的最多的主从架构，使用起来简单有效，不仅可以实现高可用，而且还能读写分离，进而提升集群的并发能力。

---

复制的方式

1. 基于语句的逻辑复制（Statement-Based Replication, SBR）：

   • 特点：
     • 二进制日志记录 SQL 语句，操作逻辑在从库重放。
     • 日志体积小，传输效率高。
   • 缺点：
     • 语句重放依赖于上下文环境，可能导致主从数据不一致（如 NOW() 或 UUID() 生成的值不同）。基于语句更新依赖于其它因素，比如插入数据时利用了时间戳。因此在开发当中，我们应该尽量将业务逻辑逻辑放在代码层（创建时间，不应该是mysql的创建时间），而不应该放在 MySQL 中，不易拓展。
     • 多表操作或复杂查询时，性能可能不理想。
   • 适用场景：
     • 操作简单且可预测的业务场景。
     • 设表里有一百万条数据，一条sql更新了所有表，基于语句的复制仅需要发送一条sql，而基于行的复制需要发送一百万条更新记录

2. 基于行的物理复制（Row-Based Replication, RBR）：

   • 特点：
     • 二进制日志记录每一行的数据变更，直接同步数据。
     • 精确可靠，不受上下文影响。
   • 缺点：
     • 日志体积大，占用更多存储和带宽。
   • 适用场景：
     • 数据更新频繁，且对数据一致性要求较高的场景。
     • 例如一条更新用户总积分的语句，需要统计用户的所有积分再写入用户表。如果是基于语句复制的话，从库需要再一次统计用户的积分，而基于行复制就直接更新记录，无需再统计用户积分。

3. 混合复制（Mixed Replication, MIXED）：

   • 特点：
     • 默认使用语句复制，当遇到复杂场景（如函数、触发器）时切换为行复制。
     • 动态选择复制方式，兼具两种方式的优点。
   • 缺点：
     • 复杂度较高，需要额外的资源判断何时切换。
   • 适用场景：
     • 通用场景，特别是既有简单语句，又有复杂操作的业务。

---

设计复制机制

以下是主从复制的详细执行流程：

1. 主库写入 Binary Log：

   • 任何修改数据的操作（如 INSERT、UPDATE、DELETE）都会记录到主库的 Binary Log。

2. 从库 I/O 线程拉取 Binary Log：

   • 从库的 I/O 线程向主库请求 Binary Log。
   • 主库会生成一个 log dump 线程，将 Binary Log 发送给从库。

3. 从库存储中继日志：

   • 从库将主库的 Binary Log 存储为中继日志（Relay Log）。

4. 从库 SQL 线程执行 Relay Log：

   • 从库的 SQL 线程读取 Relay Log，将日志中的操作在从库重放，完成数据同步。

5. 后续新数据到达主库：

   • 主库执行写操作后，事务提交时会将修改记录写入 Binary Log。主库的 Log Dump 线程实时检测 Binary Log 更新，并通过长连接主动推送到从库。

注意：

• 同步过程是实时推送日志。

• 第一次连接：从库的 I/O 线程主动向主库发起请求，同步历史数据。

• 后续新数据到达主库：主库主动推送新数据实时同步到从库。

• 长连接保持：从库的 I/O 线程与主库的 Log Dump 线程建立长连接。从库无需反复发起请求去检查主库是否有新数据，而是等待主库通过长连接推送新的日志。

  • 长连接保持的关键在于：
    1. TCP 持久连接：从库的 I/O 线程与主库的 Log Dump 线程通过 TCP 连接持续通信。
    2. 复制心跳机制：即使主库没有新数据生成，也会定期发送心跳包，保持连接活动。
    3. 自动重连机制：当连接意外中断时，从库的 I/O 线程会自动尝试重新连接主库。
  • MySQL 设计了完整的断点续传和自动重连机制，确保长连接断开后可以尽快恢复。
    • 从库记录了上次成功同步的日志位置（MASTER_LOG_FILE 和 MASTER_LOG_POS）。
    • 重新连接后，从库会从上次中断的位置继续同步，避免重复同步或数据丢失。

---

主从复制的配置步骤

1. 配置主库（Master）：

   • 启用 Binary Log：

     [mysqld]
     log-bin=mysql-bin
     server-id=1
     

   • 重启 MySQL 服务。

2. 配置从库（Slave）：

   • 设置从库的 server-id：

     [mysqld]
     server-id=2
     

   • 连接主库：

     CHANGE MASTER TO
     MASTER_HOST='主库IP',
     MASTER_USER='复制用户',
     MASTER_PASSWORD='密码',
     MASTER_LOG_FILE='mysql-bin.000001',
     MASTER_LOG_POS=120;
     

   • 启动从库复制：

     START SLAVE;
     

3. 验证主从复制状态：

   • 在从库执行：

     SHOW SLAVE STATUS\G;
     

---

优化和改进

1. 使用半同步复制：

   • 提高数据一致性，降低数据丢失风险。

2. 多线程复制：

   • MySQL 5.6 开始支持多线程复制（Parallel Replication），从库的 SQL 线程可以并行处理不同表的数据，提升同步效率。

3. 监控和告警：

   • 定期检查主从同步状态（SHOW SLAVE STATUS）。
   • 设置告警系统监控复制延迟、复制状态。

4. 主从自动切换：

   • 使用高可用工具（如 MHA、Keepalived、Orchestrator）实现主从自动切换，避免主库故障时人工干预。

---

总结

MySQL 主从复制是实现高可用性和负载均衡的重要机制。通过合理的复制模式配置（如半同步、并行复制）以及结合监控和自动化工具，可以显著提高数据库系统的性能和可靠性。同时，了解主从复制的缺点（如数据延迟和单点故障）并采取适当的优化措施，可以进一步提升系统的稳定性。

历史文章

1. MySQL数据库笔记——数据库三范式
2. MySQL数据库笔记——存储引擎（InnoDB、MyISAM、MEMORY、ARCHIVE）
3. MySQL数据库笔记——常见的几种锁分类
4. MySQL数据库笔记——索引介绍
5. MySQL数据库笔记——事务介绍
6. MySQL数据库笔记——索引结构之B+树
7. MySQL数据库笔记——索引潜规则（回表查询、索引覆盖、索引下推）
8. MySQL数据库笔记——索引潜规则（最左前缀原则）
9. MySQL数据库笔记——常见慢查询优化方式
10. MySQL数据库笔记——日志介绍
11. MySQL数据库笔记——多版本并发控制MVCC