什么是主从复制（Master-Slave Replication）？

Viewed 1
数据库 主从复制 扩展

📌 主要作用
🔹 主从复制的基本原理
🔹 MySQL 主从复制实施步骤
🔹 进阶优化
🔹 总结
🚀 推荐方案

Taimu1
1 Answers

🔹 什么是主从复制（Master-Slave Replication）？

主从复制（Master-Slave Replication） 是数据库的一种分布式架构，主库（Master） 负责 读写操作，而 从库（Slave） 仅进行 只读操作，并通过 复制主库的数据 保持同步。

📌 主要作用

  • 提高读性能：读请求可分发到多个从库，减少主库压力。
  • 数据冗余与备份：从库可以作为灾备方案，提高数据可靠性。
  • 支持分布式架构：支持分库分表，可扩展到大规模集群。

🔹 主从复制的基本原理

1️⃣ 主库（Master）工作方式

  • 处理所有 写入（INSERT、UPDATE、DELETE） 操作。
  • 将 所有数据变更 记录到 二进制日志（Binlog） 中。

2️⃣ 从库（Slave）同步方式

  • 读取主库的 Binlog 并存储到 中继日志（Relay Log） 中。
  • SQL 线程 解析 Relay Log 并在从库执行相应的 SQL 语句，使数据与主库保持一致。

🔄 数据同步流程

  1. 主库 记录 Binlog。
  2. 从库 通过 I/O 线程拉取 Binlog 并写入 Relay Log。
  3. SQL 线程 解析 Relay Log 并执行 SQL 更新数据。

🔹 MySQL 主从复制实施步骤

📌 环境准备

假设：

  • 主库 IP：192.168.1.100
  • 从库 IP：192.168.1.101
  • MySQL 版本：8.0

1️⃣ 配置主库（Master）

① 修改 MySQL 配置文件

在主库 /etc/mysql/my.cnf 或 /etc/my.cnf 添加以下内容：

[mysqld]
server-id=1  # 主库ID，必须唯一
log_bin=mysql-bin  # 启用 Binlog
binlog_format=ROW  # 推荐使用 ROW 级别

重启 MySQL

systemctl restart mysql

② 创建用于复制的用户

在主库 MySQL 终端执行：

CREATE USER 'repl'@'192.168.1.101' IDENTIFIED BY 'repl_password';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.1.101';
FLUSH PRIVILEGES;

③ 获取当前 Binlog 状态

SHOW MASTER STATUS;

🔹 记下 File 和 Position 值，例如：

+------------------+----------+
| File            | Position |
+------------------+----------+
| mysql-bin.000001 |  154     |
+------------------+----------+

2️⃣ 配置从库（Slave）

① 修改 MySQL 配置

在从库 /etc/mysql/my.cnf 或 /etc/my.cnf 添加：

[mysqld]
server-id=2  # 从库ID，需唯一
relay_log=mysql-relay-bin  # 中继日志
read_only=1  # 只读模式（可选）

重启 MySQL

systemctl restart mysql

② 连接主库

CHANGE MASTER TO
  MASTER_HOST='192.168.1.100',
  MASTER_USER='repl',
  MASTER_PASSWORD='repl_password',
  MASTER_LOG_FILE='mysql-bin.000001',  -- 之前记录的 File 值
  MASTER_LOG_POS=154;  -- 之前记录的 Position 值

启动复制

START SLAVE;

检查复制状态

SHOW SLAVE STATUS\G;

🔹 关键字段：

  • Slave_IO_Running: Yes
  • Slave_SQL_Running: Yes
    如果 Yes，说明主从复制 正常运行。

🔹 进阶优化

1️⃣ 读写分离

可以使用 Nginx + ProxySQL 或 MySQL Router 进行 读写分离：

  • 所有写操作 发送到 主库。
  • 所有读操作 发送到 从库。

2️⃣ 半同步复制（Semi-Synchronous Replication）

默认情况下，主库提交事务后不会等待从库确认，这可能导致数据丢失。
半同步复制 确保主库至少等待一个从库确认数据接收后再提交：

INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';

SET GLOBAL rpl_semi_sync_master_enabled = 1;
SET GLOBAL rpl_semi_sync_slave_enabled = 1;

3️⃣ GTID（全局事务 ID）复制

相比传统 Binlog 复制，GTID（Global Transaction ID） 复制更灵活，无需手动指定 File 和 Position：

[mysqld]
gtid_mode=ON
enforce-gtid-consistency=ON

在从库执行：

CHANGE MASTER TO MASTER_AUTO_POSITION=1;

🔹 总结

方式 适用场景 优势 可能问题
普通主从复制 小型系统 简单易用 Binlog 可能丢失
GTID 复制 复杂系统 迁移方便 兼容性要求高
半同步复制 高可靠性 防止数据丢失 可能降低性能
读写分离 高并发读请求 提高吞吐量 需要额外代理

🚀 推荐方案：

  • 小规模部署：普通 Binlog 复制 + 读写分离。
  • 高可用方案：GTID 复制 + 半同步复制。

💡 主从复制是高可用架构的基础，但要结合 负载均衡、分库分表 才能构建真正可扩展的分布式数据库！ 🚀

Taimu1
Related Questions