高逼格企业级MySQL数据库备份方案，原来是这样....

很多人，这里说的是运维工程师们，一提到写某某方案，很是头疼。不是上某度一统搜索，就是同样一句话在N个群全部群发一遍：“有没有某某方案，可以共享一下的吗？？求助，各位大佬们”，估计十有八九，全部石沉大海，杳无音讯。

其实，到底是真的很难，还是说你没有完全掌握整个备份思路的整理？一个方案的好坏，在于对于外行人来说，能不能一眼就能看懂其中要表达的意思，而且不需要很多的思考就可以。

一份好的备份方案无非包括以下几点：

• 为什么需要备份？

• 备份的方式有哪些？

• 某几种备份方式的区别在哪？

• 备份实战操作概述

• 恢复实战操作概述

• 其它备注信息

那么，此文将从以上几个角度，结合一些实际的实战经验，分步阐述一个完整的备份方案到底是怎么样构成的。需要学习更多Mysql数据库相关的知识，可以在公众号：民工哥技术之路的后台回复「MySQL」即可获取一份最全的MySQL数据库学习指南。

为什么需要数据库备份？

很多人，一看这标题，肯定张口就会答，这不是废话么。不备份故障了怎么办？跑路吗？数据被沙雕开发（不许喷）误删了怎么办？背锅吗？

当然，大家都知道备份的重要性与必要性。

1、保证数据安全与完整

企业的数据安全应该来说是企业的命脉，一旦丢失或造成损坏，轻则损失客户与金钱，重则倒闭（已经有前例在）。

备份的目的：为了保证数据在被人为失误、操作不当、蓄意等情况下删除或损坏后，能及时、有效的进行恢复并不会很大程度上影响到业务运行。

2、为业务提供不间断服务

实际生产环境对数据库的要求，首先就是具备7×24×365不间断服务的能力，这也是一定要备份数据库的其中原因之一。

数据库的备份方式

常用的备份方式包括以下：

• 逻辑备份

• 物理备份

1、逻辑备份

逻辑备份其实就是利用MySQL数据库自带的mysqldump命令，或者使用第三方的工具，然后把数据库里的数据以SQL语句的方式导出成文件的形式。在需要恢复数据时，通过使用相关的命令（如：source ）将备份文件里的SQL语句提取出来重新在数据库中执行一遍，从而达到恢复数据的目的。

实例如下：

mysqldump -A -B --single-transaction >/server/backup/mysql_$(date +%F).sql

一般备份时都会进行压缩处理，以节省磁盘空间，如下

mysqldump -A -B --single-transaction ｜gzip>/server/backup/mysql_$(date +%F).sql.gz

恢复操作

cd /server/backup/gzip -o mysql_$(date +%F).sql.gz

mysql -uroot -pMyadmin -h mysqldb.mingongge.com

> source /server/backup/mysql_$(date +%F).sql

逻辑备份的优点与使用场景

优点：简单，易操作，自带工具方便、可靠。

使用场景：数据库数据量不大的情况可以使用，数据量比较大（超过20G左右）时备份速度比较慢，一定程度上还会影响数据库本身的性能。

2、物理备份

物理备份就是利用命令（如cp、tar、scp等）直接将数据库的存储数据文件复制一份或多份，分别存放在其它目录，以达到备份的效果。

这种备份方式，由于在备份时数据库还会存在数据写入的情况，一定程度上会造成数据丢失的可能性。在进行数据恢复时，需要注意新安装的数据的目录路径、版本、配置等与原数据要保持高度一致，否则同样也会有问题。

所以，这种物理备份方式，常常需要在停机状态下进行，一般对实际生产中的数据库不太可取。因此，此方式比较适用于数据库物理迁移，这种场景下这种方式比较高效率。

物理备份的优点及使用场景

优点：速度快，效率高。

场景：可用于停机维护及数据库物理迁移场景中。

实际生产环境中，具体使用哪种方式，就需要看需求与应用场景所定。

全量与增量备份概述

在介绍完备份方式之后，再来介绍一下，增量与全量备份这两个概念。

什么是全量备份？

全量备份：就是将数据库中的所有数据，或者是某一个特定的库里的所有数据，一次全部备份下。

备份数据库中所有数据

mysqldump -A -B --single-transaction ｜gzip>/server/backup/All_data_$(date +%F).sql.gz

备份某个库的数据

mysqldump -A -B --single-transaction testDB1｜gzip>/server/backup/testDB1_$(date +%F).sql.gz

什么是增量备份？

增量备份：指的是上一次全量备份之后到下一次全量备份这前这段时间内数据库所更新或者是增加的数据，将其备份下来。

