按预算实现永不过时的MySQL备份

我当前的MySQL备份方案是将数据库复制到第二台服务器，并在该服务器上运行mysqldump，以删除表或行锁定中的所有停机时间。这工作得很好，但是第二台服务器每月的费用为150美元（澳大利亚主机比美国贵得多。）

我在这里读到很多问题，大多数人都需要计划备份的帮助，而这不是我所需要的。我需要没有停机的mysqldump（最好是每4小时）。db是未压缩的〜7GB，因此mysqldump可能需要一些时间，具体取决于服务器。

我曾考虑过复制到同一台机器上，但是我不希望奴隶吃掉急需的内存。我不确定我是否可以限制每个数据库的内存使用量？无论哪种方式，这都会在服务器转储数据库时给服务器增加负载。

我刚刚读了这个http://www.zmanda.com/quick-mysql-backup.html，它看起来不错，每年$ 300可以，可以为我省很多钱。

不幸的是，我无法复制到Amazon的RDS，但可以复制到微型RC2实例，但是复制将通过网络进行，并且ping约为220毫秒。

我在这里看到一些人在谈论LVM快照，这可能是一个不错的选择。我对这个选项不了解很多。

意见将不胜感激。

如果使用innodb表，则可以使用

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

这将转储您的数据库，这些数据库也可以由其工具导入而无需锁定。我相信，如果您有myisam表，它将锁定那些表。

如果您使用的是innodb或具有完全事务性的另一个后端，则可以使用mysqldump --single-transaction ...。我已经在相当大的数据库（〜100GB）上使用了它，并且效果很好。如果数据库负载沉重，则可能要花费数小时，但它确实可以工作而不会锁定表。复制通常更好，但有时您需要一个不错的可靠转储文件。请记住，您也可以转储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时，我看不出太多问题。高延迟实际上并不是什么大问题。复制被设计为即使从站落后几个小时也能快速追赶，即它可以异步运行。

只要您能在澳大利亚托管计划中承受那么多的传出带宽。

这是关于高延迟是否重要的​​更详细的响应

实际上，只有实际导出数据库所需的时间才是停机时间。在足够慢的时间内执行此操作，应该没有任何问题。该预算中的IT部门真正期望什么？

您应该能够在最多5-10分钟内mysqldump 7GB数据库，并取消读/写锁定，停机时间将结束。然后，您可以找到将7GB文件传输到新服务器的最有效带宽方法（阅读：HIGH COMPRESSION）。您有足够的时间将文件传输并导入到新服务器上的MySQL中。然后，输入masterlog信息并开始复制。应该是小菜一碟！

MySQL文档太棒了：http : //dev.mysql.com/doc/refman/5.0/en/replication.html

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

当然可以-您只需要使用其他/etc/my.cnf运行从属服务器

您甚至可以使用nice / renice和tasket（假设它是Linux服务器）在主服务器和从服务器上做一些事情来操纵调度优先级/ CPU关联性。

但是复制将通过网络进行，并且ping约为220毫秒

延迟几乎是无关紧要的-重要的是带宽-数据库带宽（假设您不复制会话数据）比HTTP带宽小几个数量级。

我需要[创建数据库的一致备份]（最好每4小时一次），而无需停机

但是您讨论的策略不允许在那个时候恢复。

我认为最便宜的选择将是同一台计算机上的从服务器-如果它对性能的不利影响超出您可以重新配置的范围，请升级当前的托管程序包。

您可能还考虑运行断开连接的从属服务器：在当前服务器上启用bin日志。获取备份，将备份还原到本地计算机上，然后在bin日志旋转时复制它们，并在本地DBMS上向前滚动它们。

我的建议：

1-保留第二个帐户/服务器，并实现到原始帐户/服务器中数据库的复制。

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

3-监控几天的效果。确保对其进行足够长时间的监视，以包括最繁忙的时段。

4-如果存在重大性能问题，请准备好切换到旧设置。这就是您保留第二个帐户的原因。

5-在原始帐户中购买更多容量/升级服务器。我认为这应该比购买两台服务器便宜。

6-取消第二个帐户。

祝好运！