我来自 Microsoft SQL Server 数据库世界，已经在那里工作了大约 7 年。我的新角色完全基于各种开源数据库引擎。
当我一直在准备迁移到 AWS RDS 和/或更新版本的 MariaDB 时，我想到了一个关于我公司备份策略的问题。ATM，为了避免敏感细节，没有任何解决方案。最受关注的数据库都运行在较旧的 TokuDB 存储引擎上，并且是需要迁移的有问题的数据库。备份这些数据库主要是通过以下方法完成的，而不是将整个数据库通过管道传输到一个 .sql 文件中
mysqldump -u root -p -t -T/$source $database $databasetable --fields-terminated-by='|' --lines-terminated-by='\n' --order-by-primary
我可以简单地说备份整个数据库并让它一次吐出每个表，但无论如何，这需要几个小时。进行普通的 sql 转储，无论是否使用 gzip，都需要 24 小时以上，甚至更多。这显然不是最好的标准备份策略，就像您可以在 Ola Hallengren 的 Microsoft SQL Server 维护计划中找到的那样。但是，我能想到的唯一替代方法是用 python 编写一些东西或使用 cronjob 来执行备份尚未确定的时间表。
我找到的唯一解决方案是 Percona 的 XtraBackup，但想看看社区是否有其他想法。
更多背景：
这些数据库服务器在 AWS 和 Ubuntu 上作为 EC2 实例运行，并配置为 m4.large 或 m4.xlarge。
有多个主副本，因此理想情况下备份应该在主副本上完成，而不是副本
最后提到 是 - 迁移到 RDS 是一个选项，这将通过自动备份消除这个问题。然而，这些旧的 Tokudb 服务器的迁移不会“那么”容易，所以我们可能需要一些时间才能到达那里。
我将不胜感激任何意见或建议。谢谢你。
Percona XtraBackup 是 InnoDB 表的热备份工具。它不会占用 TokuDB 或任何其他存储引擎。
Percona也做了TokuDB的热备份工具：https ://docs.percona.com/percona-server/8.0/tokudb/toku_backup.html
如果你有一个混合环境，这两个工具都有警告，两个存储引擎中都有一些表。仔细阅读文档并进行大量测试。
另一个快速备份选项是使用 LVM 快照。我建议查看mylvmbackup，它只是一个方便的脚本，它包装了制作 LVM 快照所需的多个步骤。
不管存储引擎如何，另一条通用建议适用：删除不需要存储在此数据库中的任何数据。
在我分析过的许多数据库中，很多数据都适合归档，然后从数据库中删除。如果您使实时数据库实例更小，那么任何备份解决方案都将更易于管理。您不必永久销毁数据，而是将其移动到一些更便宜的存储中。