MySQL的主从复制

MySQL 主从复制详解

MySQL 的主从复制是一种用来实现数据同步的机制，可以将一个 MySQL 实例的数据同步到一个或多个从库（Slave）实例中。它广泛应用于数据备份、高可用架构、读写分离、负载均衡等场景。

---

1. 主从复制的基本概念

• 主库（Master）：

  • 负责接收客户端的所有写操作（INSERT、UPDATE、DELETE 等）。
  • 记录所有变更到 Binlog（Binary Log） 中。

• 从库（Slave）：

  • 从主库获取 Binlog 并重放（Replay），以实现数据同步。
  • 通常只接受读请求（只读模式），提高系统的读性能。

• 复制类型：

  • 异步复制（Asynchronous Replication）：
    • 主库在执行事务后不等待从库完成同步，即认为事务已提交。
    • 从库的延迟可能较大，但对主库性能影响较小。
  • 半同步复制（Semi-Synchronous Replication）：
    • 主库在事务提交时会等待至少一个从库确认接收到 Binlog。
    • 提高数据可靠性，但增加写操作延迟。
  • 全同步复制（Synchronous Replication）：
    • 主库只有在所有从库都完成同步后才会提交事务。
    • 几乎不常用，因为性能开销巨大。

---

2. 主从复制的工作流程

步骤 1：主库记录变更

• 主库执行写操作时，将变更记录写入 Binlog。

步骤 2：从库拉取 Binlog

• 从库通过 I/O 线程 从主库读取 Binlog，并存储到本地的 Relay Log（中继日志）。

步骤 3：从库重放 Relay Log

• 从库的 SQL 线程 解析并执行 Relay Log 中的语句，将数据同步到从库。

---

3. 主从复制的核心组件

1. Binlog（主库的二进制日志）

• 主库记录所有数据变更操作（基于语句或行的变更记录）。
• 通过 Binlog，主库能够告知从库需要同步的内容。

2. Relay Log（从库的中继日志）

• 从库 I/O 线程从主库拉取的 Binlog 被存储在本地。
• Relay Log 是从库在执行同步操作时的临时数据文件。

3. 线程

• 主库的 Binlog Dump 线程：
  • 负责向从库传输 Binlog 数据。
• 从库的 I/O 线程：
  • 连接主库并拉取 Binlog 数据，写入 Relay Log。
• 从库的 SQL 线程：
  • 读取 Relay Log 并重放，完成数据同步。

---

4. 主从复制的配置步骤

步骤 1：配置主库

1. 开启 Binlog 日志： 在主库的 my.cnf 文件中添加以下内容：

   ini

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

   • log-bin：开启 Binlog。
   • server-id：每个 MySQL 实例的唯一标识。

2. 创建复制用户：

   sql

   复制代码

   CREATE USER 'repl_user'@'%' IDENTIFIED BY 'password'; GRANT REPLICATION SLAVE ON *.* TO 'repl_user'@'%'; FLUSH PRIVILEGES;

3. 获取主库状态：

   sql

   SHOW MASTER STATUS;

   输出示例：

   diff

   +------------------+----------+--------------+------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB| +------------------+----------+--------------+------------------+ | mysql-bin.000001 | 120 | | | +------------------+----------+--------------+------------------+

   记录 File 和 Position 值。

步骤 2：配置从库

1. 设置从库的唯一 ID： 在从库的 my.cnf 文件中添加：

   ini

   复制代码

   [mysqld] server-id=2 relay-log=relay-bin log-bin=mysql-bin

2. 连接主库并开始复制： 登录从库，执行以下命令：

   sql

   CHANGE MASTER TO MASTER_HOST='主库IP', MASTER_USER='repl_user', MASTER_PASSWORD='password', MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=120;

3. 启动复制：

   sql

   START SLAVE; SHOW SLAVE STATUS\G;

步骤 3：验证主从复制

• 在主库执行写操作后，从库中检查数据是否同步。

---

5. 主从复制的模式

1. 单主单从

• 一个主库对应一个从库。

2. 单主多从

• 一个主库对应多个从库，常用于读写分离或高可用。

3. 多主单从

• 多个主库的数据同步到一个从库（通过多源复制）。

4. 主主复制（双主模式）

• 两个主库互为从库，常用于容灾或高可用。

---

6. 主从复制的优缺点

优点

1. 提高数据可靠性：主从库同步备份，避免单点故障。
2. 支持读写分离：主库负责写操作，从库负责读操作。
3. 易于扩展：通过添加从库，扩展系统读性能。

缺点

1. 延迟问题：从库的同步可能存在延迟。
2. 数据一致性风险：主库故障或从库延迟可能导致数据不一致。
3. 管理复杂性：多从库或复杂拓扑需要额外的监控和维护。

---

7. 主从复制的优化

1. 优化网络传输：

   • 使用压缩传输 Binlog 减少带宽占用。

2. 减少从库延迟：

   • 增加从库 SQL 线程数量（仅适用于并行复制）。
   • 优化从库硬件性能。

3. 监控复制状态：

   • 定期检查 SHOW SLAVE STATUS，确保 Seconds_Behind_Master 不超出预期范围。

---

8. 主从复制的实际场景

• 高可用：

  • 主库故障时可以快速切换到从库，确保业务连续性。

• 读写分离：

  • 主库处理写请求，从库处理读请求，提升系统性能。

• 数据备份：

  • 在从库上执行备份操作，避免影响主库性能。

• 容灾恢复：

  • 在异地部署从库，保证灾难恢复能力。