MySQL数据库笔记—

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

在这里插入图片描述

文章目录

简介
核心组件
主从复制的原理
作用
主从复制的线程模型
主从复制的模式
形式
复制的方式
设计复制机制
主从复制的配置步骤
优化和改进
总结

历史文章

简介

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

核心组件

主库（Master）：
- 负责记录所有数据变更操作到 Binary Log 中。
- 通过网络将 Binary Log 提供给从库。
从库（Slave）：
- 负责从主库获取 Binary Log，并通过中继日志（Relay Log）将其重放在本地，最终实现与主库的数据同步。
二进制日志（Binary Log）：
- 主库记录所有数据变更的日志文件。
- 包含数据变更的具体操作（语句或行数据）。
中继日志（Relay Log）：
- 从库将主库发送的 Binary Log 存储为中继日志。
- 从库 SQL 线程根据中继日志执行对应的操作。

主从复制的原理

基于二进制日志（Binary Log）：
- MySQL 主从复制依赖主库的二进制日志（Binary Log）。主库将所有数据变更操作（如 INSERT、UPDATE、DELETE）记录到 Binary Log 中。
复制过程：
- 日志同步：从库向主库请求二进制日志，从主库读取日志文件中最近的更新操作。
- 日志重放：从库接收到二进制日志后，存储到自己的中继日志（Relay Log），并重放这些操作以保持与主库数据一致。
主从独立运行：
- 主库和从库的操作相互独立，从库的备份操作不会干扰主库，主库可以继续处理写操作。

作用

数据冗余，宕机保护：
- 数据冗余：在从库上保存主库的数据副本，防止数据丢失。
- 宕机保护：主库宕机时，可以快速启用从库，保障业务连续性。
读写分离，性能提升：
- 支持读写分离：主库处理写操作，从库处理读操作。
- 流量分担：多台从库分担主库的查询压力，提升系统性能。
扩展性：
- 易于扩展：通过增加从库节点应对流量增长。
- 平滑升级：可以优先升级从库，验证新版本的稳定性后再升级主库。
负载均衡：
- 多从库分担读流量，实现负载均衡，提升并发能力。

主从复制的线程模型

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

主库线程：
- Binlog Dump 线程：主库为每个从库分配一个 Binlog Dump 线程，将 Binary Log 发送到从库。
从库线程：
- I/O 线程：从库从主库拉取 Binary Log 并保存为 Relay Log。
- SQL 线程：从库读取 Relay Log，并将日志中的操作在从库中重放。

主从复制的模式

异步复制（Asynchronous Replication）：
- 主库提交事务后立即返回客户端，从库异步同步数据。延迟低，但存在数据丢失风险。
- 默认复制模式。
- 主库不等待从库的确认即完成事务提交。
- 延迟低，但如果主库崩溃，可能会导致从库数据不一致。
半同步复制（Semi-Synchronous Replication）：
- 主库在事务提交后会等待至少一个从库确认接收 Binary Log。，才返回客户端。
- 特点：
  - 提高数据安全性。
  - 延迟较低，但仍比异步复制稍高。
  - 从 MySQL 5.5 开始支持（需要插件）。
全同步复制（Synchronous Replication）：
- 主库必须等待从库同步完成后，才向客户端返回写入成功。延迟较高，但数据一致性强。
- 所有从库都确认接收到 Binary Log 后，主库才提交事务。
- 数据一致性最高，但性能损耗较大。

形式

一主一从：
- 简单高效的主从架构，适用于小型系统或简单业务场景。
- 特点：
  - 支持基本的高可用性。
  - 从库可用于查询、备份等，主库专注写操作。
一主多从：
- 主库将数据同步到多个从库，适合读多写少的场景。
- 特点：
  - 提升并发能力，实现负载均衡。
  - 每个从库可以分配特定任务，如查询或备份。
多主一从：
- 多个主库的数据同步到一台从库。
- 特点：
  - 用于整合不同业务线的数据到一个中心数据库。
  - 对从库的存储性能要求较高。
