如何将linux中mysql备份恢复

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了如何将linux中mysql备份恢复相关的知识,希望对你有一定的参考价值。

一般是即时备份。做主从。或者是每天增量备份。
本文是在linux下,mysql 4.1.14版本下测试的,经过适当修改可能适合mysql 4.0,5.0及其其他版本.

本文适合于没有启动复制功能的mysql,如果启动了复制,可能不需要采取这种备份策略或者需要修改相关参数.

每个人的备份策略都可能不同,所以请根据实际情况修改,做到举一反三,不要照搬照抄,可能会造成不必要的损失.

希望你明白这个脚本要干什么工作!

脚本描述

每7天备份一次所有数据,每天备份binlog,也就是增量备份.

(如果数据少,每天备份一次完整数据即可,可能没必要做增量备份)

作者对shell脚本不太熟悉,所以很多地方写的很笨 :)

开启 bin log

在mysql 4.1版本中,默认只有错误日志,没有其他日志.可以通过修改配置打开bin log.方法很多,其中一个是在/etc/my.cnf中的mysqld部分加入:

[mysqld]
log-bin

这个日志的主要作用是增量备份或者复制(可能还有其他用途).

如果想增量备份,必须打开这个日志.

对于数据库操作频繁的mysql,这个日志会变得很大,而且可能会有多个.

在数据库中flush-logs,或者使用mysqladmin,mysqldump调用flush-logs后并且使用参数delete-master-logs,这些日志文件会消失,并产生新的日志文件(开始是空的).

所以如果从来不备份,开启日志可能没有必要.

完整备份的同时可以调用flush-logs,增量备份之前flush-logs,以便备份最新的数据.

完整备份脚本

如果数据库数据比较多,我们一般是几天或者一周备份一次数据,以免影响应用运行,如果数据量比较小,那么一天备份一次也无所谓了.

#!/bin/sh

BakDir=/backup/mysql
LogFile=/backup/mysql/mysqlbak.log

DATE=`date +%Y%m%d`

echo " " >> $LogFile
echo " " >> $LogFile
echo "-------------------------------------------" >> $LogFile
echo $(date +"%y-%m-%d %H:%M:%S") >> $LogFile
echo "--------------------------" >> $LogFile

cd $BakDir

DumpFile=$DATE.sql
GZDumpFile=$DATE.sql.tgz

mysqldump --quick --all-databases --flush-logs
--delete-master-logs --lock-all-tables
> $DumpFile

echo "Dump Done" >> $LogFile

tar czvf $GZDumpFile $DumpFile >> $LogFile 2>&1

echo "[$GZDumpFile]Backup Success!" >> $LogFile

rm -f $DumpFile

#delete previous daily backup files:采用增量备份的文件,如果完整备份后,则删除增量备份的文件.
cd $BakDir/daily

rm -f *

cd $BakDir

echo "Backup Done!"

echo "please Check $BakDir Directory!"

echo "copy it to your local disk or ftp to somewhere !!!"

ls -al $BakDir
上面的脚本把mysql备份到本地的/backup/mysql目录,增量备份的文件放在/backup/mysql/daily目录下.

注意:上面的脚本并没有把备份后的文件传送到其他远程计算机,也没有删除几天前的备份文件:需要用户增加相关脚本,或者手动操作.

增量备份

增量备份的数据量比较小,但是要在完整备份的基础上操作,用户可以在时间和成本上权衡,选择最有利于自己的方式.

增量备份使用bin log,脚本如下:

#!/bin/sh

#
# mysql binlog backup script
#

/usr/bin/mysqladmin flush-logs

DATADIR=/var/lib/mysql
BAKDIR=/backup/mysql/daily

###如果你做了特殊设置,请修改此处或者修改应用此变量的行:缺省取机器名,mysql缺省也是取机器名
HOSTNAME=`uname -n`

cd $DATADIR

FILELIST=`cat $HOSTNAME-bin.index`

##计算行数,也就是文件数
COUNTER=0
for file in $FILELIST
do
COUNTER=`expr $COUNTER + 1 `
done

NextNum=0
for file in $FILELIST
do
base=`basename $file`
NextNum=`expr $NextNum + 1`
if [ $NextNum -eq $COUNTER ]
then
echo "skip lastest"
else
dest=$BAKDIR/$base
if(test -e $dest)
then
echo "skip exist $base"
else
echo "copying $base"
cp $base $BAKDIR
fi
fi
done

echo "backup mysql binlog ok"
增量备份脚本是备份前flush-logs,mysql会自动把内存中的日志放到文件里,然后生成一个新的日志文件,所以我们只需要备份前面的几个即可,也就是不备份最后一个.
因为从上次备份到本次备份也可能会有多个日志文件生成,所以要检测文件,如果已经备份过,就不用备份了.

注:同样,用户也需要自己远程传送,不过不需要删除了,完整备份后程序会自动生成.

访问设置

脚本写完了,为了能让脚本运行,还需要设置对应的用户名和密码,mysqladmin和mysqldump都是需要用户名和密码的,当然可以写在脚本中,但是修改起来不太方便,假设我们用系统的root用户来运行此脚本,那么我们需要在/root(也就是root用户的home目录)创建一个.my.cnf文件,内容如下

