Mysql

关注公众号 jb51net

关闭
首页 > 数据库 > Mysql > Windows到Linux数据库迁移

Windows到Linux数据库迁移实战(从mysqldump到数据一致性验证)

作者：暗暗yu

数据库迁移是系统运维中的常见需求,涉及将数据从一个环境安全、完整地转移到另一个环境,其核心原理是通过逻辑备份或物理备份实现数据转移,确保业务连续性和数据一致性,感兴趣的可以了解一下

1. 从Windows到Linux：一次数据库迁移的完整心路

最近帮一个朋友的公司处理了一个挺典型的数据库迁移需求：他们之前为了快速上线，把业务系统直接部署在了一台Windows服务器上，MySQL也顺理成章地装在了上面。随着业务量慢慢起来，那台Windows服务器的性能和稳定性开始有点捉襟见肘，加上运维团队对Linux更熟悉，成本也更可控，所以决定把整个MySQL数据库迁移到一台新的CentOS服务器上。这个“把Windows上的MySQL搬到Linux上”的需求，听起来简单，但实际操作起来，从环境差异、字符集到权限配置，每一步都可能藏着坑。今天我就把这次完整的迁移过程、踩过的雷以及最终验证有效的方案，从头到尾梳理一遍，希望能给面临同样场景的朋友一个清晰的参考。

迁移的核心目标很明确：保证数据100%一致，业务停机时间最短，迁移后服务能无缝衔接。这不仅仅是 mysqldump 导出一份SQL文件那么简单，它涉及到源端与目标端的环境评估、迁移策略选择、数据一致性校验以及迁移后的性能调优等一系列动作。整个过程，我把它拆解成了几个关键阶段：迁移前的全面“体检”、选择合适的迁移工具与路径、执行迁移操作、以及迁移后的验证与优化。下面，我们就按这个脉络，一步步深入。

2. 迁移前准备：不打无准备之仗

在动手迁移之前，充分的准备工作能避免至少80%的意外。这个阶段的目标是摸清家底，扫清障碍，并制定一个可回滚的详细计划。

2.1 全面评估源库与目标环境

首先，我们需要对Windows上的源数据库和未来的Linux新家有一个彻底的了解。

源库（Windows）信息收集：

  1. MySQL版本 ：登录MySQL，执行 SELECT VERSION(); 。记录完整版本号，例如 8.0.33 。这直接决定了兼容性和可用的备份工具。
  2. 数据库与表结构 ：执行 SHOW DATABASES; 列出所有库。对于非系统库（如 information_schema , mysql , performance_schema , sys ），需要特别关注。然后，对每个业务库，检查其默认字符集和排序规则： SELECT DEFAULT_CHARACTER_SET_NAME, DEFAULT_COLLATION_NAME FROM information_schema.SCHEMATA WHERE SCHEMA_NAME = ‘your_database’; 。Windows上默认安装的MySQL，字符集有时会是 latin1 ，而Linux上更常见 utf8mb4 ，这个差异是后续数据乱码的潜在元凶。
  3. 存储引擎 ：执行 SHOW TABLE STATUS FROM your_database; 查看主要表的存储引擎。MyISAM和InnoDB在迁移时注意事项不同，尤其是涉及到表级锁和事务支持时。
  4. 数据量评估 ：粗略估算每个业务库的大小。可以使用 SELECT table_schema AS ‘Database’, ROUND(SUM(data_length + index_length) / 1024 / 1024, 2) AS ‘Size (MB)’ FROM information_schema.TABLES GROUP BY table_schema; 来查看。这有助于你判断迁移时间窗口和选择合适的迁移方式（逻辑导出 vs. 物理拷贝）。
  5. 特殊对象 ：检查是否有存储过程、函数、触发器、事件。使用 SHOW PROCEDURE STATUS; ， SHOW FUNCTION STATUS; ， SHOW TRIGGERS; ， SHOW EVENTS; 。这些对象的定义也需要完整迁移。
  6. 用户与权限 ：这是最容易遗漏的一环。执行 SELECT user, host FROM mysql.user; 查看所有用户。然后，对于每个业务用户，使用 SHOW GRANTS FOR ‘username’@’host’; 命令导出其完整的权限语句。务必记录 host 字段，因为 ‘user’@’localhost’ 和 ‘user’@’%’ 在权限上是完全不同的。