注：全量备份是一个文件，而增量备份则是MySQL的binlog日志文件。所以常说的增量备份就是备份binlog日志文件。

两者的区别在哪？

全量备份：需要的备份时间长一点，恢复时间会短一点，因为文件数少，维护方便。但是，全量备份的文件大，占用一定的磁盘空间，全理备份时会一定程序上影响数据库的性能（这也就是为什么在0:00点备份的原因），也因文件大的原因，不便于服务器本地保存过多文件，重要业务的全量备份文件可能需要手工下载或迁移到服务器之外的存储空间中。

增量备份：备份简单，恢复时复杂一点，因为文件数量多，需将所有binlog文件解析成SQL语句，如下：

mysqlbinlog testDB1-bin.000001 testDB1-bin.000002 >./bin.sql

然后，再通过恢复的方式进行恢复

mysql -uroot -pMyadmin -h mysqldb.mingongge.com

> source /server/backup/bin.sql

或者如下操作

cd /server/backup

mysql testDB1 <./bin.sql

备份与恢复实践操作

对于Mysql数据库的备份，一般采取脚本+定时任务进行日常备份。

常用执行策略是：

• 每天0:00执行一次全量备份

• 按业务需求执行增量备份

分享一个我在一个创业公司初期的一个备份方案实例

阿里云数据库服务器备份方案

方案一：

目前数据库是主从同步，从库开启binlog日志功能进行异地备份，就目前数据量而言，只需要在从库的基础上进行定时全量与增量备份数据库即可。

1、创建备份目录

mkdir /server/backup

2、备份数据库到指定目录

mysqldump --single-transaction -F -B phoenix_coupon_production|gzip >/server/backup/phoenix_$(date +%F).sql.gz

mysqldump --single-transaction -F -B ywotx|gzip >/server/backup/ywotx_$(date+%F).sql.gz

find /server/backup/ -type f –name “*.sql.gz”-mtime +7 |xargs rm-f

将脚本写入定时任务，分时段进行打包备份 

3、定时备份二进制文件

通过参数刷新binlog产生新的文件，通过脚本判断文件新旧，然后备份旧的日志文件
mysqladmin -uroot -pywotx!123 flush-logs #刷新日志，产生新的日志文件

最终将备份文件同步或定时手工下载到异地备份服务器异地存储备份文件，实现数据库备份文件双备份存储，防止服务器硬件故障。

方案二

后期数据量增大之后，数据库需要进行读写分离，实现主写，从读，主从同步的架构，备份还是按照原来的备份方案进行，可采用分库分表进行数据备份，防止数据量大导致的恢复时间的问题，提升恢复效率。

1、创建备份目录

Mkdir /server/backup

2、备份数据到指定目录( 分库分表)
#/bin/sh
#create by mingongge at 2017-06-01
BACKUPDIR=/server/backup
DATE=`date +%F`
USER=root
PASSWD=”123456”
CMD=”mysql –u$USER –p$PASSWD”
DUMPCMD=”mysqldump –u$USER –p$PASSWD --single-transaction -F”

for dbname in `${CMD} –e “show databases”|sed ‘1d’`
do
mkdir –p${BACKUPDIR}/${dbname}
for tablename in`${CMD} –D ${dbname} –e “show tables”|sed ‘1d’`
do
${DUMPCMD} --tables${dbname} ${tablename} |gzip > ${BACKUPDIR}/${dbname}/${tablename}_$(DATE).sql.gz
done
done

find /server/backup/${dbname} -type f –name “*.sql.gz”-mtime +7|xargs rm -f

3、定时备份二进制文件（增量）
备份方法同方案一

备份频率：

• 每天0:00进行一次数据库全备

• 每天03:00  9:00  15:00 21:00 增量备份一次

数据库的备份，每天一次全备，在全备时会更新binlog日志，重新生成新的日志文件，因此在下一次增量备份时再刷新binlog,再次产生新的日志文件，实现从全备之后对数据库的操作的增量备份，一旦发现数据问题，立即刷新binlog重新成新的日志文件，将原来的日志文件手工备份一份，然后找出产生数据问题的点，从而利用日志文件进行恢复全备到产生数据问题点之间的数据,然后恢复从问题点到发现问题时间段之间的数据.

新增一台备份服务器，配置如下：

实例配置：2核/4G/40G + 200G高效云盘 经典网络 1M  295元/月

方案总结：

对于数据库服务器本地的备份文件基本上只保留一周时间内的数据，备份服务器按需求（一般保留至少30天的数据），保留30天的数据包括数据库全备文件与增量备份文件，后期可按实际生产需求进行修改，保留时间长短只会增加相应的服务器磁盘空间，增加一定的成本，其它无需改动，操作较为灵活、方便。