无预算的MySQL备份

我目前的MySQL备份scheme是将我们的数据库复制到第二个服务器,并在该服务器上运行mysqldump,以从表或行locking中删除任何停机时间。 这种方式运行良好,但第二台服务器每月花费150美元(澳大利亚托pipe比美国贵得多)。

我在这里读到很多关于这个问题的问题,大多数人需要帮助,而不是我需要的。 我需要mysqldump(最好每隔4小时),不要停机。 该数据库是约7GB的未压缩,所以mysqldump可能需要一些时间取决于服务器。

我已经考虑复制到同一台机器上,但是我不想让奴隶吃掉急需的记忆。 我不确定我可以限制每个分贝的内存使用量? 无论哪种方式,这将把负载在服务器上,而其倾销数据库。

我刚刚读了这个http://www.zmanda.com/quick-mysql-backup.html ,它看起来不错,每年$ 300是好的,这节省了我很多。

不幸的是我不能复制到亚马逊的RDS,但我可以复制到一个微型的RC2实例,但复制将发生在网上,并ping是〜220毫秒。

我在这里看到一些人在谈论LVM快照,这可能是一个不错的select。 我不知道这个选项很多。

意见将不胜感激。

如果你使用innodb表,你可以使用

http://www.percona.com/docs/wiki/percona-xtrabackup:start

这将需要转储数据库,可以通过他们的工具导入也不locking。 我相信如果你有myisam表,它locking这些。

如果您正在使用innodb或其他完全事务化的后端,则可以使用mysqldump --single-transaction ... 我在相当大的(〜100GB)数据库上使用了这个结果, 如果数据库负载很重,可能需要几个小时,但是它不会locking你的表。 复制通常更好,但有时候你需要一个很好的固体转储文件。 请记住,您也可以转储一个mysql复制从服务器。

从mysqldump页面(注意关于将泄漏到事务中的操作的说明):

  · --single-transaction This option sends a START TRANSACTION SQL statement to the server before dumping data. It is useful only with transactional tables such as InnoDB, because then it dumps the consistent state of the database at the time when BEGIN was issued without blocking any applications. When using this option, you should keep in mind that only InnoDB tables are dumped in a consistent state. For example, any MyISAM or MEMORY tables dumped while using this option may still change state. While a --single-transaction dump is in process, to ensure a valid dump file (correct table contents and binary log coordinates), no other connection should use the following statements: ALTER TABLE, CREATE TABLE, DROP TABLE, RENAME TABLE, TRUNCATE TABLE. A consistent read is not isolated from those statements, so use of them on a table to be dumped can cause the SELECT that is performed by mysqldump to retrieve the table contents to obtain incorrect contents or fail. 

在美国,通过高延迟连接到廉价的VPS,我看不到什么问题。高延迟不应该成为一个问题。 复制被devise成即使在从属设备落后几小时时也能快速赶上,即它可以asynchronous操作。

只要你能忍受你的澳大利亚托pipe计划多出去的带宽。

这是对高延迟是否重要的​​更详细的回应

实际上,只有实际导出数据库的时间才是停机时间。 在足够慢的时间内完成,不应该有任何问题。 这个预算的IT部门真正期待什么?

您应该能够在5-10分钟内将mysqldump一个7GB的数据库MAX,取下读/写锁,停机时间结束。 然后,您可以find7GB文件到新服务器的最有效的带宽方式(读取:HIGH COMPRESSION)。 您有足够的时间在新服务器上将文件传输并导入到MySQL中。 然后,inputmasterlog信息并开始复制。 应该是小菜一碟!

MySQL的文档是奇妙的 : http : //dev.mysql.com/doc/refman/5.0/en/replication.html

我不确定我可以限制每个数据库的内存使用量

当然你可以 – 你只需要用不同的/etc/my.cnf来运行slave

你甚至可以使用nice / renice和taskset(假设它是一个Linux服务器)来操作主从机上的调度优先级/ CPU关联性。

但复制将发生over-net,并且ping是〜220ms

延迟几乎不相关 – 重要的是带宽 – 数据库带宽(假设您没有复制会话数据)比HTTP带宽低几个数量级。

我需要[创build数据库的一致备份](最好每隔4小时),不要停机

但是你讨论的策略不能像那个时候那样恢复。

我认为最便宜的select将是同一台机器上的奴隶 – 如果它对性能产生负面影响,超出了你可以重新configuration的范围,那么升级当前的托pipe软件包。

你也可以考虑运行一个断开的slave:在当前服务器上启用bin日志。 获取一个备份,在本地机器上恢复备份,然后拷贝bin日志,并在本地DBMS上转发它们 。

我的build议:

1 – 保持你的第二个帐户/服务器,并实现复制到原来的帐户/服务器的数据库。

2 – 停止复制到第二个帐户/服务器。

3 – 监视几天的performance。 确保你监视它足够长的时间,以包括你最繁忙的时期。

4 – 如果出现重大性能问题,请准备切换到旧的设置。 这就是你保留第二个帐户的原因。

5 – 在您的原始帐户购买更多的容量/升级服务器。 这应该比支付我相信两台服务器便宜。

6 – 取消第二个帐户。

祝你好运!