MySQL数据库增量备份的操作
# 1,前言。
当数据库文件以及量级不大的时候,我们可以采用全量备份的策略来进行备份。但是当数据库文件有一定量级的时候,再使用全量备份,就显得有些笨拙了。
内网数据虽然没有特别重要,但是备份也是不可或缺的一个环节,朱子有言:“宜未雨而筹谋,勿临渴而掘井
”,这句话放在备份领域简直就是无法颠破的真理。
因此,在内网的数据,我们也做了全量备份,今天就来整理一下备份的脚本以及备份的策略以及备份的灾备恢复。
增量备份的成立依赖于 mysql 的 bin-log 原理,我们在数据库中的每一步增删改查操作都会记录在 binlog 日志当中,那么通过先对数据库进行一次全量备份,备份同时将 binlog 日志刷新,在这次备份之后的所有操作都会记录在新增的 binlog 日志当中,在增量备份当中我们只需要对增加的 binlog 进行备份,就实现了对不断增加内容的数据库的完美备份了。
当数据库出现异常的时候,我们可以先恢复最近一次的全量备份,接着将增量备份的文件一个一个按顺序恢复即可实现原来数据库的恢复。
# 2,备份。
# 1,开启 bin-log 记录。
执行增量备份的前提条件是 MySQL 打开binlog
日志功能,在my.cnf
中加入
log-bin=/data/mysql/mysql-bin #“log-bin=”后的字符串为日志记载目录,如果不指定位置的话,默认在mysql的data目录下。
# 2,首先是全量备份的脚本。
#!/bin/bash
dumpdate=$(date +%H%M%S)
filedate=$(date +%y%m%d)
mysqldump=/usr/local/mysql/bin/mysqldump
mulu=/backup/sqlbackup/all/$filedate
if [ ! -d $mulu ];then
mkdir -p $mulu
fi
$mysqldump --quick --events --all-databases --flush-logs --delete-master-logs --single-transaction > ${mulu}/all${dumpdate}.sql
sleep 5
2
3
4
5
6
7
8
9
10
参数:
--quick,-q
该选项在导出大表时很有用,它强制 MySQLdump 从服务器查询取得记录直接输出而不是取得所有记录后将它们缓存到内存中。
--events, -E
导出事件
--all-databases , -A
导出全部数据库。
--flush-logs
开始导出之前刷新日志,这一项必须带上
。
请注意:假如一次导出多个数据库 (使用选项—databases 或者—all-databases),将会逐个数据库刷新日志。除使用—lock-all-tables 或者—master-data 外。在这种情况下,日志将会被刷新一次,相应的所以表同时被锁定。因此,如果打算同时导出和刷新日志应该使用—lock-all-tables 或者—master-data 和—flush-logs。
--delete-master-logs
master 备份后删除日志. 这个参数将自动激活—master-data。
--single-transaction
该选项在导出数据之前提交一个 BEGIN SQL 语句,BEGIN 不会阻塞任何应用程序且能保证导出时数据库的一致性状态。它只适用于多版本存储引擎,仅 InnoDB。本选项和—lock-tables 选项是互斥的,因 LOCK TABLES 会使任何挂起的事务隐含提交。要想导出大表的话,应结合使用—quick 选项。
# 3,接着是增量备份的脚本。
#!/bin/bash
export LANG=en_US.UTF-8
BakDir=/backup/sqlbackup/add
LogFile=$BakDir/binlog.log
BinDir=/usr/local/mysql/data
BinFile=/usr/local/mysql/data/mysql-bin.index
mysqladmin=/usr/local/mysql/bin/mysqladmin
$mysqladmin flush-logs
#这个是用于产生新的mysql-bin.00000*文件
Counter=`wc -l $BinFile |awk '{print $1}'`
NextNum=0
#这个for循环用于比对$Counter,$NextNum这两个值来确定文件是不是存在或最新的。
for file in `cat $BinFile`
do
base=`basename $file`
#basename用于截取mysql-bin.00000*文件名,去掉./mysql-bin.000005前面的./
NextNum=`expr $NextNum + 1`
if [ $NextNum -eq $Counter ]
then
echo $base skip! >> $LogFile
else
dest=$BakDir/$base
if test -e $dest
#test -e用于检测目标文件是否存在,存在就写exist!到$LogFile去。
then
echo $base exist! >> $LogFile
else
cp $BinDir/$base $BakDir
echo $base copying >> $LogFile
fi
fi
done
echo `date +"%Y年%m月%d日 %H:%M:%S"` Bakup succ! >> $LogFile
sleep 5
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
针对 binlog 的增量备份。
# 4,通过定时执行两个脚本来实现备份策略。
方式 | 定时任务 | 备注 |
---|---|---|
增量备份 | 0 3 0 /bin/bash /backup/sqlbakall.sh | 每周日凌晨三点备份 |
全量备份 | 0 3 1-6 /bin/bash /backup/sqlbakadd.sh | 每周一到周六凌晨三点备份 |
这样就实现了数据库的增量备份。其中全量备份则使用 mysqldump 将所有的数据库导出,每周日凌晨三点执行,并会删除上周留下的 binlog(mysql-bin.00000*)。增量备份会在每周一到周六的凌晨三点执行,执行的动作是将一周生成的 binlog 复制到指定的目录。
# 3,恢复。
关于灾备恢复。
一旦出现问题,恢复的顺序应该是先恢复
最近一次的全量备份,让数据库追溯到最近一次的完整状态。
然后按顺序将增量备份一个一个恢复起来。(注意:这个地方要注意的是,由于脚本当中没有对旧备份的 binlog 进行处理,所以当需要恢复增量备份的时候,要结合全量备份的日期,与 binlog 备份中的日期,恢复的时候只用从全量备份那一天之后的 binlog 进行恢复即可!)
具体恢复命令如下:
# 1, 恢复安全备份。
mysql -uroot -p123456 < all104528.sql
# 2, 恢复增量备份。
mysqlbinlog master-bin.000007 | mysql -uroot -p123456
mysqlbinlog master-bin.000008 | mysql -uroot -p123456
mysqlbinlog master-bin.000009 | mysql -uroot -p123456
2
3
注:当执行恢复操作的时候,由于数据量较大,可以暂时关闭 binlog 的记录。
# 4,优化。
突然想,为何不优化一下呢?
说干就干。
优化思路就是把旧的 binlog 保存在 oldbinlog 目录当中。
全量备份:
#!/bin/bash
dumpdate=$(date +%H%M%S)
filedate=$(date +%y%m%d)
mysqldump=/usr/local/mysql/bin/mysqldump
mulu=/backup/sqlbackup/all/$filedate
if [ ! -d $mulu ];then
mkdir -p $mulu
fi
$mysqldump --quick --events --all-databases --flush-logs --delete-master-logs --single-transaction > ${mulu}/all${dumpdate}.sql
sleep 5
cd /backup/sqlbackup/add/
\mv master-bin.0000* oldbinlog
2
3
4
5
6
7
8
9
10
11
12
注意要创建这个 oldbinlog 目录。
这样,当服务出问题的时候,直接根据 all 目录下的全量备份进行恢复,然后根据 add 目录下的增量备份进行恢复即可。