如何将 MySQL 数据库同步到另一台服务器：4 种方法

保持服务器之间的数据一致性是 MySQL 管理员面临的常见挑战。无论你是要迁移到云端、扩展读取能力，还是设置灾难恢复，都需要一种可靠的方式将 MySQL 数据库同步到另一台服务器。

正确的方法取决于你的环境。一次性脚本可能适用于预发布环境，但生产系统通常需要持续、低延迟的复制。

本指南涵盖四种在两个 MySQL 数据库之间同步数据的实用方法，从命令行工具到原生复制和企业级同步解决方案。

为什么要将 MySQL 数据库同步到另一台服务器？

正确的方法取决于目标、网络和数据量。以下是最常见的场景。

一次性迁移 完整传输且无持续链接，通常用于迁移到新服务器或云服务商。

只读副本和扩展 将读取查询分流到辅助服务器，使主服务器专注于写入。依赖同步或异步复制来保持更新。

实时分析和报表 将数据复制到单独的服务器，以便 BI 工具可以查询数据而不拖慢生产系统。

灾难恢复 保持备用数据库随时待命，以便在主服务器宕机时接管。

同步前检查清单：开始前需要确认的事项

在开始同步前进行几项检查，可以节省大量后续排查时间。

• 同步表上的稳定主键：每个表都需要主键或唯一、非空索引，以便识别行。如果没有主键，复制延迟会增加，持续同步期间的冲突解决也会变得更困难。
• 网络和防火墙访问：确认目标服务器可以访问源服务器，通常需要在两台主机之间开放 port 3306 端口。
• MySQL 版本匹配或兼容：使用 SELECT VERSION(); 检查两个版本。从较旧版本复制到较新版本通常没问题，但反过来往往会导致兼容性错误。
• 当前数据库备份：在运行任何同步工具之前，先对源数据库进行完整备份；如果你需要企业级保护，可以使用类似 i2Backup 的工具。这样如果脚本行为异常或覆盖生产数据，你还有一个恢复点。

将 MySQL 数据库同步到另一台服务器的 4 种方法

最佳方法取决于数据库大小、可接受的停机时间和管理员技能水平。下面快速比较这四种方法。

方法 1：使用 mysqldump 进行一次性复制（迁移）

使用 mysqldump 导出 MySQL 数据库 是一次性迁移中移动数据的标准方式。这个命令行工具会将 schema 和数据导出为包含 SQL 语句的文件。由于它捕获的是静态快照，因此创建 dump 之后所做的任何更改都不会包含在内。

步骤 1. 导出源数据库

在源服务器上运行 mysqldump ，将数据库导出为 .sql 文件。对于 InnoDB 表，建议使用 --single-transaction 标志，以避免锁定正在使用的生产数据。

mysqldump -u root -p --single-transaction --databases my_database > db_dump.sql

步骤 2. 传输 dump 文件

使用安全的传输方式将导出的文件移动到目标服务器。 scp 或 rsync 都适合此操作。

scp db_dump.sql user@target_server_ip:/tmp/

步骤 3. 导入到目标服务器

登录目标服务器，使用 mysql 客户端加载 SQL 文件并重建数据库。

mysql -u root -p < /tmp/db_dump.sql

为慢速网络压缩大型 dump 文件

对于较大的数据库，在传输前压缩 dump 文件可以缩短传输时间。最简单的方法是将输出直接通过 gzip 管道处理：

mysqldump -u root -p --single-transaction --databases my_database | gzip > db_dump.sql.gz

在目标端，可以在单个管道中解压并导入，以节省本地磁盘空间：

gunzip < db_dump.sql.gz | mysql -u root -p

何时不要使用此方法

此方法不适合高流量、活跃的生产数据库，因为它无法提供持续更新。大型数据库可能需要数小时才能 dump 和恢复，这意味着迁移切换期间会有显著停机时间。需要持续同步或最小停机的团队应考虑复制。

方法 2：使用 MySQL Workbench 进行图形化同步（无需命令行）

MySQL Workbench 提供图形界面，无需编写命令行参数即可在两个 MySQL 数据库之间同步数据。其向导会引导你以可视化方式复制 schema 结构和行。此方法最适合较小的数据集和非生产系统。

步骤 1. 设置到两台服务器的连接

1. 启动 MySQL Workbench，点击 MySQL Connections 旁边的 + 图标。
2. 输入源服务器的主机名、用户名和密码，然后点击 Test Connection。
3. 重复该过程，为目标服务器创建第二个连接配置。
4. 在继续之前确认两个连接都成功。