目标环境（Linux）准备：

  1. 操作系统 ：确认Linux发行版（如CentOS 7/8, Ubuntu 20.04/22.04）和内核版本。
  2. MySQL安装 ： 强烈建议在目标Linux服务器上安装与源库完全相同的主版本号（Major Version）的MySQL 。例如，源是MySQL 8.0.33，目标也安装MySQL 8.0.x的最新版本。这能最大程度避免因版本差异导致的语法或功能不兼容。可以通过官方Yum源或APT源进行安装。
  3. 文件系统与空间 ：确保目标服务器的磁盘空间至少是源库数据文件大小的1.5倍以上，为备份文件、临时文件留出余地。考虑使用 ext4 或 xfs 这类适合数据库的文件系统。规划好MySQL的数据目录（如 /var/lib/mysql ）。
  4. 防火墙与网络 ：确保Linux服务器的防火墙（如 firewalld 或 iptables ）开放了MySQL的默认端口（3306），如果你计划在迁移过程中直接从Windows服务器传输文件到Linux，还需要开放SSH端口（22）或用于文件传输的其他端口。

2.2 制定迁移方案与回滚计划

根据数据量、停机时间要求和技术熟悉度，选择迁移方案：

对于大多数从Windows迁移到Linux的中小型项目， 方案一（mysqldump）是最稳妥、最通用的选择 。本次分享也将以 mysqldump 为核心展开。

制定回滚计划 ：必须明确，如果迁移失败，如何快速切回原Windows数据库。通常这意味着在迁移开始前，对源库做一个完整的备份，并确保在迁移验证完成前，原Windows数据库服务保持可随时启动的状态。同时，要通知业务方明确的停机时间窗口。

3. 核心迁移操作：步步为营的执行细节

假设我们选择了 mysqldump 方案。下面进入具体的操作环节。

3.1 在Windows源服务器上执行逻辑备份

首先，在Windows服务器上，打开命令提示符（CMD）或PowerShell，切换到MySQL的 bin 目录（例如 C:\Program Files\MySQL\MySQL Server 8.0\bin ），或者将该目录添加到系统环境变量 PATH 中。

全库备份命令： 这是最常用的命令，它会备份所有数据库（包括系统库，但通常我们不需要恢复系统库）。

mysqldump -u root -p --all-databases --single-transaction --routines --triggers --events --set-gtid-purged=OFF --default-character-set=utf8mb4 > full_backup.sql

让我们拆解每个参数：

注意 ：如果数据库非常大，生成的SQL文件可能会达到几十GB。建议使用压缩，可以节省大量磁盘空间和传输时间。在Windows上，可以借助 gzip （如果安装了Git Bash或Cygwin）或 7-Zip 。一个更通用的方法是使用管道：

mysqldump -u root -p --all-databases --single-transaction --routines --triggers --events --set-gtid-purged=OFF --default-character-set=utf8mb4 | gzip > full_backup.sql.gz

这样得到的是压缩后的文件。

单独备份用户权限： 之前用 SHOW GRANTS 导出的权限语句，最好也保存到一个单独的文件，例如 grants.sql 。因为 mysqldump --all-databases 虽然会包含 mysql 系统库，但直接恢复整个 mysql 库到新环境可能会覆盖目标库原有的系统配置，风险较高。更安全的做法是只恢复业务用户权限。

3.2 将备份文件传输到Linux目标服务器

备份文件生成后，需要将其从Windows服务器安全地传输到Linux服务器。最常用的工具是 scp （Secure Copy）或 sftp 。

在 Linux服务器 上执行以下命令，从Windows服务器拉取文件（假设Windows服务器IP是 192.168.1.100 ，备份文件在 C:\backup\ 目录）：

