MySQL企业级备份

时间 2020-05-26

标签 mysql 企业备份栏目 MySQL 繁體版

原文原文链接

1.数据库管理员的两大工做核心

1.1.可以让数据安全获得保护

所谓的数据安全，最容易被人误觉得是只有数据丢失，其实还包括数据被脱库、泄密等方面。mysql

**1.2.能7*24小时提供服务**

数据库具有7*24小时提供服务的能力，是数据库管理员的重要职责。sql

2.全量备份和增量备份

2.1.全量备份的概念

全量数据就是数据库中全部的数据（或某一个库的所有数据）；全量备份就是把数据库中全部的数据进行备份。数据库

备份数据库中全部库的全部数据：vim

mysqldump -B --master-data=2 --single-transaction -A |gzip >/opt/all.sql.gz

备份oldboy一个库中全部数据：安全

mysqldump -B --master-data=2 --single-transaction oldboy |gzip >/opt/oldboy.sql.gz

2.2.增量备份的概念

增量数据就是指上一次全量备份数据以后到下一次全量备份以前数据库所更新的数据。在使用mysqldump命令作全备时，增量数据就是MySQL的binlog日志，所以，对binlog日志的备份在此处就能够称为增量备份，固然，有些工具自己就能够实现全量以及增量数据备份，例如Xtrabackup。bash

2.3.全量与增量如何结合备份

2.3.1.按天全备与增量备份数据

周一00点全量备份	周二00点全量备份	周三00点全量备份	......
01.sql.gz	02.sql.gz	03.sql.gz	......
周一增量备份	周二增量备份	周三增量备份	......
mysql-bin.00002一、......	mysql-bin.00003五、......	mysql-bin.00004九、......	......

按天全备的特色：服务器

一、优势：恢复数据时须要的数据文件数量少，恢复时间短，维护成本低。
二、缺点：天天一个全备，占用空间多，占用系统资源多，常常备份会影响用户体验。

中小企业用得最多的策略就是按天全备，而后根据空间状况保留全备份数，例如仅保留7天内的备份数据，若是企业数据很重要，则可使用磁带机等设备留存一年以上的备份数据。架构

binlog增量的清理能够经过在my.cnf中配置“过时清理天数”的相关参数（expire_logs_days=7）来实现，例如保留7天内的binlog日志，理论上若是天天进行全备，那么binlog只要保留1天的。app

2.3.2.按周全备与增量备份数据

每周一00点全量备份
01.sql.gz
周一增量备份	周二增量备份	周三增量备份	一直到下周日增量备份
mysql-bin.00002一、......	mysql-bin.00003五、......	mysql-bin.00004九、......	......

按周全备的特色：tcp

一、优势：每周仅有一个完整备份，所以占用磁盘总空间小，占用系统资源少，备份次数少，用户体验好一些。
二、缺点：恢复时数据文件多，致使恢复麻烦，维护成本高，恢复时间长。

大型企业因为数据量特别大，天天全备时间太长，所以有可能会采用周备的策略，这样不只有利于节省数据存储空间并且不会影响用户访问数据库的体验。

3.MySQL经常使用的备份方式

MySQL备份的经常使用方式有逻辑备份和物理备份。

3.1.逻辑备份方式

3.1.1.逻辑备份

MySQL的逻辑备份其实就是使用MySQL自带的mysqldump命令或其余相关工具，把MySQL数据以SQL语句的形式导出或备份成文件。在恢复的时候则经过执行mysql恢复命令（或source等）将存储的SQL语句文件数据还原到MySQL数据库中。

实现逻辑备份的经常使用工具为MySQL自带的mysqldump命令，备份全部库：

mysqldump -A -B --master-data=2 --single-transaction |gzip >/opt/all.sql.gz

恢复数据库的方法之一为：

zcat opt/all.sql.gz|mysql

使用此种逻辑备份方式进行全量备份后的增量数据就是数据库记录的binlog日志文件，那么，如何增量恢复binlog日志呢？mysqlbinlog工具能够把binlog日志转换成SQL语句，而后经过mysql恢复命令（或source等）将SQL语句还原到MySQL数据库中。

恢复增量数据：

mysqlbinlog mysql-bin.000008 mysql-bin.000009 >bin.sql  #将binlog文件解析为SQL语句
mysql <bin.sql  #恢复到数据库

3.1.2.逻辑备份的特色

