MySQL数据库的备份案例

MySQL企业备份案列

前言：上篇文档分享了 MySQL 数据库的几种备份方法，以及各自的特点。下面我们通过一个企业级的备份案例了解一下MySQL数据库的常见备份和恢复。（如果有看不懂的地方，可以参考小编主页的上篇文档： 怎么对MySQL数据库进行备份与恢复 ）

案例：

需求描述：某某公司的用户信息数据库为client，用户资费数据表为user_info，该公司每周需要进行完全备份，每天需要进行增量备份。新增的用户信息如下表所示：

一、一般恢复

1.添加数据库、表、录入信息

在进行备份前，先根据需求创建用户信息数据库client、用户资费数据表user_info，并且根据需求描述中的表格插入前三条用户的数据。 如下图：

2.先进行一次完全备份

为了方便验证二进制日志的增量恢复功能，我们在插入三条用户数据后先对client数据库的user_info数据表进行一次完全备份，然后在 linux 系统命令行下执行"mysqladmin -u root -p flush-logs"命令或在"mysql>"命令提示符下执行"flush logs；"生成新的二进制日志。如下图：

3.继续录入新的数据并进行增量备份

继续录入两个用户的数据，并执行"mysqladmin -u root -p flush-logs"命令刷新二进制日志，进行增量备份。这样，二进制日志文件mysql-bin.000003中仅保留插入两个用户数据的操作。如下图：

4.模拟误操作删除user_info表

5.恢复操作

执行恢复操作时，需要先恢复完全备份，然后恢复增量备份。

二、基于位置恢复

1.由于上面已经做过恢复操作了，所以我们 第一步还是模拟误操作删除user_info表，然后恢复完全备份。 操作同上，这里就略过了。

2.想要实现基于位置或时间点恢复数据，必须先通过查看二进制日志文件确定恢复的位置或时间点。使用" mysqlbinlog --no-defaults 二进制日志文件 "可以查看日志文件的具体内容。如下图：

通过查看日志文件的具体内容可以发现，在每进行一个操作之前都会有一个独特的编号，如"# at 458"。此编号随着操作数增多而变大，我们称之为操作ID。在操作ID下面紧跟着的是时间标记，要实现基于位置或时间点恢复数据，需要分别依赖二进制日志文件中的操作ID或者时间标记。例如，通过二进制日志文件可以得知，在操作ID为"458"的时候，user_info表中插入了"王麻子"的用户数据。因此执行以下命令可以实现仅恢复到操作ID为"458"之前的数据，即不恢复"王麻子"的信息。这时所恢复的数据是从二进制日志文件的开始位置直到指定位置。如下图：

上述操作命令中，"--stop-position"指定的是停止的位置，如果仅恢复"王麻子"的信息，跳过"赵六"的信息，可以使用"--start-position"选项指定开始恢复数据的位置。这时所恢复的数据是从指定位置开始直到二进制日志文件的最后。如下图：

三、基于时间点恢复

基于时间点恢复数据所使用的选项是"--stop-datetime"，指定的时间同样也是查询二进制日志文件所得。

如下图：执行以下操作可以实现恢复到"2:38:32"之前的数据，即不恢复"王麻子"的信息。

基于时间点恢复同样也可以使用"--start-datetime"选项指定开始恢复数据的时间，命令格式与基于位置恢复的格式一样，这里就不再给图了。

四、制定企业备份策略的思路

在企业中备份策略并不是千篇一律的，而是根据每个企业的实际生产环境与业务需求指定合适的备份策略。无论是选择完全备份，还是选择增量备份，都需要考虑它们的优缺点，是否适合当前的环境。同时，为了保证恢复的完整性，建议开启二进制日志功能，二进制日志文件给恢复工作也带来了很大的灵活性，可以基于时间点或位置进行恢复。考虑到数据库性能，我们可以将二进制日志文件保存到其他安全的硬盘中。

在进行热备份时，备份操作和应用服务在同时运行，这样就十分消耗系统资源了，导致数据库服务性能下降，这就要求我们选择合适的时间，如，在应用负担很小的时候在进行备份操作。

需要注意的是，不是备份完就万事大吉了，最好确认备份是否可用，所以，备份之后的恢复测试是很有必要的，同时备份时间也要有灵活调整。如：

• 数据更新频繁，则应该频繁的备份
• 数据的重要性，在有适当更新时进行备份
• 在数据库压力小的时间段进行备份，如一周一次完全备份，每天进行增量备份。
• 中小公司，完全备份一般一天一次即可
• 大公司可每周进行一次完全备份，每天进行增量备份
• 尽量为企业实现主从复制架构，以增加数据的高可用性