# 如果Windows服务器开启了OpenSSH服务（Win10/Server 2019以后版本内置）
scp administrator@192.168.1.100:/C:/backup/full_backup.sql.gz /tmp/

# 更常见的做法是，在Windows上用支持SCP/SFTP的客户端（如WinSCP）图形化上传，或者使用共享文件夹。
# 这里以在Linux上使用scp从开启了SSH的Windows拉取为例，需要Windows端有SSH服务并已知用户名密码或密钥。

如果文件很大，传输过程可能中断。可以考虑使用 rsync 命令，它支持断点续传：

rsync -avz --progress administrator@192.168.1.100:/C:/backup/full_backup.sql.gz /tmp/

如果备份文件是压缩的（ .gz ），可以先传输，在Linux上解压，这样可以减少网络传输量。

3.3 在Linux目标服务器上准备MySQL环境并恢复数据

  1. 安装MySQL ：确保安装与源库同主版本的MySQL。例如在CentOS 7上安装MySQL 8.0： 
    sudo yum install -y https://dev.mysql.com/get/mysql80-community-release-el7-3.noarch.rpm
sudo yum install -y mysql-community-server
  2. 初始化并启动MySQL ：
    sudo systemctl start mysqld
sudo systemctl enable mysqld
    首次启动后，MySQL会为root用户生成一个临时密码，记录在日志文件中（通常 sudo grep ‘temporary password’ /var/log/mysqld.log ）。使用该密码登录并立即修改。
  3. （可选）调整配置 ：根据Linux服务器的硬件配置，初步调整 /etc/my.cnf 中的一些参数，如 innodb_buffer_pool_size （通常设置为物理内存的50%-70%）。但这一步也可以在数据恢复完成后进行细调。
  4. 恢复数据前的重要操作 ：在恢复全库备份前， 强烈建议先注释掉或删除备份SQL文件开头关于 mysql 系统库的部分 。用 vim 或 sed 打开 full_backup.sql ，找到类似 CREATE DATABASE /*!32312 IF NOT EXISTS*/ mysql /*!40100 DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci */; 和 USE mysql ; 以及后续对 mysql 库的所有操作语句，将其注释或删除。因为我们只想恢复业务数据，不想覆盖新MySQL实例自身的系统表。
  5. 执行数据恢复 ：
    # 如果备份文件是压缩的，先解压
gunzip /tmp/full_backup.sql.gz

# 使用mysql客户端执行SQL文件恢复
mysql -u root -p < /tmp/full_backup.sql
    这个过程可能会很长，取决于数据量大小。你可以观察MySQL的错误日志（ /var/log/mysqld.log ）来监控进度，或者另开一个终端用 SHOW PROCESSLIST; 查看当前执行状态。
  6. 恢复用户权限 ：将之前单独保存的 grants.sql 文件传到Linux，然后执行：
    mysql -u root -p < /tmp/grants.sql
    执行后，最好用 FLUSH PRIVILEGES; 命令刷新权限，使其立即生效。

4. 迁移后验证：确保数据一致与服务就绪

数据恢复完成，并不意味着迁移成功。必须进行严格的验证。

4.1 基础连通性与对象检查

  1. 连接测试 ：使用原有的业务账号和密码，从应用服务器或本地尝试连接Linux上的新MySQL数据库。
  2. 对象数量核对 ：分别在源库（Windows）和目标库（Linux）执行以下命令，对比结果是否一致：
    -- 检查数据库列表
SHOW DATABASES;

-- 检查某个库下的表数量
SELECT COUNT(*) FROM information_schema.TABLES WHERE TABLE_SCHEMA = ‘your_database';

-- 检查存储过程、函数、触发器、事件的数量
SELECT COUNT(*) FROM information_schema.ROUTINES WHERE ROUTINE_SCHEMA = ‘your_database';
SELECT COUNT(*) FROM information_schema.TRIGGERS WHERE TRIGGER_SCHEMA = ‘your_database';
SELECT COUNT(*) FROM information_schema.EVENTS WHERE EVENT_SCHEMA = ‘your_database';

4.2 数据一致性校验（核心）

