当前位置：首页 > news >正文

[MySQL实战] 主从复制(Replication)搭建教程：实现读写分离与高可用基础

news 2025/5/17 6:13:02

更多服务器知识，尽在hostol.com

当你的网站或应用程序发展到一定规模，数据库往往会成为首当其冲的性能瓶颈。大量的读取请求、写入操作、以及对数据高可用性的要求，都可能让单台数据库服务器不堪重负。这时候，MySQL 或 MariaDB 的**主从复制 (Master-Slave Replication)** 技术就成了我们手中一把强大的“解压利器”和“定心丸”。

简单来说，主从复制就是让一台服务器（我们称之为 **Master - 主库**）上的数据更改，能够自动、异步地被一台或多台其他服务器（我们称之为 **Slave - 从库**）复制过去。主库通常负责处理所有的写入操作（INSERT, UPDATE, DELETE），而从库则可以承担大部分的读取操作（SELECT），从而实现**读写分离**，大大提升数据库的并发处理能力和整体性能。同时，从库作为主库数据的一个近乎实时的副本，也为**数据备份**和**基本的高可用性**（当主库故障时，可以将从库提升为新的主库）提供了可能。

想象一下，Master 就像是一个辛勤写作的“原稿作者”，他写下的每一个字（数据更改）都会被忠实地记录下来。而 Slave 们则像是一群努力的“抄写员”，它们时刻关注着“原稿作者”的新动向，一旦有更新，就立刻把新内容抄写到自己的副本上。这样，当有大量“读者”（应用程序）想看内容时，就可以直接去各个“抄写员”那里看副本，而不用都挤到“原稿作者”那里去，让他能专心创作新的内容。

这篇教程，我们就来一起动手，在两台 Linux 服务器上（以 Ubuntu 22.04 和 MySQL 为例）搭建一个基础的、基于二进制日志 (Binary Log) 位置的单向主从复制环境。过程会比较详细，请准备好你的耐心和细心！

主从复制的“神来之笔”：它能为我们解决什么问题？

在开始“施工”之前，我们先明确一下，费老大劲儿搞这个主从复制，到底能给我们带来哪些实实在在的好处呢？

读写分离，提升性能与并发能力 (Read/Write Splitting for Performance & Scalability): 这是主从复制最主要的应用场景。对于读多写少的应用（比如大部分网站、内容发布系统、论坛等），可以将大量的读请求导向从库，而主库只负责处理写请求。这样不仅分担了主库的压力，让写操作更顺畅，也使得整个数据库集群能够应对更高的并发访问量。你的应用就像有了多个“只读服务窗口”，大大提升了服务效率。
数据冗余与备份便利 (Data Redundancy & Backup Convenience): 从库是主库数据的一个（或多个）副本。这意味着即使主库的硬盘突然损坏（当然，你还是应该有其他备份措施！），从库上仍然保留着大部分数据。更重要的是，你可以在从库上进行数据备份操作（比如使用 mysqldump），而不会对主库的正常业务造成锁定或性能影响。这就像你可以随时复印“抄写员”的稿件作为存档，而不必打扰正在奋笔疾书的“原稿作者”。
高可用性基础 (Foundation for High Availability - HA): 虽然本教程搭建的基础主从复制本身并不能实现自动故障转移，但它是构建更高级别高可用方案（如 MHA, Percona XtraDB Cluster, Galera Cluster，或者手动/脚本化故障切换）的基石。当主库发生故障时，理论上可以将一台数据最新的从库提升为新的主库，从而在一定程度上缩短服务中断时间。
数据分析与报表服务器 (Data Analysis/Reporting Offloading): 如果你需要运行一些非常消耗资源的、长时间的分析查询或生成复杂的报表，直接在主库上操作可能会严重影响线上业务。有了从库，你就可以把这些“重活儿”都交给从库去处理，让主库轻装上阵。

看到了吧？主从复制的好处还是相当诱人的，特别是对于有一定规模或对性能/可用性有追求的应用来说。

