MySQL企业备份案例前言：上一篇分享了MySQL数据库的几种备份方式及其各自的特点。下面通过一个企业级备份案例，了解一下MySQL数据库的常见备份与恢复。（有不懂的可以参考小编主页上一篇文档：MySQL数据库的备份与恢复方法）案例：需求描述：某公司的用户信息数据库为client，用户tariff数据表为user_info，公司要求每周全量备份，每天增量备份。新增用户信息如下表所示：一、一般恢复1、添加数据库、表、输入信息。插入前三个用户的数据。如下图所示：2.首先进行全量备份。为了方便验证二进制日志的增量恢复功能，我们在插入三段用户数据后，先对客户端数据库的user_info数据表进行一次全量备份，然后在linux的命令行下执行系统“mysqladmin-uroot-pflush-logs”命令或执行“flushlogs;”在“mysql>”命令提示符下生成一个新的二进制日志。如下图：3、继续输入新数据，进行增量备份继续输入两个用户的数据，执行“mysqladmin-uroot-pflush-logs”命令刷新二进制日志，进行增量备份备份。这样二进制日志文件mysql-bin.000003中只保留插入两条用户数据的操作。如下图所示：4、模拟误操作删除user_info表5、恢复操作进行恢复操作时，需要先恢复全量备份，再恢复增量备份。二、基于位置的恢复1、既然上面已经做了恢复操作，那么我们第一步就是模拟删除user_info表的误操作，然后恢复全量备份。操作同上，此处略过。2.如果要根据位置或时间点恢复数据，首先要通过查看二进制日志文件来确定恢复的位置或时间点。使用“mysqlbinlog--no-defaultsbinarylogfile”查看日志文件的具体内容。如下图所示：通过查看日志文件的具体内容可以发现，每次操作前都会有一个唯一的编号，如“#at458”。这个数字随着操作次数的增加而变大，我们称之为操作ID。紧接在操作ID下方的是时间戳。根据位置或时间点恢复数据，需要分别依赖二进制日志文件中的操作ID或时间戳。例如，从二进制日志文件可以得知，当操作ID为“458”时，“王麻子”的用户数据被插入到user_info表中。因此，执行以下命令只能恢复操作ID为“458”之前的数据，即不会恢复“王麻子”的信息。此时恢复的数据是从二进制日志文件的起始位置到指定位置。如下图所示：上述操作命令中，“--stop-position”指定停止位置。如果只恢复“王麻子”的信息，跳过“赵六”的信息，可以使用“--start-position”选项指定从哪里开始恢复数据。此时恢复的数据是从指定位置到二进制日志文件的末尾。如下图所示：3.时间点恢复用于基于时间点恢复数据的选项是“--stop-datetime”，指定的时间也是通过查询二进制日志文件得到的.如下图所示：执行以下操作恢复“2:38:32”之前的数据，即不恢复“王麻子”的信息。时间点恢复也可以使用“--start-datetime”选项来指定开始恢复数据的时间。命令格式与location-basedrecovery相同，此处不再图示。4、制定企业备份策略的思路企业内部的备份策略并不统一，而是根据每个企业的实际生产环境和业务需求，制定合适的备份策略。无论选择全量备份还是增量备份，都需要考虑它们的优缺点，是否适合当前环境。同时为了保证恢复的完整性，建议开启二进制日志功能。二进制日志文件也给恢复工作带来了极大的灵活性，可以根据时间点或位置进行恢复。考虑到数据库的性能，我们可以将二进制日志文件保存到其他安全的硬盘上。热备份时，备份操作和应用服务同时运行，消耗大量系统资源，导致数据库服务性能下降。这就需要我们选择一个合适的时间，比如在应用负载较小的时候进行备份操作。需要注意的是，没有备份完就万事大吉了。最好确认备份是否可用。因此，需要备份后恢复测试，并灵活调整备份时间。例如：如果数据经常更新，就应该经常备份。数据的重要性，当有适当的更新时应该进行备份。备份应该在数据库压力较小的时间段进行，比如每周一次全量备份，每天一次增量备份。对于中小型公司来说，一般一天一次全量备份就够了。大公司可以每周做一次全量备份，每天做一次增量备份。尝试为企业实现主从复制架构，提高数据可用性。