逻辑备份的优势为操做简单、方便、可靠，而且备份的数据能够跨平台、跨版本、甚至跨软件、跨操做系统，还能够实现分库分表备份；逻辑备份也有必定的缺点，例如，备份速度比物理备份慢、恢复的效率也不是特别高等。

3.1.3.逻辑备份的经常使用工具

mysqldump是MySQL官方自带的最经常使用的逻辑备份工具，还能实现分表分库备份，还有一个mydumper工具，它是一个在GPL许可下发布的高性能MySQL备份和恢复工具集。

3.1.4.逻辑备份的企业应用场景

适用于数据量不是特别大的场景，打包前不大于30GB的数据库数据，30GB的值主要是考虑备份效率的问题，以及管理员使用复杂度的平滑。不过，在跨版本、跨软件升级或迁移数据的时候，此时物理备份通常就不能使用。

3.2.物理备份方式

3.2.1.物理备份

3.2.1.1.冷备方法

MySQL的物理备份方法之一是使用cp、rsync、tar、scp等复制工具把MySQL数据文件复制成多份，因为在备份期间数据仍然有写入操做，因此，直接复制的备份方式会引发数据丢失。另外在恢复数据库时，对新数据库的路径、配置也有要求，通常要和原库的配置保持一致（版本、路径、配置尽量同样）。

为了确保备份期间数据的一致性，能够选择人工停库或者锁库后再进行物理复制，而这在生产环境中通常是不容许的，除非是能够申请停机或锁表时间，因此使用传统Linux命令复制工具仍是比较粗的冷备份方式，应避免使用。

通常在进行大规模数据库迁移时，先停库，而后物理迁移，这样作是颇有效率的方案。

3.2.1.2.热备方法

除了在Linux命令行经过命令直接复制MySQL数据文件以外，还有一些其余的第三方的开源或商业物理热备份工具，如Xtrabackup。使用这个工具能够实现物理全备及增量备份。

3.2.2.物理备份的特色

物理备份的优缺点正好与逻辑备份相反，所以在企业里应根据需求，互补使用。

一、优势：速度快，效率高。
二、缺点：不容易跨平台、跨版本、跨软件、跨操做系统，能够实现分库分表备份，但恢复时会麻烦不少，软件的使用也比较复杂一些。

3.2.3.物理备份的经常使用工具或方法

Linux下冷备份工具为cp、tar，备份时须要锁表或者停库以确保数据的一致性；开源的热备份（基于InnoDB）工具则是Xtrabackup。

3.2.4.物理备份的企业应用场景

数据库总数据量超过30GB的，可以使用Xtrabackup热备工具进行备份，以提高效率。

能够选择在数据库的从库上进行备份，备份时中止SQL线程应用数据到数据库，而后经过cp或tar打包备份，这也是一种不错的冷备方案，不会影响数据库的服务。

3.3.物理备份与逻辑备份的区别

物理备份与逻辑备份的对比：

	逻辑备份	物理备份
备份原理	以SQL语句的形式	直接复制磁盘物理文件或其余非SQL语句方式的备份
相关命令	mysqldump、mysql、mysqlbinlog	cp、rsync、tar、scp、Xtrabackup（热备）
备份要求	须要锁表但不须要停库。锁表会影响数据库更新，InnoDB引擎能够不锁表，而采用事务备份方案	冷备须要锁表或停机，热备不须要锁表（仅事务引擎，例如InnoDB）或停机
配置特色	恢复时与系统版本、库的配置基本版本无关	物理复制须要系统、配置、版本尽量地一致
性能特色	速度慢	速度快
方便性考虑	安全、易掌握、容易控制，通常不会丢失数据	冷备简单，但应用场景少，热备工具操做复制一些，较难掌握

4.逻辑备份的企业级应用

4.1.中小企业的MySQL备份实战

4.1.1.中小企业全备备份策略与应用

中小企业通常会采用逻辑备份，经常使用的工具就是mysqldump命令，备份的策略通常是每日进行全量备份，备份会选择在数据库业务流量低估时执行，备份时能够锁表或者采用事务方式备份。

简单的备份脚步：