步骤 2. 导出源数据库

1. 打开源连接，在 Navigator 侧边栏中选择 Data Export 。
2. 选择要复制的 schema。
3. 选择 Export to Self-Contained File。
4. 点击 Start Export。

步骤 3. 导入到目标服务器

1. 打开目标连接。
2. 选择 Data Import/Restore。
3. 选择步骤 2 中创建的导出文件。
4. 点击 Start Import 以重建 schema 并加载数据。

步骤 4. 比较并同步后续 schema 更改

1. 打开 Database 菜单。
2. 选择 Synchronize with Any Source 进行实时到实时比较，或者如果要与 EER 模型比较，则选择 Synchronize Model。
3. 选择源和目标 schema，然后点击 Compare。
4. 查看差异报告，并取消选择你不想应用的任何更改。
5. 点击 Generate Script 生成对齐 schema 所需的 ALTER 语句，然后对目标运行该脚本。

方法 3：原生 MySQL 复制（持续同步 / 只读副本）

MySQL 复制是一项原生功能，可以持续将更改从源服务器流式传输到一个或多个副本服务器。它依赖二进制日志来跟踪更新，因此非常适合扩展读取、构建分析环境或设置灾难恢复。

前提条件 两台服务器都需要在 my.cnf 或 my.ini 文件中设置唯一的 server-id 。源服务器需要启用二进制日志，并且两端都需要通过 port 3306 进行网络访问。

步骤 1. 配置源服务器

1. 在源服务器上打开 MySQL 配置文件（Linux 上为 /etc/my.cnf ）。
2. 在 [mysqld] 块下，分配唯一的 server-id。
3. 使用 log-bin 启用二进制日志。
4. 可选地使用 binlog_do_db 将复制限制到特定 schema。

server-id = 1
log-bin = mysql-bin
binlog_do_db = my_database

保存文件并重启 MySQL 服务以应用更改。

步骤 2. 创建复制用户 登录源服务器，为副本创建专用账户。此用户只需要 REPLICATION SLAVE 权限来连接并读取二进制日志。

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

步骤 3. 获取一致性快照并记录日志位置

1. 锁定源表以暂停写入。
2. 在另一个会话中，检查当前二进制日志文件和位置。

FLUSH TABLES WITH READ LOCK;
SHOW MASTER STATUS;

3. 在锁仍然生效时，使用 mysqldump 导出数据库。
4. 导出完成后解锁表。

UNLOCK TABLES;

步骤 4. 配置副本

1. 将步骤 3 中的 dump 导入副本服务器。
2. 使用 CHANGE REPLICATION SOURCE TO 将副本指向源。

CHANGE REPLICATION SOURCE TO
  SOURCE_HOST = 'primary_server_ip',
  SOURCE_USER = 'repl_user',
  SOURCE_PASSWORD = 'StrongPassword123',
  SOURCE_LOG_FILE = 'mysql-bin.000001',
  SOURCE_LOG_POS = 154;

步骤 5. 启动复制并验证

1. 启动复制线程。
2. 检查状态输出。

START REPLICA;
SHOW REPLICA STATUS\G

3. 确认 Replica_IO_Running 和 Replica_SQL_Running 都显示 Yes。

MySQL 8.0+ 语法与旧术语 MySQL 8.0.22 及更高版本在复制命令中替换了 master 和 slave 等术语。 CHANGE REPLICATION SOURCE TO 取代了 CHANGE MASTER TO， SHOW REPLICA STATUS 取代了 SHOW SLAVE STATUS。旧语法在当前版本中仍可向后兼容，但对于已升级的环境，现代命令是更安全的选择。

方法 4：企业级复制工具（跨区域 / 零数据丢失同步）

原生复制适用于简单的设置，但在跨云区域或异构数据库时可能会吃力，尤其是在高写入负载下。当你需要具有亚秒级 RPO 的零数据丢失同步，或用于合规的详细审计日志时，仅靠原生工具往往不够。

关键评估标准

• RPO 和 RTO 目标：根据你的业务可以容忍多少数据丢失和停机时间来选择工具。
• 无代理与基于代理的部署：代理运行在主机上；无代理工具远程读取日志。要考虑对性能和安全策略的影响。
• DDL 和 DML 同步支持：确认工具不仅同步行级插入、更新和删除，还能同步 schema 更改。
• 延迟告警和监控：寻找实时仪表板以及延迟超过阈值时的告警。

像 i2Stream 这样的企业级工具如何解决这一问题