这是最关键的一步，确保每一个字节的数据都正确无误。对于非巨型表，可以采用抽样校验。

方法一：行数校验 对每个业务表，执行 SELECT COUNT(*) FROM table_name; ，对比源和目标的数量。但这种方法只能发现数据丢失，无法发现数据内容错误。

方法二：CHECKSUM TABLE MySQL提供了 CHECKSUM TABLE 命令，可以计算整个表的校验和。

-- 在源库执行
CHECKSUM TABLE your_database.table_name;

-- 在目标库执行同样的命令

对比两次结果的 Checksum 值。如果一致，则表数据一致性概率极高。 但需要注意 ： CHECKSUM TABLE 对于有浮点数列或 BLOB/TEXT 列且值经常变化的表，可能每次计算结果都不同，此时该方法不适用。

方法三：自定义哈希对比（推荐） 对于关键表，或者想更放心，可以写一个简单的脚本，对表内容进行哈希比对。思路是：按照主键顺序，将每一行数据拼接成一个字符串，然后计算整个结果集的MD5或SHA256哈希值。

-- 示例：在源库和目标库分别执行，假设表有id, name, age三列
SELECT MD5(GROUP_CONCAT(CONCAT_WS(‘|', id, name, age) ORDER BY id SEPARATOR ‘#')) AS hash FROM your_table;

比较两个库计算出的 hash 值。 GROUP_CONCAT 有长度限制（默认1024字节），对于大表需要分段处理或调整 group_concat_max_len 参数。这是一种非常可靠的方法，但需要一定的脚本编写能力。

方法四：使用专业工具 对于企业级的重要迁移，可以考虑使用 pt-table-checksum （Percona Toolkit的一部分）来进行在线一致性校验。它功能强大，但配置和使用也相对复杂。

4.3 应用功能测试与切换

  1. 只读测试 ：将测试环境的应用配置指向新的Linux数据库，进行全面的功能测试，特别是涉及增删改查的核心业务流程。
  2. 性能基准测试 ：运行一些典型的查询语句，对比在Windows源库和Linux目标库上的执行时间。可以使用 EXPLAIN 分析执行计划是否一致。Linux通常在高IO场景下表现更优，但也要确认配置得当。
  3. 正式切换 ：
    • 选择一个业务低峰期，通知相关方开始切换。
    • 停止 Windows上的业务应用（或使其进入维护模式）。
    • 进行 最终的数据同步 （如果迁移过程中源库仍有少量写操作，可能需要利用备份后的二进制日志进行增量恢复，这涉及 mysqlbinlog 工具，步骤更复杂，本文不展开）。
    • 修改生产环境应用的数据库连接配置，指向新的Linux服务器地址。
    • 启动 业务应用，并密切监控日志和应用状态。
    • 进行快速的冒烟测试，确认核心功能正常。

5. 常见问题与避坑指南

在实际操作中，我遇到了不少典型问题，这里列出来供大家参考。

问题一：迁移后中文乱码 这是Windows到Linux迁移的最高频问题。现象是数据中的中文变成了问号 ? 或乱码。

问题二： mysqldump 备份时出现 Warning: A partial dump from a server that has GTIDs

问题三：恢复过程中出现 ERROR 2006 (HY000) at line XXX: MySQL server has gone away

问题四：迁移后自增主键（AUTO_INCREMENT）值不连续或归零

问题五：权限恢复后，应用用户仍然无法连接或操作

迁移完成后，别忘了在业务平稳运行一段时间后，清理旧的Windows数据库服务器上的数据，并归档本次迁移的所有操作记录和备份文件，形成文档，这对未来的运维和审计非常有价值。整个迁移过程，核心是“细”和“稳”，每一步操作前都想好回退方案，每一次关键操作后都立即验证，这样才能在跨平台的数据库迁移中，把风险降到最低。

到此这篇关于Windows到Linux数据库迁移实战(从mysqldump到数据一致性验证)的文章就介绍到这了,更多相关Windows到Linux数据库迁移内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！

您可能感兴趣的文章:
阅读全文