vim bak.sh
#!/bin/bash
export PATH=/application/mysql/bin:/usr/local/bin:/sbin:/bin:/usr/bin
bak_path=/server/backup
[ ! -d $bak_path ] && mkdir -p $bak_path  #若备份路径不存在则建立
mysqldump -B -A --master-data=2 |gzip >$bak_path/${file_name}.sql.gz  #若是仅为innodb引擎，则能够再加上--single-transaction参数
rsync -az $bak_path/ rsync_backup@172.16.1.31::mysql/ --password-file=/etc/rsync.password
#备份完成后马上推送至备份服务器，须要提早部署rsync服务
find $bak_path/ -type -f -name "*.sql.gz" -mtime +7|xargs rm -f  #删除本地的7天备份

稍微复杂点的脚步：

vim bak.sh
#!/bin/bash
export PATH=/application/mysql/bin:/usr/local/bin:/sbin:/bin:/usr/bin
bak_path=/server/backup
[ ! -d $bak_path ] && mkdir -p $bak_path  #若备份路径不存在则建立
if [ $(date +%w) -eq 6 ]  #若是时间为周六，则
then
    file_name=bak_$(date +%w_%F)  #将备份文件名改成周和日期，目的是在备份服务器上保留每周六的数据
else
    file_name=bak_$(date +%F)  #不然，备份文件名为日期
fi
mysqldump -B -A --master-data=2 |gzip >$bak_path/${file_name}.sql.gz
md5sum $bak_path/${file_name}.sql.gz >$bak_path/${file_name}.flag  #作md5指纹的目的是用于将来检测备份及传输结果是否正常
rsync -az $bak_path/ rsync_backup@172.16.1.31::mysql/ --password-file=/etc/rsync.password
#备份完成后马上推送至备份服务器，须要提早部署rsync服务
find $bak_path/ -type -f -name "*.sql.gz" -mtime +7|xargs rm -f  #删除本地的7天备份

配置定时任务，使其每日0点执行脚本：

crontab -e
bak mysql for oldboy at 20200515
00 00 * * * /bin/sh /server/scripts/bak.sh &>/dev/null

保留最近7天的全部备份，同时保留每周六的所有备份：

find /server/backup/ -type f -name "bak_*" -mtime +7 ! -name "bak_6*"
find /server/backup/ -type f -name "bak_*" -mtime +7 ! -name "bak_6*" |xargs rm -f

4.1.2.全备的数据什么时候能够派上用场

使用mysqldump全备的数据何时能够派上用场：

一、迁移或者升级数据库时。
二、增长从库时。
三、人为执行DDL、DML语句破坏数据库数据时（此时若使用主从库就会没法防止数据丢失，由于全部库都会执行破坏语句）。
四、跨机房灾备时，此时须要将全备份复制到异地。

如果由于硬件或删除物理文件致使数据库故障，就不须要用备份数据恢复了，能够直接把主库关闭，在从库上配置好VIP等配置后，启动从库提供服务便可。

4.1.3.中小企业增量备份策略

中小企业增量备份就是备份binlog文件，在MySQL没有主从复制功能或主从复制功能不完善的时候，咱们就曾采起定时或实时推binlog文件的方法。例如每分钟推一次binlog到备份服务器上，或者经过mysqlbinlog参数read-from-remote-server，在其余服务器上远程读取binlog。

可是这类方法都不是最佳的，由于有可能会丢失数据。比较好的binlog增量备份或MySQL备份方法就是为MySQL数据库配置异机主从复制功能（实时复制功能），即binlog会被实时地发送到从服务器上，这样效果才是最好的。固然，也要相应地在主从复制的从库上实现全备。

4.1.4.备份binlog增量文件什么时候能够派上用场

当须要完整恢复数据库数据的时候，就会须要binlog增量恢复。

4.1.5.企业里MySQL备份策略选择

大多数中小企业的数据库环境都为一主多从，所以，可采起在一个从库服务器上专门作全量以及增量备份（须要开启从库记录binlog日志功能），至于备份方法，采用mysqldump、Xtrabackup都可。

4.2.中小企业MySQL增量恢复案例

完整恢复数据库数据须要具有的条件：

一、具有全量备份（mysqldump）。
二、除全量备份之外，还有全量备份以后产生的全部binlog增量日志。

模拟0点开始对数据库oldboy数据进行全备：

mysqldump -B --master-data=2 --single-transaction oldboy|gzip >/data/backup/oldboy_$(date +%F).sql.gz

模拟0点全备后用户继续写入数据：