准备工作：在“克隆”之前，你需要哪些“基因”？

在开始我们的“数据库克隆计划”之前，请确保你的“实验室”已经准备就绪：

至少两台 MySQL/MariaDB 服务器实例： 一台作为 Master（主库），一台作为 Slave（从库）。它们可以是两台独立的物理服务器、VPS 或云服务器。为了简单起见，本教程假设它们位于可以相互访问的网络中（比如同一内网，或者公网但防火墙已正确配置）。理论上也可以在同一台机器上用不同端口运行两个实例来测试，但实际意义不大，我们这里假设是两台独立的服务器。
操作系统： 本教程以 **Ubuntu 22.04 LTS** 为例，并使用 **MySQL**。如果你使用 CentOS/RHEL 或 MariaDB，大部分概念和配置项是相通的，但具体的包名、配置文件路径和一些命令可能会略有差异。
网络连通性： Master 服务器和 Slave 服务器之间必须能够通过网络相互访问 MySQL 的服务端口（默认为 TCP 3306）。你需要确保它们之间的防火墙（包括服务器自身的 ufw/firewalld 以及云平台的安全组）已经开放了这个端口的互相访问。
sudo 或 root 权限： 你需要在两台服务器上都拥有管理员权限，以便安装软件、修改配置文件和重启服务。
MySQL/MariaDB 已安装： 我们假设两台服务器上都已经安装了 MySQL 或 MariaDB建议 Master 和 Slave 使用大致相同的主要版本（比如都是 MySQL 8.0.x 或 MariaDB 10.6.x），以减少潜在的兼容性问题。
初始数据同步计划（如果 Master 已有数据）： 如果你的 Master 服务器上已经存在大量数据，你需要一个方法将这些初始数据同步到 Slave 服务器。本教程将介绍使用 mysqldump 进行全量备份和恢复的方法。在进行此操作时，为了保证数据一致性，可能需要在 Master 上临时锁定表格，这可能会短暂影响写操作，建议在业务低峰期或维护窗口进行。对于全新的、还没有数据的 Master，则无需此步骤。
耐心和细心： 主从复制的配置细节较多，任何一个小小的疏忽都可能导致失败。请务必仔细阅读并核对每一步操作。

都准备好了吗？让我们开始给我们的“原稿作者”（Master）和“抄写员”（Slave）分配任务吧！

第一步：配置 Master 服务器 – “原稿”的准备与“授权信”

首先，我们需要在 Master 服务器上做一些配置，告诉它：“嘿，你要开始记录你所有的‘创作’（数据更改）了，并且要允许特定的‘抄写员’来读取这些记录。”

1.1. 修改 Master 的 MySQL/MariaDB 配置文件 (my.cnf 或相关 .cnf 文件)： 你需要编辑 Master 服务器上的 MySQL/MariaDB 主配置文件。这个文件的路径可能因系统和安装方式而异，常见的位置有：
- /etc/mysql/my.cnf
- /etc/my.cnf
- /etc/mysql/mysql.conf.d/mysqld.cnf (Ubuntu/Debian 上 MySQL 8.0 的常见路径)
- /etc/mysql/mariadb.conf.d/50-server.cnf (Ubuntu/Debian 上 MariaDB 的常见路径)
使用你熟悉的文本编辑器打开它 (需要 sudo)： [提示：请将以下代码片段复制并粘贴到 WordPress 的“代码”区块中] # 示例，请替换为你的实际配置文件路径 sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf 在 [mysqld] (或 [mariadb]) 段落下，找到或添加以下几行关键配置： [提示：请将以下代码片段复制并粘贴到 WordPress 的“代码”区块中]

[mysqld]