[mysqladmin]
password =password
user= root
[mysqldump]
user=root
password=password
注:设置本文件只有root可读.(chmod 600 .my.cnf )

此文件说明程序使用mysql的root用户备份数据,密码是对应的设置.这样就不需要在脚本里写用户名和密码了.

自动运行

为了让备份程序自动运行,我们需要把它加入crontab.

有2种方法,一种是把脚本根据自己的选择放入到/etc/cron.daily,/etc/cron.weekly这么目录里.
一种是使用crontab -e放入到root用户的计划任务里,例如完整备份每周日凌晨3点运行,日常备份每周一-周六凌晨3点运行.
参考技术A

前言

MySQL 5.6引入了GTID,每个事务都会产生一个GTID,我们可以通过验证主从GTID来验证主从数据的一致性。

为了叙述简便,定义一个量ALL_GTID: 表示某个数据库实例上 所有存在过的 或 将要存在的事务 的GTID(包括已经被purge掉的事务)。

在讨论数据库可用性的场景中, 当发生主备切换时, 需要进行数据补偿。通过比较主备的ALL_GTID,可以确定需要补偿多少数据:

    在实例存活的情况,可以在实例状态中查询ALL_GTID。

    在实例崩溃的情况,无法在实例状态中查询ALL_GTID。可以通过查询BINLOG中的Previous-GTIDs计算来获得ALL_GTID。

    下面列举与ALL_GTID相关的变量。

    与ALL_GTID相关的变量

    Previous-GTIDs

    Previous-GTIDs格式如下(环境为MySQL5.7,日志手动flush binary logs获得):

    查看新轮转出的BINLOG:


    下面为mysql-bin.00001中包含的GTID:

    请点击输入图片描述


    然后再次flush binary logs:

    请点击输入图片描述


    mysql-bin.00002中是没有任何GTID的。

    请点击输入图片描述


    综上Previous-GTIDs是本身这个BINLOG文件前面的所有BINLOG的集合。

    请点击输入图片描述

    全局变量中的GTID相关的变量

    请点击输入图片描述

    变量解释:

    gtid_executed 代表着server上所有事务执行产生的GTID(包含已经被purge的BINLOG中的GTID或者是手动set gtid_purged的GTID)。

    gtid_purged 代表着已经被purge到的GTID。gtid_purged是gtid_executed的子集。

    gtid_retrieved 是从机上relay_log中的GTID。

    ALL_GTID 的计算

    了解了GTID相关的变量之后,可以得到获得实例的All_GTID的集合的方法:

    对象

    方法

    存活的Master实例    gtid_executed    

    存活的Slave实例    gtid_executed和gtid_retrieved的并集    

    非存活Master实例    最后一个BINLOG文件的Previous-GTIDs + 最后一个BINLOG文件中所有的GTID    

    非存活Slave实例    最后一个BINLOG文件的Previous-GTIDs + 最后一个BINLOG文件中所有的GTID    

    在获得非存活实例中的ALL_GTID时,最后一个BINLOG文件中的GTID可能不连续(比如事务同时来自于本实例客户端和复制回放),所以需要扫描最后一个BINLOG文件。

    生产中我们使用Xtrabackup来产生一个 从实例 的流程如下:

    拉取备份,进行还原

    change master to

    set @@global.gtid_purged='xxx';

    set @@global.gtid_purged='xxx'; 的影响:

    将 从实例 的ALL_GTID手工置为xxx, 在通过GTID方式建立复制时不会出错.

    将更新Binlog中记录的Previous-GTIDs (由于Binlog不可改变, 将产生新的Binlog, 记录新的Previous-GTIDs).

    MySQL 5.7中set gtid_purged的行为变更

    问题描述

    回顾一下备份恢复的流程:

    拉取备份,进行还原

    change master to

    set @@global.gtid_purged='xxx';

    现象: 发现有一台MySQL 5.7的Slave服务器恢复后没有产生 正确的Previous-GTIDs。

    分析

    分析整个过程,解决问题应该分阶段进行手动模拟发现问题。以下为详细步骤:

    手工还原备份

    环境

    BINLOG数量,Previous-GTIDs状态

    Xtrabackup 2.4.2 & MySQL 5.6    1,空    

    Xtrabackup 2.4.2 & MySQL 5.7    1,空    

    Xtrabackup 2.2.9 & MySQL 5.6    1,空    

    Xtrabackup 2.2.9 & MySQL 5.7    1,空    

    可见: 恢复过程不会轮转BINLOG。

    验证change master和set gtid_purged在不同的MySQL版本中执行的差异

    环境

    BINLOG数量,Previous-GTIDs状态

    change master & MySQL 5.6    1,空    

    change master & MySQL 5.7    1,空    

    set gtid_purged & MySQL 5.6    2,正常    

    set gtid_purged & MySQL 5.7    1,空    

    可见: 执行set gtid_purged时不同版本的MySQL产生了差异

    验证

    对不同版本MySQL单独执行set @@global.gtid_purged='';语句。检查结果

    环境

    进行的操作

    BINLOG数量,Previous-GTIDs状态

    MySQL 5.7    reset master; set @@global.gtid_purged=”;    1,空    

    MySQL 5.6    reset master; set @@global.gtid_purged=”;    2,正常    

    结论

    参考: http://bugs.mysql.com/bug.php?id=75767

    官方解释: 在5.7版本中,执行SET GTID_PURGED语句后binlog_simple_gtid_recovery会给GTID_PURGED计算出一个错误的值。

    由于5.7中新增了存储GTID的表。所以5.7版本中set @@global.gtid_purged='';语句被改成只修改存放GTID的表。

    而5.6版本中会进行BINLOG轮转和向Previous_gtids_log_event中添加GTID。如果5.7需要产生和5.6相同结果的话,可以在SET GTID_PURGED语句后手动执行flush binary logs语句。