mysql -e "use oldboy;insert into test values(6,'bingbing');"
mysql -e "use oldboy;insert into test values(7,'xiaoting');"

模拟上午10点管理员删除oldboy数据库：

mysql -e "drop database oldboy;show databases;"

恢复前准备，移走全部binlog增量文件，防止二次破坏，并确认是否有全备：

cp -a /application/mysql/data/mysql-bin.* /data/backup/

开始恢复：

一、中止数据库对外访问。由于是经过drop命令删除数据库的，后面不会有写入操做，所以，能够不用额外中止写入。但若是是由于update致使的数据破坏，最好是停库处理或对外中止写入。这里采用iptables防火墙屏蔽全部应用程序的写入：
iptables -I INPUT -p tcp --dport 3306 ! -s 172.16.1.51 -j DROP  #非172.16.1.51禁止访问数据库3306端口。

二、解压全备的数据：
gzip -cd oldboy_2020-05-19.sql.gz >oldboy.sql

三、解析binlog文件增量数据：
sed -n '22p' oldboy.sql

从代码里能够看到，要从mysql-bin.000004文件的7181位置点开始恢复增量数据：
mysqlbinlog -d oldboy mysql-bin.000004 --start-position=7181 -r bin.sql

恢复后面的全部binlog文件：
mysqlbinlog -d oldboy mysql-bin.000005 mysql-bin.000006 -r bin1.sql

四、剔除误删除数据库的drop语句：
grep -w drop bin.sql  #过滤drop单词的行。
sed -i '/drop database oldboy/d' bin.sql  #删除drop数据库oldboy的语句。

恢复0点之前的全备数据：
mysql </data/backup/oldboy.sql  #先恢复全备，即0点之前的备份

恢复增量备份：
mysql oldboy</data/backup/bin.sql  #恢复增量文件

5.分库分表的生产备份策略

5.1.为何要分库分表备份

全备命令把2个库备份成了一个备份文件：

mysqldump -B --master-data=2 --single-transaction oldboy mysql|gzip>/data/backup/all.sql.gz

在还原时，不少时候只须要还原一个库或者多个库的一个表，这个时候，整个备份文件就会很难拆分，给恢复也会带来麻烦。对于这种状况，最好是分库分表备份。

5.2.如何进行分库备份

最佳的方法就是从数据库中取出全部库名，而后对每一个数据库执行一次备份。

分库备份的脚本：

vi fenku.sh
#!/bin/bash
export PATH=/application/mysql/bin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
bak_path=/server/backup/$(date +%F)
[ ! -d $bak_path ] && mkdir -p $bak_path
for dbname in `mysql -e "show databases"|sed '1,2d'|grep -v _schema`  #取库名轮询备份
do
    mysqldump -B --master-data=2 $dbname|gzip >$bak_path/${dbname}_$(date +%F).sql.gz  #注意备份的名字
done

5.3.如何进行分表备份

分表备份比分库更细，实际上就是先取一个库名，而后循环读取该库里的表进行备份，备份完以后，再取下一个库名，继续循环库里的全部表进行备份，知道全部库里的全部表都备份完毕。

分表备份的脚本：

vi fenbiao.sh
#!/bin/bash
export PATH=/application/mysql/bin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
bak_path=/server/backup/$(date +%F)
[ ! -d $bak_path ] && mkdir -p $bak_path
for dbname in `mysql -e "show databases"|sed '1,2d'|grep -v _schema`
do
    for tablename in `mysql -e "show tables from $dbname;"|sed '1d'`
    do
        mysqldump -B --master-data=2 $dbname$tablename|gzip >$bak_path/${dbname}_${tablename}_$(date +%F).sql.gz
    done
done

6.MySQL生产经常使用备份架构方案

在中小公司通常比较经常使用的作法是，每日0点执行全备任务，先把数据按照日期备份到数据库本地，而后推送到数据库备份服务器，因为本地空间有限，所以本地仅保留3-7日的全备。

若是有备用的服务器资源可用，那么最好经过主从同步的方式进行备份，这样即便物理机损坏了也能够很快地切换到新服务器（还能够HA自动切换），可是主从复制的缺点是不能解决错误执行SQL语句的问题。

所以，咱们通常会在某一台不对外提供业务的从库上使用mysqldump或Xtrabackup来进行定时备份。这里有个须要特别注意的地方，用于备份从库的二进制日志记录功能必须打开。