# ... 其他已有配置 ... # 1. 启用二进制日志 (Binary Log) - 这是复制的基础！ # Postfix会把所有修改数据的SQL语句（或行变更）记录到这个日志里。 log_bin = /var/log/mysql/mysql-bin.log # 你可以指定其他路径，但确保MySQL用户有权写入 # 2. 设置服务器的唯一ID (Server ID) - 在复制集群中必须唯一！ # Master 通常设为 1，Slave 可以设为 2, 3, ... server_id = 1 # 3. (推荐) 设置二进制日志格式为 ROW # ROW 格式记录的是实际数据行的变更，更准确可靠，特别是对于包含触发器、存储过程或不确定性函数的复制。 # 可选项有 STATEMENT (记录SQL语句，可能不安全), MIXED (混合模式)。 binlog_format = ROW # 4. (可选) 二进制日志自动清理设置 expire_logs_days = 7 # 自动删除超过7天的旧二进制日志文件，防止占满磁盘 max_binlog_size = 100M # 单个二进制日志文件的最大大小，超过会自动切割 # 5. (重要) 确保 bind-address 不是 127.0.0.1 (除非Slave和Master在同一台机器上测试) # 如果是 127.0.0.1，Slave 将无法从网络连接到 Master。 # 通常设为服务器的内网 IP 地址，或者 0.0.0.0 (监听所有网络接口，但需配合防火墙严格控制) # bind-address = 0.0.0.0 # 或者你的服务器实际可被Slave访问的IP # ... 其他已有配置 ...

重点解释：

log_bin: 必须启用！ 这是开启二进制日志的开关，并指定日志文件的存储路径和前缀。没有它，复制无从谈起。
server_id: 必须设置，且在整个复制集群中唯一！ 它用来区分不同的服务器。
binlog_format: 推荐使用 ROW 格式，虽然日志文件可能会大一些，但能保证数据复制的准确性，避免很多因 STATEMENT 格式下不确定性函数导致的主从不一致问题。

修改并保存配置文件。

1.2. 创建一个专门用于复制的用户账户：

Slave 服务器需要一个 MySQL 用户账户来连接到 Master 并读取二进制日志。我们不应该直接使用 Master 的 root 用户，而是创建一个专用的、权限受限的复制用户。

登录到 Master 服务器的 MySQL：

[提示：请将以下代码片段复制并粘贴到 WordPress 的“代码”区块中]


sudo mysql -u root -p

然后执行以下 SQL 命令（将 'SLAVE_SERVER_IP' 替换为你 Slave 服务器的实际 IP 地址，'YourStrongPasswordForRepl' 替换为一个强大的密码）：

[提示：请将以下代码片段复制并粘贴到 WordPress 的“代码”区块中]


-- 创建复制用户，并限制它只能从指定的 Slave IP 连接
CREATE USER 'repl_user'@'SLAVE_SERVER_IP' IDENTIFIED BY 'YourStrongPasswordForRepl';-- 授予该用户 REPLICATION SLAVE 权限 (这是它读取二进制日志所需的最小权限)
GRANT REPLICATION SLAVE ON *.* TO 'repl_user'@'SLAVE_SERVER_IP';-- 刷新权限
FLUSH PRIVILEGES;-- (可选) 查看一下刚创建的用户的权限
-- SHOW GRANTS FOR 'repl_user'@'SLAVE_SERVER_IP';EXIT;

注意： 如果你有多个 Slave，或者 Slave 的 IP 地址可能会变化（不推荐），你可以将 'SLAVE_SERVER_IP' 替换为 '%' 来允许从任意主机连接，但这会降低安全性，务必确保密码足够复杂，并且在防火墙层面做了严格限制。

1.3. 重启 Master 的 MySQL/MariaDB 服务并获取主库状态：

为了让新的配置（特别是 log_bin 和 server_id）生效，你需要重启 Master 上的数据库服务：

[提示：请将以下代码片段复制并粘贴到 WordPress 的“代码”区块中]


sudo systemctl restart mysql  # 或 mariadb

服务重启后，再次登录到 Master 的 MySQL，现在我们需要获取一个关键的信息——**当前主库的二进制日志文件名和位置 (Position)**。这个信息将告诉 Slave 服务器从哪里开始“抄写”。

重要操作： 如果你的 Master 数据库上已经有数据并且正在被写入，为了获得一个完全一致的数据快照点，理论上最安全的操作是在获取这个状态信息之前，先锁定所有表，禁止写入：

