将 mariaDB 数据库迁移到新服务器和新的 mariaDB 版本，并使用原始 innoDB 分区

Question

我有一个运行 mariaDB-5.5 的 Linux 服务器；这些表都是（我认为）innoDB 表，并且数据存储在原始分区上；实际上在两个原始分区上，因为几年前在最后一次硬件升级时，我们添加了第二个分区以增加容量。我刚刚检查过，现在我的表的“数据长度”+“索引长度”约为 95GB。

我即将迁移到新的存储和服务器以及操作系统，因此将使用 mariaDB-10.5（或者我可能会选择 11.4，而不是操作系统提供的版本）。据我从文档中看到，这不应该有任何重大问题，但我很感激专家/经验丰富的人对某些相互关联的观点的想法：

1. 原始分区：如果我继续使用多个原始文件系统与创建一个大文件系统，这有什么真正的区别吗？
2. 原始分区仍然合理吗？这是由我的前任设置的，但阅读文档后，我不完全确定这可能会比“每个表一个文件”配置带来性能改进。有什么想法吗？我不太清楚如何进行反映生产环境中使用情况的速度测试：我没有能力创建实时系统的开发克隆。

3. mysqldump

   vs

   dd

   。 上次我这样做时，我只是使用

   dd

   将旧的原始分区逐字节复制到新分区。这就是为什么我们有两个分区，因为这当然妨碍了调整它的大小。这部分是因为

   mysqldump

   会生成一个非常大的文件，部分是因为我有点担心如果我走那条路，最终会出现外键死锁或类似的愚蠢情况。另一方面，使用

   dd

   需要我在新机器上创建原始分区，精确复制旧机器上的数量和大小（因此问题 1），这显然有些限制。

我想当我在这里的时候，有什么我没有预见到我应该注意的令人讨厌的问题吗？

我也会阅读 percona 工具包选项，但还没有读到那么远！

Answer 1

欢迎您升级。

考虑到 10.5 还需要大约 1 年的维护时间，跳转到 11.4 听起来很谨慎，并且与您迄今为止不频繁的更新保持一致。

正如您所发现的，原始分区管理起来有点混乱。在文件系统中，文件系统的目的是提供对原始存储尽可能的直接访问。虽然不是 0 开销，但与原始存储读/写速度相比，文件系统处理的几个 cpu 周期很少。

因此，我建议删除下一台服务器中的原始分区。

最大限度地减少停机时间，创建新服务器作为当前服务器的副本。这里的关键方面是您需要在当前服务器上启用二进制日志记录，并拍摄记录当前数据位置的时间点快照。

如果在转储期间创建/删除表，则需要关注

mysqldump

（现在称为

mariadb-dump

）的长事务。如果情况并非如此，则可以将 

mysqldump

 流式传输到 

mariadb

（以前称为 

mysql

 的客户端）以填充新服务器。请注意使用 

--dump-slave

 和 

--single-transaction

。应执行 

change master to

 以列出 

master_host

，然后复制应开始。确保您的新服务器具有较大的 innodb 缓冲池和 innodb 日志文件大小，以方便大量写入。

作为测试过程的试运行，也许可以使用

mariadb-dump --no-data

 执行第一步以确保复制表结构。复制不起作用，但请确保您了解迁移中的所有步骤。

完成后，会发生一次小中断，确保复制在新服务器上进行，

stop replica

并将应用程序流量切换到新数据库。