i2Stream 专为原生 MySQL 复制能力不足的场景而构建。

• 无代理、基于日志的架构：直接从数据库日志捕获事务，无需在生产服务器上安装软件，也不会产生可测量的性能影响。
• 广泛的跨平台支持：可在 40 多种数据库和平台组合之间同步，包括 MySQL、MariaDB、PostgreSQL、Oracle 和 SQL Server，适合将 MySQL 同步到不同引擎用于分析的团队。
• 接近零 RPO、分钟级 RTO：专为金融级灾难恢复而构建，支持主动-主动和多站点架构，保持事务级一致性并自动解决冲突。
• 集成 DDL/DML 同步：添加列等 schema 更改会与常规数据更新一起同步，因此结构变化不会破坏正在进行的复制流。
• 亚秒级延迟告警：统一仪表板实时跟踪吞吐量、延迟和错误，并通过自动校验和验证及早发现数据漂移。

对于需要超越数据库复制的高可用性的团队， i2Availability 将类似的故障转移原则扩展到完整的应用环境。

同步 MySQL 数据库时的常见问题及修复方法

同步设置往往会遇到一些反复出现的问题。以下是这些问题的原因以及各自的修复方法。

复制延迟

目标服务器无法跟上来自源的传入更改。这通常由单线程执行、高写入负载或目标端磁盘硬件较慢引起。

使用 replica_parallel_workers （在较旧版本上为 slave_parallel_workers ）启用多线程复制，并使用 binlog_format = ROW 的行级日志，以便目标端可以更快地应用更改。

批量同步中缺失删除和更新

大多数批量脚本使用类似 updated_at 的时间戳列查询源，但被删除的行不会留下任何痕迹供脚本捕获。

改用带有 is_deleted 列的软删除，或定期运行全表比较以捕获孤立行。

Schema 更改破坏同步

如果源上添加或删除了列，而副本失去对齐，复制线程一旦遇到引用本地不存在列的查询就会停止。

先在副本上应用匹配的 schema 更改，或使用可避免锁表的在线 schema 迁移工具。

双向设置中的复制循环

主动-主动设置可能会陷入循环，事务会在两台服务器之间无休止地来回反弹，因为它们无法区分自己的事务和已经接收过的事务。

为每台服务器分配唯一的 server-id 并启用 GTID（全局事务标识符），这样服务器就能识别并跳过已经处理过的事务。

常见问题

Q1：我可以将 MySQL 同步到不同版本的 MySQL 吗？

在大多数情况下可以。从较旧版本复制到较新版本通常受支持，但从较新版本复制到较旧版本往往会导致兼容性错误。在设置同步之前，使用 SELECT VERSION(); 检查两个版本。

Q2：同步 MySQL 数据库会导致停机吗？

这取决于方法。 mysqldump 导出和导入可能会短暂锁表，并且对于大型数据集会使数据库离线。原生复制和企业级同步工具在后台持续运行，因此源数据库始终保持在线。

Q3：复制和同步有什么区别？

复制是持续且基于日志的，将近乎实时地将更改从源流式传输到一个或多个目标。同步是一个更广泛的术语，根据设置方式，它可以指一次性复制、计划批量作业或持续复制。

Q4：我可以只同步特定表而不是整个数据库吗？

可以。 mysqldump 支持导出单个表，原生复制可以使用 binlog_do_db 或 replicate-do-table 等过滤器限定到特定数据库或表。大多数企业级同步工具也支持表级过滤。

Q5：mysqldump 对生产数据库安全吗？

是的，在与 --single-transaction 一起使用时是安全的，它可以避免在 dump 期间锁定 InnoDB 表。它不会锁定 MyISAM 等非事务性表，也无法防止在 dump 进行期间运行 schema 更改（DDL）。对于非常大的生产数据库，原生复制或企业级工具造成的影响更小。

结论

将 MySQL 数据库同步到另一台服务器，归根结底是根据目标选择方法。一次性的 mysqldump 适用于简单迁移，MySQL Workbench 适合较小的 GUI 驱动传输，原生复制处理持续同步和读扩展，而当需求变得更苛刻时，例如跨区域设置或接近零 RPO，企业级工具就会发挥作用。

无论哪种方法适合你的环境，在进行任何更改之前都要先进行完整备份。如果过程中出现复制延迟、schema 不匹配或其他同步问题，上面介绍的修复方法应该能帮助你回到正轨。

英方软件 为管理 MySQL 和其他数据库环境的团队提供更多类似的数据库保护和复制主题。