[提示：请将以下代码片段复制并粘贴到 WordPress 的“代码”区块中]


-- 在 Master 的 MySQL 中执行 (需要 SUPER 或 RELOAD 权限)
FLUSH TABLES WITH READ LOCK;

这个命令会关闭所有打开的表，并用一个全局读锁锁定所有数据库的所有表，直到你执行 UNLOCK TABLES; 为止。这意味着在锁定期间，所有写操作都会被阻塞！ 所以这个操作务必在业务低峰期或维护窗口进行。

在表被锁定（或你确认没有写操作正在进行）后，执行：

[提示：请将以下代码片段复制并粘贴到 WordPress 的“代码”区块中]


SHOW MASTER STATUS;

你会看到类似这样的输出：


+------------------+----------+--------------+------------------+-------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000003 |      157 |              |                  |                   |
+------------------+----------+--------------+------------------+-------------------+

你需要**非常仔细地记下这里的 File (文件名，如 mysql-bin.000003) 和 Position (位置号，如 157)**。这两个值是后续配置 Slave 的“金钥匙”！

如果你执行了 FLUSH TABLES WITH READ LOCK;，请保持这个 MySQL 会话打开，不要关闭它！我们还需要在这个锁定状态下进行数据导出（下一步）。 如果你没有数据需要导出（比如 Master 是全新的），或者你可以容忍导出期间可能发生的少量数据不一致（不推荐用于生产），则可以跳过锁表或在获取状态后立即 UNLOCK TABLES;。

1.4. (如果需要) 导出主库数据以同步到从库：

如果 Master 上已经有数据了，你需要把这些数据原样复制一份给 Slave，作为复制的起点。最常用的方法是使用 mysqldump 工具进行全量备份。

打开一个新的服务器终端（保持上一步那个持有读锁的 MySQL 会话不要动！），执行以下命令导出所有数据库的数据：

[提示：请将以下代码片段复制并粘贴到 WordPress 的“代码”区块中]


# 将 master_dump.sql 替换为你想要的备份文件名
mysqldump -u root -p --all-databases --single-transaction --flush-logs --master-data=2 > /tmp/master_dump.sql
# 如果只想备份特定数据库: mysqldump -u root -p --databases db1 db2 --single-transaction ... > /tmp/master_dump.sql

参数解释：

--all-databases: 导出所有数据库。
--single-transaction: 对于 InnoDB 表，在导出开始时启动一个事务，可以保证导出的数据是一致性的快照，并且不会长时间锁定表。
--flush-logs: 在导出开始前，会滚动当前的二进制日志文件。执行这个选项后，SHOW MASTER STATUS; 看到的 File 和 Position 会是你下一次复制应该开始的点，但这与我们之前获取的点可能不同。为了简单起见，如果你已经在上一步锁表后用 SHOW MASTER STATUS; 获取了 File 和 Position，那么在 mysqldump 时可以不加 --flush-logs 和 --master-data，以之前获取的为准。
--master-data=2: 这个选项会在导出的 SQL 文件中以注释的形式加入一条 CHANGE MASTER TO ... 语句，包含了当前的二进制日志文件名和位置。这很方便，但如果你之前已经手动记录了 File 和 Position，也可以不用它。值为 1 则不注释。

本教程推荐： 既然我们已经在上一步锁表后手动执行了 SHOW MASTER STATUS; 并记下了 File 和 Position，那么这里 mysqldump 可以简单一些，主要目的是导出数据：

[提示：请将以下代码片段复制并粘贴到 WordPress 的“代码”区块中]


mysqldump -u root -p --all-databases --single-transaction > /tmp/master_dump.sql

导出完成后（可能需要一些时间，取决于数据量），你需要将这个 /tmp/master_dump.sql 文件安全地传输到你的 **Slave 服务器**上（比如用 scp 命令）。

数据导出完成后，回到你之前那个持有读锁的 Master MySQL 会话，执行以下命令解除锁定：

