巨大的mysql数据库的可靠备份？

Question

我有200GB / 400Mrows的mysql / innodb数据库 - 远远超出我发现的合理范围。

一个令人惊讶的问题是恢复备份。 mysqldump生成巨大的sql文件，他们需要大约一个星期的时间才能导入到一个新的数据库中（试图让它变得更快，如更大/更小的事务，在导入期间关闭密钥等，网络压缩等到目前为止失败，myisam import似乎快2倍然后就没有交易了）。

更糟糕的是 - 我希望能得到一些帮助 - 在一周的时间内传输> 200GB的网络连接有一个非常重要的破坏机会，并且sql导入过程不能以任何非平凡的方式继续。

处理它的最佳方法是什么？ 现在，如果我注意到连接断开，我手动尝试通过检查最后导入的表的最高主键来确定它何时结束，然后有一个perlscript基本上这样做：

perl -nle 'BEGIN{open F, "prelude.txt"; @a=<F>; print @a; close F;}; print if $x; $x++ if /INSERT.*last-table-name.*highest-primary-key/'

这真的不是要走的路，那么最好的方法是什么？

Answer 1

您的MySQL盒子是否有足够的硬盘空间可以将所有数据加倍？ 本地存储在这里是最好的，但如果它不是一个选项，你也可以尝试使用iSCSI的某种NAS设备。 它仍然通过网络发生，但在这种情况下，您可以获得更高的吞吐量和可靠性，因为您只依赖于具有相当纤薄操作系统且几乎从不需要重新启动的NAS。

Answer 2

你不能使用mysqldump来备份大型数据库 - 200G是可行的，但是更大的数据库会变得越来越糟。

你最好的选择是获取数据库目录的卷快照并以某种方式将其压缩 - 这就是我们通常所做的 - 或者在其他地方进行rsync。

如果您的文件系统或块设备不支持快照，那么您基本上遇到了麻烦。 您可以关闭数据库以进行备份，但我不认为您想这样做。

要恢复它，只需执行相反的操作然后重新启动并等待（可能需要一段时间）进行innodb恢复以解决问题。

maatkit mk-parallel-dump和restore工具比mysqldump好一点，速度方面 - 但我并不是100％相信它们的正确性

---

编辑：重新阅读问题，我认为文件系统快照+ rsync可能是最好的方法; 您可以在不影响实时系统的情况下执行此操作（您只需要转移自上次备份以来更改的内容）太多，如果连接失败，您可以恢复rsync，并且它将从中断处继续。

Answer 3

你需要数据库中的所有东西吗？

您是否可以将一些信息推送到存档数据库并在应用程序中添加一些内容，以便人们可以查看存档中的记录，

显然这很大程度上取决于您的应用和设置，但它可能是一个解决方案？ 你的数据库可能只会变得更大......