MySQL数据库-mysqldump方式备份恢复
文章来由:
关于MySQL备份恢复的文章,网上一搜一大把,为何我还要花时间写这篇博文?
我不是闲的蛋疼,网上的文章一般也只是给个备份命令,或者恢复命令,有一些报错也没有说明原因。因为工作中遇到了这类问题,并不是像网上的文章那样:
- 从Windows下面用cmd导出的,用MySQL IDE恢复不能用
- 恢复时加什么--binary-mode=1
- 给备份文件添加上bom头信息:sublime-file-save with encoding - utf-8 with bom
等等,诸如此类。
我遇到的情况不一样,在此总结一下,希望能帮到和我一样遇到这样困扰的同行。
本人不是专业的MySQL DBA,数据库管理纯属兼职。:)
mysqldump备份出来的结果大体有两种,一种是sql文件,另外一种是gz文件(本质上也是sql,只不过备份后用gzip进行了压缩处理),但是恢复方式却不太相同,这里记录一下。
首先摆出我遇到的报错,相信大家也可能会遇到:
备份恢复方式一
使用mysqldump导出sql文件,再使用tar命令进行压缩后存放的。
备份命令:
mysqldump -u root -p confluence > /opt/confluence.sql tar confluence.sql.tar.gz confluence.sql
这类文件的恢复方法按道理说很简单,无非是解压后,恢复到数据库中
tar xzf confluence.sql.tar.gz # 登录MySQL数据库 mysql -u root -p # 创建数据库: mysql>create database confluence default character set utf8 collate utf8_bin; # 导入数据 use confluence; source confluence.sql
至此恢复完成。
当然也可以不登录mysql数据库恢复数据到指定数据库中
mysql -uroot -p confluence < /opt/confluence.sql
但是有人非要使用如下方法恢复数据,这就会出现文章开头提到的错误。很多人可能和笔者一样,一脸懵逼。
~]# gunzip < confluence.tar.gz |mysql -uroot -p confluence Enter password: ERROR: ASCII '\0' appeared in the statement, but this is not allowed unless option --binary-mode is enabled and mysql is run in non-interactive mode. Set --binary-mode to 1 if ASCII '\0' is expected. Query: 'confluence.sql'.
我开始也遇到了这个问题,不得不说笔者这个MySQL菜鸟还不是一般的菜。希望读者你没有遇到。:)
遇到问题并不可怕,只要有钻研精神,把问题分析透彻,了解清楚就行了。
备份恢复方式二
使用mysqldump备份数据库时,直接用管道符号交给gzip进行压缩存储。
备份命令:
mysqldump -hlocalhost -uroot -p confluence | gzip > /opt/confluence-`date +%Y-%m-%d`.sql.gz
恢复方法有二
1、使用gunzip命令直接恢复压缩文件,命令如下:
gunzip < confluence-2020-09-28.sql.gz | mysql -uroot -p confluence
2、解压后恢复sql文件,参考命令如下:
# 解压文件 gunzip confluence-2020-09-28.sql.gz # 恢复到数据库 mysql -uroot -p confluence < confluence-2020-09-28.sql
MySQL备份脚本参考
#!/bin/bash # mysql_backup.sh: backup mysql databases and keep newest 7 days backup. # # ${db_user} is mysql username # ${db_password} is mysql password # ${db_host} is mysql host # —————————– #/root/mysql_backup.sh # everyday 3:00 AM execute database backup # 0 3 * * * /root/mysql_backup.sh #/etc/cron.daily db_user="root" db_password="NMm#t87TO2JL&Zq2" db_host="localhost" SOCK_FILE=/tmp/mysql.sock # the directory for story your backup file. # backup_dir="/opt/backup/mysql/" # 要备份的数据库名 # #all_db="$(${mysql} -u ${db_user} -h ${db_host} -p${db_password} -Bse 'show databases')" # all_db="confluence apolloportal apolloconfig17" # 要保留的备份天数 # backup_day=7 #数据库备份日志文件存储的路径 logfile="/var/log/mysql_backup.log" # local IP address local_ip="$(hostname -i)" # date format for backup file (dd-mm-yyyy) # time="$(date +"%Y-%m-%d")" # mysql, ${mysqldump} and some other bin's path # mysql="/ichint/mysql/bin/mysql" mysqldump="/ichint/mysql/bin/mysqldump" # the directory for story the newest backup # test ! -d ${backup_dir} && mkdir -p ${backup_dir} #备份数据库函数# mysql_backup() { # 取所有的数据库名 # for db in ${all_db} do backname=${db}.${time} dumpfile=${backup_dir}${backname} #将备份的时间、数据库名存入日志 echo "------"$(date +'%Y-%m-%d %T')" Beginning database "${db}" backup--------" >>${logfile} ${mysqldump} -F -u${db_user} -p${db_password} -S $SOCK_FILE ${db} > ${dumpfile}.sql 2>>${logfile} 2>&1 #${mysqldump} --login-path=my3306 ${db} > ${dumpfile}.sql 2>>${logfile} 2>&1 #开始将压缩数据日志写入log echo $(date +'%Y-%m-%d %T')" Beginning zip ${dumpfile}.sql" >>${logfile} #将备份数据库文件库压成ZIP文件,并删除先前的SQL文件. # tar -czf ${backname}.tar.gz ${backname}.sql 2>&1 && rm ${dumpfile}.sql 2>>${logfile} 2>&1 #将压缩后的文件名存入日志。 echo "backup file name:"${dumpfile}".tar.gz" >>${logfile} echo -e "-------"$(date +'%Y-%m-%d %T')" Ending database "${db}" backup-------\n" >>${logfile} done } delete_old_backup() { echo "delete backup file:" >>${logfile} # 删除旧的备份 查找出当前目录下七天前生成的文件,并将之删除 find ${backup_dir} -type f -mtime +${backup_day} | tee delete_list.log | xargs rm -rf cat delete_list.log >>${logfile} } #进入数据库备份文件目录 cd ${backup_dir} mysql_backup delete_old_backup echo -e "========== mysql backup done at "$(date +'%Y-%m-%d %T')" ==========\n\n">>${logfile} #cat ${logfile}
如果希望用第二种备份方式,自行修改下备份函数中的备份命令即可。
人们永远没有足够的时间把它做好,但永远有足够的时间重新来过。 可是,因为并不是总有机会重做一遍,你必须做得更好,换句话说, 人们永远没有足够的时间去考虑到底是不是想要它,但永远有足够的时间去为之后悔。 ★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★ 浅掘千口井,不如深挖一口井!当知识支撑不了野心时,那就静下心来学习吧!运维技术交流QQ群:618354452
个人微信公众号,定期发布技术文章和运维感悟。欢迎大家关注交流。