如何将阿里云mysql RDS备份文件恢复到自建数据库

PS:目前恢复只支持 Linux 下进行。Linux下恢复的数据文件,无论 Windows、Linux 操作系统,MySQL 都可以正常使用
1、概述和软件说明
1.1 概述
  RDS MySQL 使用开源软件 percona-Xtrabackup 对 MySQL 数据库进行备份。需要下载该软件,然后使用该软件进行恢复。
  
  1.2 软件说明
  • 1.2.1 解压软件
  • a)  RDS的备份文件是一个压缩包,需要先解压出来,才能恢复,这里下载解压工具 rds_backup_extract.sh目前只支持 64 位 Linux 系统
  • b) 软件使用方式:
  1. bash rds_backup_extract.sh -f backup.tar.gz/back.xb.gz  -C directory
  1. # -f 指定要解压的备份集文件
  1. # -C 指定解压到的目录;-C 参数是可选的,如果不指定就解压到当前目录,如 bash rds_backup_extract -f backup.tar.gz
 
  • 1.2.2 恢复软件
  • 恢复软件请下载官方的 Percona-XtraBackup(下载地址:https://www.percona.com/downloads/XtraBackup/)官方提供各种平台的安装包,请根据自己的需要下载。RDS 备份使用的版本是 2.2.9,建议下载 2.2.9 或更新的版本使用。
  • (PS: 注意要选择与自己的系统版本(查看版本命令:lsb_release -a)相对应的软件包,我当时选错了包安装时就出问题了)
2、恢复流程
2.1 下载rds备份文件
2.2 使用 rds_backup_extract.sh 工具解压备份文件
  1. bash rds_backup_extract.sh -f /home/mysql/backup/hins575175_xtra_20150429091224.tar.gz -C /home/mysql/data
PS:
如果数据太大有可能解压时报错(blocked for more than 120 seconds),需要修改linux内核参数把下面内容追加到 /etc/sysctl.conf 文件中
vm.dirty_ratio = 10
vm.dirty_background_ratio = 5
原因:这个版本的内核 2.6.32 默认情况下会预留内存的 20% (由参数 vm.dirty_ratio 指定)作为 IO 的缓存,当脏页达到这个阈值时,内核会将内存中的数据写到磁盘上。写到磁盘上这个过程是有 120 秒的超时限制的,所以我们看到了 blocked for more than 120 seconds 这句话。在大内存机器上,比如64G,那么预留给 IO 缓存的内存有 12.8G。如果需要在 120秒内将 12.8G 到磁盘上需要 109MB/s (873Mbit/s) 的写速度,这个在一般磁盘上都很难达到,所以发生了这个问题
2.3 恢复数据文件
  1. innobackupex --defaults-file=/home/mysql/data/backup-my.cnf --apply-log /home/mysql/data
 

 

出现如上图说明恢复成功
2.4 配置文件修改
由于存在的版本问题,请将解压文件 backup-my.cnf 中的 红框内的参数项注释掉,如下图:
 
 
 
2.5 修改文件属主
  1. chown -R mysql:mysql /home/mysql/data
2.6 启动 MySQL 进程并且登录验证
启动mysqld进程:
  1. mysqld_safe --defaults-file=/home/mysql/data/backup-my.cnf --user=mysql --datadir=/home/mysql/data &
PS: 如果服务器原来的mysql已经启动,则需要将mysql关闭
登录mysql验证
  1. mysql -u root
PS:这里不要输入mysql的密码,直接用无密码登录
 注意:
  •  恢复完成后,表 mysql.user 中是不包含 RDS 中创建的用户,需要新建。
  •  新建用户前请执行如下 SQL:
  1. delete from mysql.db where user<>\'root\' and char_length(user)>0;
  1. delete from mysql.tables_priv where user<>\'root\' and char_length(user)>0;
  1. flush privileges;

BY bjr 15:43:50

以上是关于如何将linux中mysql备份恢复的主要内容,如果未能解决你的问题,请参考以下文章

如何将阿里云mysql RDS备份文件恢复到自建数据库

MySQL全备份如何只恢复一个库或者一个表

Linux下mysql备份 恢复

Linux下mysql备份 恢复

Linux数据库备份和恢复

MySQL备份和恢复