[提示：请将以下代码片段复制并粘贴到 WordPress 的“代码”区块中]


UNLOCK TABLES;
EXIT;

现在 Master 服务器的准备工作基本完成了！

第二步：配置 Slave 服务器 – “复印机”的就绪与“校对基准”

...

第三步：测试与验证 - “墨迹”是否同步？

...

后续步骤与注意事项（重要！）

...

结论：读写分离与高可用的“第一块基石”已奠定！

恭喜你！如果你成功地完成了以上所有步骤，并且在 Slave 服务器上用 SHOW SLAVE STATUS\G 命令看到了那两个令人心安的 Yes (Slave_IO_Running: Yes 和 Slave_SQL_Running: Yes)，以及一个很小（最好是 0）的 Seconds_Behind_Master，那么，你就已经成功搭建起了一个基础的 MySQL/MariaDB 主从复制环境！

现在，你的 Master 服务器（原稿作者）所做的任何数据修改，都会通过二进制日志近乎实时地被 Slave 服务器（抄写员）复制过去。你已经为实现**数据库读写分离**（将读请求导向 Slave，写请求发往 Master）和**基本的数据冗余/高可用性**（当 Master 故障时，Slave 可以作为数据副本或潜在的接替者）奠定了最重要的一块基石！

但是，请务必记住，我们今天搭建的只是一个**最基础、最简单**的主从复制模型。它通常是异步的（Master 不会等待 Slave 确认复制成功），并且没有自动的故障转移机制。一个真正生产环境可用的、健壮的数据库复制和高可用架构，还需要考虑更多因素：

安全性： 为复制用户设置更严格的权限和来源 IP 限制，考虑为复制通道启用 SSL/TLS 加密。
监控与告警： 持续监控主从复制的状态（SHOW SLAVE STATUS\G），特别是 Seconds_Behind_Master 和任何错误信息，并设置告警。
故障转移策略： 当 Master 发生故障时，如何将 Slave 提升为新的 Master？这个过程是手动操作，还是通过脚本或工具（如 MHA, Orchestrator, ProxySQL 等）实现自动化？
GTID 复制： 基于全局事务标识符 (GTID) 的复制通常比基于二进制日志文件和位置的复制更健壮，尤其是在故障切换和重新配置复制时更不容易出错。这是进阶学习的方向。
数据一致性与延迟： 理解异步复制可能带来的主从数据延迟，并评估其对你应用的影响。是否需要考虑半同步复制 (Semi-Sync Replication) 来增强数据一致性保障？
备份策略： 如何结合主从复制来制定更完善的数据备份和恢复方案？

所以，把今天搭建的这个环境看作是你迈向数据库高级运维的“第一堂实操课”。它为你打开了一扇通往更高性能、更高可用性数据库架构的大门。继续学习，不断实践，你一定能把你的数据库“玩”得越来越溜！

还有疑问？常见问题解答 (FAQs)

