3种mysql备份恢复方案优劣对比 _mysql

文章插图

前言这周又是上线周。办公桌的头发越来越多了，保温杯都是枸杞，电脑壁纸也换成了应急逃生通道（不要问我为什么是应急通道，因为打算随时跑路）。
因为是新系统要与旧系统之间进行数据同步，清洗，分发。所以，这周任务是不断地核实数据，调试程序，与数据库打交道的占比很高。
一旦要到数据库这个话题，永远也避不开数据安全的问题。所以今天我就来讲讲怎么使用 MySQL 的备份与恢复。
抛出本文问题
首先，在讲 MySQL 备份之前，我想明确咱们接下来需要探究的问题

备份这么麻烦，但是为什么值得我们去做？
多得一批的备份术语
我们究竟需要备份什么？
备份需要考虑什么因素？
备份的方案有哪些？
实践

知识背景
为什么我们需要备份？
时间是往前流动的，人生是不可逆转的，但是数据库能。我想说几个场景你是否还很熟悉？

线上项目因为 Bug 或客户骚操作的问题，导致业务数据缺失，流程无法继续走下去，没有回头了只硬着头皮线上改数据，结果表一多起来，改了那条都不知道了
上线前从旧系统迁移数据，为上线做准备，结果一执行清洗 SQL，哎呀，IS NOT NULL 忘了改回了 IS NULL，含泪全库删除，重新导库清洗；
新同事在服务器执行了技术大佬传授真经命令行 rm -rf /*，结果我赶紧给他发了一张高清的紧急逃生通道...

所以说，为什么我们要备份？因为我们要做到无所畏惧，有路可退。在风险面前，我们尽能力去规避风险。这些风险，小到不小心在别的服务器执行了 Alter Table，大到服务器硬件出现故障，全机崩溃，软件硬件故障/自然灾害/人为操作等等。

所以我们需要备份是为了应对来自各方面的威胁

多得一批的备份术语
说起备份，可能你的头脑里浮现了热备份/冷备份/增量备份/差异备份/逻辑备份...放弃的声音席卷而来！
其实先不要害怕这些术语，它们都是有专门的由来的。
首先是热备份，温备份和冷备份。热备份指的是不需要停止任何服务即可备份，就好像你备份不用关掉数据库来备份，随时随地可进行;冷备份指的是停止数据库进行数据备份。
然后全量备份和部分备份。

全量备份(类似名字还有全局备份，完全备份)指的是将整个数据库备份下来。显然当项目数据达到一定规模，那么整库备份变得不现实，因为备份时间变得更长，同时需要更多地磁盘资源，机器资源...
部分备份指的是将部分数据集备份下来，例如备份某库某表某个时间段的数据，或者是仅仅备份某库某表的所有数据。部分备份一般不包含完整的数据集，而我们明显可以仅仅备份所更改的数据，这样可以减少服务器的开销/备份时间/备份空间。根据部分备份的概念，我们可以拆分成两种备份方式：增量备份和差异备份，下面使用表格说明：

名称说明增量备份对自上次全备份后所有改变的部分而做的备份差异备份自从任意类型的上次备份后所有修改做的备份
举例说明，假设在周日做了一个全量备份。在周一，对自周日以来所有的改变做一个差异备份。在周二，你有两个选择：备份周日以来所有的改变(差异备份)，或只备份自从周一备份后所有的改变(增量备份)
我们究竟需要备份信息？
可能说到这个问题上，大多数人第一反应就是备份表结构+表数据。恭喜你，你猜对了一半，但是这个方案是备份中最低的要求，因为在数据库中还存在很多被忽略的数据在默默支撑着数据库的正常运行。下面介绍一下数据库哪些值得关注的数据：
类型内容非显著信息二进制日志和 InnoDB 事务日志代码触发器和存储过程复制配置二进制日志/中继日志/日志索引文件/.info 文件服务器配置服务器的配置文件选定的操作系统文件对生产服务器至关重要的外部配置。在 unix 服务器上，可能包括了 cron 任务/用户和组的配置/管理脚本/sudo 规则等