- 补充：由于主库间没有自动同步，需确保主库之间的写操作不会冲突。
双主复制：
- 两台服务器互为主从，支持双机热备。
- 特点：
  - 任一主库宕机后，另一主库可继续提供服务。
  - 双向同步，数据一致性需谨慎处理，防止循环复制或冲突。
- 适用场景：
  - 高可用场景，如业务不允许服务中断。
级联复制：
- 一些从库直接从主库同步数据，其他从库通过这些从库同步。
- 特点：
  - 缓解主库压力。
  - 降低主库对网络带宽的依赖。
- 适用场景：
  - 大规模分布式系统。

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

复制的方式

基于语句的逻辑复制（Statement-Based Replication, SBR）：
- 特点：
  - 二进制日志记录 SQL 语句，操作逻辑在从库重放。
  - 日志体积小，传输效率高。
- 缺点：
  - 语句重放依赖于上下文环境，可能导致主从数据不一致（如 NOW() 或 UUID() 生成的值不同）。基于语句更新依赖于其它因素，比如插入数据时利用了时间戳。因此在开发当中，我们应该尽量将业务逻辑逻辑放在代码层（创建时间，不应该是mysql的创建时间），而不应该放在 MySQL 中，不易拓展。
  - 多表操作或复杂查询时，性能可能不理想。
- 适用场景：
  - 操作简单且可预测的业务场景。
  - 设表里有一百万条数据，一条sql更新了所有表，基于语句的复制仅需要发送一条sql，而基于行的复制需要发送一百万条更新记录
基于行的物理复制（Row-Based Replication, RBR）：
- 特点：
  - 二进制日志记录每一行的数据变更，直接同步数据。
  - 精确可靠，不受上下文影响。
- 缺点：
  - 日志体积大，占用更多存储和带宽。
- 适用场景：
  - 数据更新频繁，且对数据一致性要求较高的场景。
  - 例如一条更新用户总积分的语句，需要统计用户的所有积分再写入用户表。如果是基于语句复制的话，从库需要再一次统计用户的积分，而基于行复制就直接更新记录，无需再统计用户积分。
混合复制（Mixed Replication, MIXED）：
- 特点：
  - 默认使用语句复制，当遇到复杂场景（如函数、触发器）时切换为行复制。
  - 动态选择复制方式，兼具两种方式的优点。
- 缺点：
  - 复杂度较高，需要额外的资源判断何时切换。
- 适用场景：
  - 通用场景，特别是既有简单语句，又有复杂操作的业务。

设计复制机制

在这里插入图片描述

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

主库写入 Binary Log：
- 任何修改数据的操作（如 INSERT、UPDATE、DELETE）都会记录到主库的 Binary Log。
从库 I/O 线程拉取 Binary Log：
- 从库的 I/O 线程向主库请求 Binary Log。
- 主库会生成一个 log dump 线程，将 Binary Log 发送给从库。
从库存储中继日志：
- 从库将主库的 Binary Log 存储为中继日志（Relay Log）。
从库 SQL 线程执行 Relay Log：
- 从库的 SQL 线程读取 Relay Log，将日志中的操作在从库重放，完成数据同步。
后续新数据到达主库：
- 主库执行写操作后，事务提交时会将修改记录写入 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）。
  - 重新连接后，从库会从上次中断的位置继续同步，避免重复同步或数据丢失。

主从复制的配置步骤

配置主库（Master）：
- 启用 Binary Log：
```
[mysqld]
log-bin=mysql-bin
server-id=1
```
- 重启 MySQL 服务。

配置从库（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;
```

验证主从复制状态：
- 在从库执行：
```
SHOW SLAVE STATUS\G;
```

优化和改进

使用半同步复制：
- 提高数据一致性，降低数据丢失风险。
多线程复制：
- MySQL 5.6 开始支持多线程复制（Parallel Replication），从库的 SQL 线程可以并行处理不同表的数据，提升同步效率。
监控和告警：
- 定期检查主从同步状态（SHOW SLAVE STATUS）。
- 设置告警系统监控复制延迟、复制状态。
主从自动切换：
- 使用高可用工具（如 MHA、Keepalived、Orchestrator）实现主从自动切换，避免主库故障时人工干预。