前言:
对于系统来说,生产数据是非常重要的,有时候不小心删除了却找不回来就酿成了大祸。因此,定时备份生产数据是非常有必要的,即使不小心删除了全部数据,也可以使用备份数据进行回复。本文提供MySQL的备份脚本,可按自己的需求进行修改。
1.增量备份脚本binlogbak.sh
脚本中文件路径BakDir、LogFile需要自行创建,其中BinFile和BinDir需要自己自行找到对应的路径
#!/bin/bash
export LANG=en_US.UTF-8
BakDir=/u01/data/mysqlbak/data/zlbak
BinDir=/var/lib/mysql
LogFile=/u01/data/mysqlbak/log/binlog.log
BinFile=/var/lib/mysql/logindex.index
mysqladmin -h 生产数据库服务器ip地址 -u数据库用户名 -p数据库密码 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"` Backup success! >> $LogFile
2、全量备份脚本databak.sh
脚本中文件路径BakDir、ZlbakDir、LogFile需要自行创建,此脚本可在多个服务器上定时执行
#!/bin/bash
export LANG=en_US.UTF-8
BakDir=/u01/data/mysqlbak/data/allbak
ZlbakDir=/u01/data/mysqlbak/data/zlbak
LogFile=/u01/data/mysqlbak/log/bak.log
Date=`date +%Y-%m-%d-%H-%M-%S`
Begin=`date +"%Y年%m月%d日 %H:%M:%S"`
Database=要备份的数据库名称
#BackName=`$Database-$Date`
cd $BakDir
DumpFile=$Database-$Date.sql
GZDumpFile=$Database-$Date.tar.gz
mysqldump -h 生产数据库服务器ip地址 -u数据库用户名 -p数据库密码 $Database --flush-logs --delete-master-logs --single-transaction > $BakDir/$DumpFile
#示例:mysqldump -h 172.16.40.92 -uroot -pIDEO-xwk123 $Database > $BakDir/$DumpFile
tar -czvf $GZDumpFile $DumpFile
rm $DumpFile
count=$(ls -l *.tar.gz |wc -l)
if [ $count -ge 2 ]
then
file=$(ls -l *.tar.gz |awk '{print $9}'|awk 'NR==1')
rm -f $file
fi
Last=`date +"%Y年%m月%d日 %H:%M:%S"`
echo 开始:$Begin 结束:$Last $GZDumpFile success >> $LogFile
# 进入到增量备份目录,删除binlog
cd $ZlbakDir
rm -f *
3、设置定时任务
注意:一定要选择用户量少的时间执行脚本,防止影响用户体验。
[root@server mysqlbak]# crontab -e
#每个星期日凌晨2:00执行完全备份脚本
0 2 * * 0 /u01/data/mysqlbak/databak.sh >/dev/null 2>&1
#周一到周六凌晨2:00做增量备份
0 2 * * 1-6 /u01/data/mysqlbak/binlogbak.sh >/dev/null 2>&1
4、使计划任务生效
# systemctl restart crond.service
5、查看计划任务
出现如下内容,即设置定时任务成功
#每个星期日凌晨2:00执行完全备份脚本
0 2 * * 0 /u01/data/mysqlbak/databak.sh >/dev/null 2>&1
#周一到周六凌晨2:00做增量备份
0 2 * * 1-6 /u01/data/mysqlbak/binlogbak.sh >/dev/null 2>&1
6.问题
Shell脚本手动执行可以正常运行,并得到正确结果;使用Crontab定时调度的时候,Shell脚本执行出来的结果数据量为0。
原因:
Linux下用crontab执行定时任务不会缺省的从用户profile文件中读取环境变量参数,所以经常导致在手工执行某个脚本时是成功的,但是到crontab中试图让它定期执行时就是会出错。这是因为用户登陆Linux操作系统的时候,”/etc/profile”, “~/.bash_profile”等配置文件会被自动执行,而crontab定时调度的时候可能不会执行配置文件。
7.解决
Shell脚本缺省的**#!/bin/sh** 开头换行后的第一行添加
source /etc/profile
source ~/.bash_profile
8.mysqldump的–single-transaction参数
如果不带–single-transaction参数使用mysqldump进行备份,会产生以下影响:
- 表锁定:
- mysqldump默认会使用全局读锁(如FLUSH TABLES WITH READ LOCK)来确保备份数据的一致性。这意味着在备份过程中,所有被备份的表都将被锁定为只读状态,直到备份完成。
- 对于高并发的系统,这种锁定机制可能会导致其他尝试访问这些表的写操作被阻塞,直到备份结束。
- 备份时间与业务影响:
- 由于表被锁定,任何尝试修改被锁定表的操作都将被延迟,直到备份完成。对于实时性要求较高的系统,这种延迟可能会导致业务中断或性能下降。
- 如果数据库数据量较大,备份时间可能会较长,进一步增加了对业务的影响。
- 事务处理:
- 不带–single-transaction参数时,mysqldump不会利用InnoDB的事务特性来创建备份。因此,它无法确保在备份过程中,数据的一致性是基于某个特定的事务点的。
- 性能考虑:
- 由于全局读锁会阻塞其他写操作,这可能会导致数据库性能下降,特别是在高并发的场景下。
- 解决策略:
- 如果你的系统使用的是InnoDB存储引擎,并且希望避免在备份过程中锁定表,可以考虑使用–single-transaction参数。这个参数会告诉mysqldump在备份开始时设置事务隔离级别为可重复读(REPEATABLE READ),并开始一个事务,然后创建 Read View,然后整个事务执行期间都在用这个 Read View,而且由于 MVCC 的支持,备份期间业务依然可以对数据进行更新操作。这样,mysqldump就可以在这个事务中读取数据,而不会锁定表。
- 使用–single-transaction参数时,需要确保没有其他长时间运行的事务正在修改备份中的表,因为这可能会导致备份数据不一致。
综上所述,不带–single-transaction参数使用mysqldump进行备份可能会导致表锁定、备份时间长、对业务的影响大以及无法利用InnoDB的事务特性来确保数据一致性等问题。
9.多数据库备份
上面提到的全量备份脚本只能备份单个数据库的数据,对此,可以通过databases参数来备份多个数据库,只需将脚本的备份命令改成如下即可:其中database1、database2、database3为数据库名称
mysqldump -h 生产数据库服务器ip地址 -u数据库用户名 -p数据库密码 --databases database1 database2 database3 --flush-logs --delete-master-logs --single-transaction > $BakDir/$DumpFile
如果数据库端口不是3306的话,需要在备份命令中添加-P 端口号来指定端口