问: 如果我的 Master 服务器 IP 地址因为某些原因改变了，Slave 会不会就断开复制了？该怎么办？ 答: 是的，如果 Master 的 IP 地址变了，而 Slave 的 CHANGE MASTER TO ... MASTER_HOST='旧IP' ... 配置没有更新，那么 Slave 的 I/O 线程将无法连接到新的 Master IP，复制会中断 (Slave_IO_Running 会变成 No)。你需要登录到 Slave 服务器的 MySQL，执行 STOP SLAVE;，然后执行新的 CHANGE MASTER TO MASTER_HOST='新MasterIP', ... 命令（其他参数如用户名、密码、日志文件和位置通常不需要改变，除非 Master 也重置了），最后执行 START SLAVE; 来恢复复制。
问: 一台 Master 服务器可以有多台 Slave 服务器吗？反过来，一台 Slave 可以同时从多台 Master 复制吗？ 答: 1) 一台 Master 可以有多台 Slave： 这是非常常见的架构，比如一个主库带多个从库来实现读写分离的横向扩展，或者用于不同的备份/分析目的。每台 Slave 都独立地连接到 Master 读取二进制日志。2) 一台 Slave 通常不能直接同时从多台 Master 复制（标准的星型复制不支持）： 如果你想实现将多个 Master 的数据汇总到一个 Slave 上，或者更复杂的多主复制拓扑，你需要考虑更高级的技术，比如 MySQL Cluster (NDB), Galera Cluster, Percona XtraDB Cluster (它们实现了多主同步复制)，或者使用第三方工具和自定义脚本来实现数据聚合。标准的异步主从复制是单源的。
问: 如果 Slave 服务器因为某些原因（比如网络中断、重启）落后 Master 太长时间，或者复制出错了（比如主键冲突），该怎么办？ 答: 这是维护主从复制时常遇到的问题。1) **对于复制中断或延迟：** 首先通过 SHOW SLAVE STATUS\G 查看错误信息 (Last_Error, Last_SQL_Error, Last_IO_Error) 和延迟情况 (Seconds_Behind_Master)。如果是临时网络问题，网络恢复后 Slave 通常会自动尝试重连并追赶。如果错误导致 SQL 线程停止 (Slave_SQL_Running: No)，你需要分析错误原因。对于某些可以安全跳过的错误（比如你确认是无关紧要的、或者你已手动在 Slave 上修复了数据），可以用 SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; START SLAVE; 来跳过一个事务错误。但滥用跳过会导致数据不一致！2) **对于严重的数据不一致或长时间延迟：** 最可靠（但也最耗时）的方法通常是**重新搭建从库**，即停止 Slave，删除其数据目录中的数据（或只保留 Relay Log 信息），从 Master 重新获取一个一致性的数据快照 (mysqldump) 和新的二进制日志位置，然后在 Slave 上恢复数据并重新配置复制。使用 GTID 复制可以简化某些场景下的重新同步。
问: 主从复制能完全替代我的数据库备份方案吗？ 答: 绝对不能！ 主从复制提供了数据的**冗余**和**近乎实时的副本**，它对于提升读性能和作为高可用方案的一部分非常有价值，也能在一定程度上防止因 Master 硬件故障导致的数据丢失。但是，它不能替代传统的、定期的、最好是异地的数据库备份。原因在于：1) 如果 Master 上发生了人为的误操作（比如不小心 DROP TABLE 了一个重要表），这个错误操作也会被复制到所有的 Slave 上，导致所有副本数据都被破坏。2) 如果 Master 上的数据因为软件 Bug 或其他原因损坏了，损坏的数据也可能被复制到 Slave。只有定期的、基于时间点的备份（比如每天的全量备份 + 增量备份），才能让你在发生这类逻辑错误或数据损坏时，将数据恢复到某个特定的、健康的历史状态。所以，主从复制和定期备份是相辅相成、缺一不可的。
问: 我听说还有一种叫 GTID 的复制方式，它和我们今天配置的基于文件和位置的复制有什么区别？哪个更好？ 答: GTID (Global Transaction Identifier - 全局事务标识符) 复制是 MySQL 5.6 和 MariaDB 10.0 以后引入的一种更现代、更健壮的复制方式。在传统的基于二进制日志文件和位置 (Binlog File + Position) 的复制中，Slave 需要明确知道从 Master 的哪个日志文件的哪个位置开始复制。当发生主从切换 (Failover) 或者需要重新配置复制时，手动查找和指定这个文件和位置可能会很麻烦且容易出错。而 GTID 复制为每一个在 Master 上提交的事务都分配了一个全局唯一的 ID。Slave 在复制时，不再关心具体的日志文件和位置，而是只需要知道自己已经复制到了哪个 GTID，然后从下一个 GTID 开始复制即可。这使得**主从切换、添加新从库、或者从故障中恢复复制等操作变得更加简单和自动化，也更不容易出错**。因此，对于新的生产环境，如果你的 MySQL/MariaDB 版本支持，**强烈建议优先学习和使用 GTID 复制**。我们今天介绍的基于文件和位置的复制是最基础的入门方式。