频繁的数据库备份工作流程答案

【问题标题】：Frequent database backup workflow频繁的数据库备份工作流程
【发布时间】：2018-09-03 21:50:16
【问题描述】：

我们有一个包含关键业务信息的数据库 (mysql) 驱动的应用程序，正在考虑构建一个允许我们经常（比如每 15 分钟）备份数据库的系统，以便我们减少任何风险数据丢失。在两种设置之间撕裂的地方：

每隔 15 分钟在 cron 上添加一个备份作业队列，并将这些备份存储在另一台服务器上。（为了节省空间，我们将在 3 天后删除大部分备份，但保留 06:00、12:00、18:00 小时的版本。）

或

是否有类似 RAID 的设置，我们的所有数据都会自动复制到另一个硬盘驱动器或在这种情况下是服务器，在这种情况下，如果我们丢失数据会发生什么情况，是否会将丢失的数据转移到另一台服务器（我们会还为我们的存档运行标准每日备份）？

或

还有另一种创建频繁备份的既定方法吗？

【问题讨论】：

【解决方案1】：

在我看来，最佳备份方案如下。

Delayed slave。它允许您在主故障的情况下快速恢复您的数据库。它可能在 DROP DATABASE 或其他错误 SQL 的情况下有所帮助。所以，你还需要一些额外的东西。
每天使用来自延迟从站的Xtrabackup 进行增量备份。或者，您还可以检查 TwinDB 以获取增量备份。
只要你需要 15 分钟的粒度，你就可以从 MySQL 5.6 的 mysqlbinlog 从 master 中提取二进制日志（即使 master 是 5.5 或 5.1）。因此，mysqlbinlog 在远程主机上运行，并从 master 拉取日志。

如果你需要恢复数据库，你有两种方法。

如果您可以从延迟的从站中恢复，则将该从站用作新的主站。
如果由于某种原因您不能使用延迟的从属设备（您错过了 DROP 命令），那么您从增量备份恢复昨晚的副本并应用自上次备份到事故发生时的二进制日志（再次，如果事故是错误的 DROP 表，您将重播日志直到 DROP 之前的最后一个事件。

从性能角度来看，此架构将是最佳的（对应用程序没有影响），并且根本不会丢失数据。

【讨论】：

【解决方案2】：

如果您的备份频率超过一小时，您需要的是replication。设置一个可以用作热备份的辅助数据库服务器比通过重复读取滥用数据库要好得多。

如果您经常备份数据库，请查看innobackupex 为您的表创建快照，或者可能查看LVM snapshots。

【讨论】：

我想支持复制解决方案，但另外我会做延迟从属。如果出现人为错误（意外的 DROP TABLE 等），您将有一些时间来防止在从站上执行错误的查询。检查 pt-slave-delay tool ，它可以做到percona.com/doc/percona-toolkit/2.1/pt-slave-delay.html
您当然可以按照 tadman 的建议使用 Xtrabackup 进行增量备份。但同样，它必须读取整个数据库才能找到自上次备份以来已更改的页面。因此，对于非常大的数据库，当普通读取需要超过 15 分钟时，您不能经常进行备份。
mylvmbackup 是一个很好的 LVM 快照工具，但在您的情况下，由于与使用 XtraBackup 进行增量备份相同的原因，它可能无法正常工作。