多年来,我一直在不同的环境中使用中小型数据库(1 G 到 100 G)进行此操作。快速而肮脏的mysqldump 适用于较小的数据集;它们越小越好。
当您超过 5-10 GB 时,根据 MySQL 负载,quick and dirty 不再削减它。
为什么mysqldump 可能还不够
MySQLdump 的问题在于,当它转储时,活动数据库要么无法使用,要么使用起来非常尴尬,要么备份将不一致。除非您有足够宽的时间窗口,此时实时数据库的不可用并不重要,因为无论如何都不需要使用数据库(例如,深夜)。
默认选项(here 讨论原因)使数据库在转储时几乎无法使用,除非使用只是读取数据而已。在一个繁忙的电子商务网站上,您正面临客户堆积如山的崩溃。
所以你使用 InnoDB 和现代选项(据我所知,不是默认值)
--single-transaction --skip-lock-tables
这允许站点在转储期间运行,尽管比正常速度慢。根据使用情况,它可能会明显变慢。
当您使用它时,还可以转储其他可能很重要的数据:
--events --triggers --routines
(...哦,这仍然不会转储用户权限。用作测试可能并不那么重要)。
有一个我发现“建议”(!)作为“伟大的黑客”的解决方法,它基本上禁用事务完整性允许数据库在转储时全速运行。有点像从你的车上卸下刹车来减轻它的重量并让它跑得更快,是的,它会起作用,但它会有一些你可能不会立即注意到的副作用。你会几乎肯定迟早会注意到它们 - 就像刹车一样,它会是你最需要它们的时候,而且它不会很漂亮。
但是,对于 test 数据库,它仍然可以工作。
Xtrabackup
如果你有一个“严肃”的数据库,为什么没有a "serious" backup?
从属复制
如果您有多余的空间(现在 20 Gb 并不多),另一种可能性是使用辅助数据库。
您可以在不同端口上的同一服务器上安装第二个 MySQL 服务器副本,并让它成为从属服务器(服务器将在存储速度方面受到性能影响)。然后你将拥有两个相同的数据库(live master,live slave)。 第一次您仍然需要运行完整转储以使它们同步,其中涉及的所有问题。
当您需要克隆测试数据库时,停止从属复制 - 活动从属现在将及时保持“冻结”状态 - 并使用 MySQLbackup 或仅复制数据文件将活动从属备份到测试数据库。完成后,重新启动复制。
对活动主节点的影响可以忽略不计,从节点实际上可以用于非更新关键选择。