centos5 gcc g++ 要求提高gcc至4.4以上上,2.1.1 yum的装置格局澳门威尼斯人网址

宣称:本文由自个儿的同事@fiona514编辑,是自身看过的最用心的国语表达介绍,强烈推荐我们学习应用。

一、 简介

Percona XtraBackup User 马努al 阅读笔记,perconaxtrabackup

 澳门威尼斯人网址 1

咱俩领悟,针对InnoDB存款和储蓄引擎,MySQL本身没有提供适宜的热备工具,ibbackup虽是一款快速的首要选拔热备格局,但它是是收费的。幸好Percona公司给大家提供了一个开源、免费的Xtrabackup热备工具,它可完结ibbackup的有所成效,并且还扩展扶助真正的增量备份效用,是经济贸易备份工具InnoDB
Hotbackup的三个很好的替代品。

XtraBackup

XtraBackup..
1

2 安装XtraBackup.. 1

2.1 安装XtraBackup binary版本… 1

2.1.1 yum的设置情势:…
1

2.1.2 直接下载rpm包安装… 1

3 XtraBackup使用手册…
1

3.1 使用innobackupex脚本… 1

3.1.1 备份预备工作…
1

3.1.2 全备和全备还原…
1

3.1.2.1 使用innobackupex创立全备…
1

3.1.2.2 使用innobackupex预备全备… 1

3.1.2.3 使用innobackupex还原备份…
1

3.1.3 增量备份和还原…
1

3.1.3.1 创立增量备份…
1

3.1.3.2 预备增量备份…
1

3.1.3.3 还原增量备份…
1

3.1.3.4 能够行使流做增量备份…
1

3.1.4 部分备份和还原…
1

3.1.4.1 创制部分备份…
1

3.1.4.2 预备部分备份…
1

3.1.4.3 还原部分备份…
1

3.1.5 窄备份… 1

3.1.5.1 创设窄备份…
1

3.1.5.2 预备窄备份… 1

3.1.5.3 还原窄备份…
1

3.1.6 备份加密…
1

3.1.7 其余职能…
1

3.1.7.1 备份压缩和流…
1

3.1.7.2 在复制环境下备份…
1

3.1.7.3 加快备份进度…
1

3.1.7.4 节流(throttling)备份… 1

3.1.7.5 还原独立表…
1

3.1.7.6 时间点还原…
1

3.1.7.7 提高对FLUSH TABLES WITH READ
LOCK控制… 1

3.1.8 innobackupex工作规律…
1

3.1.9 Reference.
1

3.2 使用Xtrabackup..
1

3.2.1 选择bianry.
1

3.2.2 配置Xtrabackup..
1

3.2.3 创立全备和还原…
1

3.2.3.1 成立全备…
1

3.2.3.2 预备全备…
1

3.2.3.3 还原全备…
1

3.2.4 增量备份和还原…
1

3.2.4.1 增量备份…
1

3.2.4.2 预备增量备份…
1

3.2.5 使用归档日志做增量备份…
1

3.2.5.1 原理… 1

3.2.5.2 创设备份…
1

3.2.5.3 使用归档日志来预备备份…
1

3.2.6 部分备份和预备…
1

3.2.6.1 备份部分备份…
1

3.2.6.2 预备备份…
1

3.2.7 窄备份和预备…
1

3.2.7.1 创制窄备份…
1

3.2.7.2 预备窄备份…
1

3.2.7.3 备份还原…
1

3.2.8 其余效用…
1

3.2.8.1 节流备份…
1

3.2.8.2 使用脚本调用xtrabackup来执行备份…
1

3.2.8.3 分析表计算消息…
1

3.2.8.4 使用binary log.
1

3.2.8.5 还原单个表…
1

3.2.8.6 LRU dump备份… 1

3.2.8.7 xtrabackup的限制… 1

3.2.8.8
References1

3.2.9 xbstream..
1

3.2.10
xbcrypt1

3.2.11 Xtrabackup原理… 1

4 如何运用和案例(How-tos and
Recipes)1

4.1 innobackupex案例… 1

4.1.1 本地全备(备份,预备,还原)1

4.1.2 使用Stream备份… 1

4.1.3 创制增量备份…
1

4.1.4 成立压缩备份…
1

4.1.5 备份还原独立分区…
1

4.1.5.1 创造备份…
1

4.1.5.2 预备备份… 1

4.1.5.3 从备份还原…
1

4.2 xtrabackup案例… 1

4.3 其余案例…
1

4.3.1 七个步骤安装二个slave.
1

4.3.2 再追加3个slave.
1

4.3.3 使用复制和pt-checksum验证备份…
1

4.3.4 怎样创建基于GTID的Slave. 1

4.4协理理工科程师具手册…
1

参考… 1

 

Percona Xtrabackup 2.4.1

Xtrabackup蕴含八个主要工具:Xtrabackup和innobackupex:

2 安装XtraBackup

此处只介绍yum和rpm安装方式

其它装置格局查看:

§  Installing Percona XtraBackup from Binaries

§  Compiling and Installing from Source Code

编写翻译及软件正视

Xtrabackup只好备份InnoDB和XtraDB两种引擎表,而无法备份MyISAM数据表。

2.1 安装XtraBackup binary版本

centos5,6
供给升级cmake至2.8.2版本以上,消除:安装cmake版本3.4.3测试通过

innobackupex则是参照InnoDBHotbackup的innoback脚本修改而来的一个perl脚本,它包裹了xtrabackup,首即便为了能造福的同时备份InnoDB和MyISAM引擎表。但在拍卖MyISAM时索要加一个读锁,那会阻塞线上劳动的写操作,所以数据库中MyISAM表越少越好。别的,该工具还参预了部分别样使用接纳,比如slave-info,能够在备份中记录一些Slave须要的消息,依据这一个消息,能够很便利的施用备份重做Slave。

2.1.1 yum的装置格局:

自动


$ rpm -Uhv
http://www.percona.com/downloads/percona-release/percona-release-0.0-1.x86\_64.rpm

然后晤面到:

Retrieving
http://www.percona.com/downloads/percona-release/percona-release-0.0-1.x86\_64.rpm

Preparing…               
###########################################
[100%]

   1:percona-release       
###########################################
[100%]

手动


[percona]

name = CentOS $releasever – Percona

baseurl=http://repo.percona.com/centos/$releasever/os/$basearch/

enabled = 1

gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-percona

gpgcheck = 1

测试安装库


使用yum list | grep percona来确认保证卫安全装

yum list | grep percona

汇合世以下信息:

percona-release.x86_64                     0.0-1                      
installed

Percona-Server-client-51.x86_64            5.1.47-rel11.1.51.rhel5    
percona

Percona-Server-devel-51.x86_64             5.1.47-rel11.1.51.rhel5    
percona

Percona-Server-server-51.x86_64            5.1.47-rel11.1.51.rhel5    
percona

Percona-Server-shared-51.x86_64            5.1.47-rel11.1.51.rhel5    
percona

Percona-Server-test-51.x86_64              5.1.47-rel11.1.51.rhel5    
percona

xtrabackup.x86_64                          1.2-22.rhel5               
percona

 

centos5 gcc g++ 必要升高gcc至4.4以上上
,消除:安装4.4.7测试通过

透过Xtrabackup,不但可在线(热)备份整个库的InnoDB、XtraDB表,还可在上二回整库备份的基础上做增量备份(InnoDB
only),其行事原理如下:

2.1.2 直接下载rpm包安装

行使wget下载rpm包,然后通过rpm包安装

参考:http://www.cnblogs.com/cosiray/archive/2012/03/02/2376595.html

 

其余xtrabackcup别的Boost版本要求1.59.0本子或以上,近年来centos5,6默许是1.41.0。化解:升级至1.59.0

先是形成3个通通备份,并记录下此时检查点的LSN(Log Sequence
Number);在实行增量备份时,相比较表空间中种种页的LSN是不是当先上次备份时的LSN,假使是,则备份该页,同时记录当前检查点的LSN。

3 XtraBackup使用手册

GTID扶助意况

小心:在增量备份时,作为备份基础的全备文件无法减弱,不然备份失效;其余,增量备份时期,表结构改变的话,变更部分的备份也会失灵。

3.1 使用innobackupex脚本

innobackupex是perl脚本对xtrabackup的卷入,和效率扩展。

测试5.6,5.7敞开GTID下得以健康备份,还原

二、安装

3.1.1 备份预备工作

权限和三番五次


xtrabackup须求三番五次到数据库和datadir操作权限。

xtrabackup只怕innobackupex在动用进程中陈设到2类用户权限:

1.连串用户,用来调用innobackupex可能xtrabackup

2.数据库用户,数据库Nelly用的用户

 

连接到服务:innobackupex恐怕xtrabackup通过—user和—password连接到数据库服务

$ innobackupex –user=DBUSER –password=SECRET /path/to/backup/dir/

$ innobackupex –user=LUKE  –password=US3TH3F0RC3 –stream=tar ./ |
bzip2 –

$ xtrabackup –user=DVADER –password=14MY0URF4TH3R –backup
–target-dir=/data/bkps/

其他总是选项

Option

Description

–port

The port to use when connecting to the database server with TCP/IP.

–socket

The socket to use when connecting to the local database.

–host

The host to use when connecting to the database server with TCP/IP.

 

内需的权杖:连接到服务是为着履行备份,必要在datadir上有read,write和execute权限。在数据库中供给以下放权力限:

Ÿ   RELOAD和LOCK
TABLES权限为了进行FLUSH TABLES WITH READ
LOCK   。

Ÿ   REPLICATION CLIENT为了取得binary log 地点

Ÿ   CREATE
TABLESPACE权限为了导入表,用户表级其余复原

Ÿ   SUPEXC60权限在slave环境下备份用来运维和关闭slave线程

 

mysql>CREATEUSER'bkpuser'@'localhost' IDENTIFIED BY's3cret';

mysql>GRANT RELOAD, LOCK TABLES, REPLICATION CLIENT ON*.*TO'bkpuser'@'localhost';

mysql> FLUSH PRIVILEGES;

对MySQL5.5,MySQL5.6本子协助

Pecona官方网站提供了Xtrabackup源码包、二进制包以及XC90PM包两种安装包,下载地址为:http://www.percona.com/downloads/XtraBackup/
本文采用最简便易行方便的CRUISERPM包安装,如下:

3.1.2 全备和全备还原

5.6在开启和倒闭gtid格局下都能够平常备份还原

[[email protected]
~]# rpm -ivh percona-xtrabackup-2.0.5-499.rhel5.x86_64.rpm

3.1.2.1 使用innobackupex成立全备

制造全备

$ innobackupex --user=DBUSER --password=DBUSERPASS /path/to/BACKUP-DIR/

会输出以下新闻

innobackupex: Backup created in directory '/path/to/BACKUP-DIR/2013-03-25_00-00-09'

innobackupex: MySQL binlog position: filename 'mysql-bin.000003', position 1946

111225 00:00:53  innobackupex: completed OK!

从音讯中会发现备份被创制在/path/to/BACKUP-DI奇骏/二〇一三-03-25_00-00-09

 

里面机制:在备份的时候innobackupex会调用xtrabackup来备份innodb表,并复制全数的表定义,其余内燃机的表(MyISAM,MEGL450GE,CSV,A宝马7系CHIVE)。

 

其他选项:

–no-timestamp,钦命了那些选项备份会间接备份在BACKUP-DI库罗德,不再成立时间戳文件夹。

–default-file,指定安顿文件,用来布署innobackupex的选线。

5.5足以平常备份还原

warning: percona-xtrabackup-2.0.5-499.rhel5.x86_64.rpm:Header V4 DSA
signature: NOKEY, key ID cd2efd2a

3.1.2.2 使用innobackupex预备全备

创办完备份之后数据被没有当即能够被苏醒,必要回滚未提交业务,前滚提交业务,让数据库文件保持一致性。

innobackupex使用—apply-log来做准备备份

$ innobackupex –apply-log /path/to/BACKUP-DIR

打响则会输出:

111225  1:01:57  InnoDB: Shutdown completed; log sequence number 1609228

111225 01:01:57  innobackupex: completed OK!

水到渠成后,备份能够被用来复苏数据库了。

 

当中机制:读取备份文件夹中的配置文件,然后innobackupex重做已交给业务,回滚未提交业务,之后数据就被写到了备份的数据文件(innodb文件)中,同等对待建日志文件。这一步隐式调用了2次xtrabackup
–prepare。跟多关于xtrabackup能够看未来的章节。

 

其余选拔:

–user-memory:钦赐预备阶段可使用的内部存款和储蓄器,内部存款和储蓄器多则速度快,私下认可为10MB

$ innobackupex –apply-log –use-memory=4G /path/to/BACKUP-DIR

5.6局部表导出还原测试平常

Preparing…
###########################################
[100%]

3.1.2.3 使用innobackupex还原备份

利用innobackupex –copy-back来回复备份

$ innobackupex –copy-back /path/to/BACKUP-DIR

会依据my.cnf复制全体备份到datadir下:

innobackupex: Finished copying back files.

 

111225 01:08:13  innobackupex: completed OK!

 

注:datadir必须是为空的,innobackupex
–copy-back不会覆盖已存在的文件,还要小心,还原时索要先关闭服务,如果服务是开行的,那么就无法还原到datadir。

 

从此须求修改文件的持有者和权力:

$ chown -R mysql:mysql /var/lib/mysql

对现有版本结合新特点的建议

1:percona-xtrabackup
###########################################
[100%]

3.1.3 增量备份和恢复生机

增量备份呢是为着削减空间应用和备份的时刻。

增量备份的兑现,重视于innodb页上面的LSN(log sequence
number),每一回对数据库的修改都会造成LSN自增。

增量备份会复制钦点LSN之后的具备数据页。

近期线上版本大多数在1.6.3和1.5版本。很多供给是透过第3方工具支持。结合2.4.1的新特色和release历史和近日景况,提出几点如下:

安装达成后,会在/usr/bin/目录下转移如下命令工具:

3.1.3.1 成立增量备份

成立全备


在开创增量备份以前供给多个全备,不然增量备份是没有意义的。

$ innobackupex /data/backups

如此就会在/data/backups下开创三个时间戳文件夹,如 /data/backups/二〇一二-03-31_23-01-18,然后文件夹内是备份文件。

自笔者批评备份文件夹下的xtrabackup-checkpoints,会有须臾间音讯:

backup_type = full-backuped

from_lsn =0

to_lsn =1291135

 

开创第3个增量备份


接下来利用—incremental创建增量备份

$ innobackupex –incremental /data/backups –incremental-basedir=BASEDIR

BASEDIKoleos指向此前的全备, /data/backups/2011-03-31_23-01-18,成功后备份会生成在/data/backups下的时刻戳目录中,如:/data/backups/二〇一三-04-01_23-01-18 ,把这么些目录叫为记为 INCREMENTAL-DI大切诺基-1方面随后选拔。

接下来查看xtrabackup-checkpoints:

backup_type = incremental

from_lsn =1291135

to_lsn =1352113

能够窥见和全备分化的是,backup_type为incremental,from_lsn不为0。

 

然后更创设三个增量备份


在INCREMENTAL-DI翼虎-1的根基上再创制二个增量备份,记为INCREMENTAL-DI冠道-2。

$ innobackupex –incremental /data/backups
–incremental-basedir=INCREMENTAL-DIR-1

 

增量备份替代格局


能够行使钦定—incremental-lsn来代替—incremental-basedir的不二法门创立增量备份。

innobackupex –incremental /data/backups –incremental-lsn=1291135

innobackupex –incremental /data/backups –incremental-lsn=1358967

 

留意:xtrabackup只会潜移默化xtradb只怕innodb的表,其余汽油发动机的表在增量备份的时候只会复制整个文件,不会距离。

*
xtrabackup支持非Innodb表备份,并且Innobackupex在下一本子中移除,提出通过xtrabackup替换innobackupex

[[email protected]
~]# cd /usr/bin/

3.1.3.2 预备增量备份

准备增量备份需求一个步骤:

1.索要先预备全备,不过只重做已提交业务,不回滚未提交业务,然后使用到全备,也是只重做已交付业务,不回滚未提交业务

2.回滚未提交业务

万一已经回滚了未提交业务,那么就不可能再利用增量备份。

注:在mariadb 10.0 上测试发现不加—redo-only预备全备,然后采纳 –redo-only应用增量备份,mysql服务能够健康运转并且数据被成功还原

 

在全备上,使用—redo-only只做已交付业务,不回滚未提交业务


innobackupex –apply-log –redo-only BASE-DIR

会冒出以下结果:

120103 22:00:12 InnoDB: Shutdown completed; log sequence number 1291135

120103 22:00:12 innobackupex: completed OK!

 

行使首个增量备份


innobackupex --apply-log --redo-only BASE-DIR --incremental-dir=INCREMENTAL-DIR-1

出口结果,注意LSN的转变:

120103 22:08:43 InnoDB: Shutdown completed; log sequence number 1358967

120103 22:08:43 innobackupex: completed OK!

若果没有点名—incremental-dir,那么innobackupex会利用以来的多少个在basedir中被成立的子目录。

 

行使此外3个备份


innobackupex –apply-log BASE-DIR –incremental-dir=INCREMENTAL-DIR-2

因为是最终一个增量备份所以并未供给再加—redo-only,这样结尾贰个增量也被使用到全备上了。

注:–redo-only除了最后三个永不加之外,其余的增量应用都要加,最后两个选取的时候可以直接进入回滚未提交业务阶段。借使加了也没关系,服务运行的时候会进去recovery进程,来回滚

 

须求小心的是,应用增量备份的时候只好依据备份的依次来使用。假诺利用顺序错误,那么备份就不可用。如果不可能鲜明顺序,能够利用xtrabackup-checkpoints来规定顺序。

 

回滚未提交业务


当使用完全体增量备份的时候,就要求回滚全数为成功业务(若是最终一步加了
–redo-only就要求回滚未提交,不实施的话在服务运维阶段服务会处理未提交业务)。

innobackupex –apply-log BASE-DIR

 

Note that the iblog* files will not be created by innobackupex, if you want them
to be created, use xtrabackup –prepareon the
directory. Otherwise, the files will be created by the server once
started.

注:

文中提到innodb事务日志(iblog*)不会被创立,可是测试下行使了末了一步回滚未提交业务发现有iblog*文本,而且上文提到 innobackupex会隐式执行五回 xtrabackup –prepare,在下文介绍xtrabackup时会提到,执行贰遍xtrabackup
–preare会创立iblog*文件,与文中涉及不符。

*
流式备份通过–stream钦定格式为xbtream而代替tar,补助streaming格式的相互备份和压缩

[[email protected]
bin]# ls xtr* inno*

3.1.3.3 还原增量备份

平复增量备份其实和苏醒全备一样

innobackupex –copy-back BASE-DIR

注意事项能够看:使用innobackupex还原备份

*
以前脚本使用第壹方压缩工具pbzip2举行压缩。建议通过–compress
和–compress-threads选项进行互相压缩

innobackupex innochecksum xtrabackup_51 xtrapchar xtrapinfo xtrapproto
xtrapstats

3.1.3.4 能够动用流做增量备份

先实行三个全备:

innobackupex /data/backups

应用当地:

innobackupex –incremental –incremental-lsn=LSN-number
–stream=xbstream ./ > incremental.xbstream

解包方法

xbstream -x < incremental.xbstream

运用当地备份流到长途并解包

innobackupex  –incremental –incremental-lsn=LSN-number
–stream=xbstream ./ | /

ssh
[email protected]
cat – | xbstream -x -C > /backup-dir/”

*
钦定–safe-slave-backup,增添备份的一致性。(那个选项截至SQL线程并且等到show
status中的slave_open_temp_tables为0的时候先导备份,倘若没有打开近年来表,bakcup会马上初阶,不然SQL线程运行只怕关闭知道没有打开的一时表。假诺slave_open_temp_tables在–safe-slave-backup-timeount(暗中认可300秒)秒现在不为0,从库sql线程会在备份完毕的时候重启)

innobackupex-1.5.1 xtrabackup xtrabackup_55 xtrapin xtrapout xtrapreset

3.1.4 部分备份和还原

xtrabackup能够选择一些备份,不过只万幸1个表二个文本的气象下才能采用,设置mysql选项:innodb_file_per_table。

平复部分备份使用表导入的艺术,而不是—copy-back选项。

固然不少现象下能够通过直接复制文件的办法,不过会生出一致性难点不提议选拔。

* 内定–rsync选项,加速备份过程(为了加速备份进度,同时减小FLUSH TBALES WITH READ
LOCAK阻塞写的小时,当该选用钦点时innobackupex使用rsync拷贝全数的非InnoDB文件替换cp。尤其适用于有恢宏的库和表的时候会更快。innobackup会调用rsync两回。① 、执行flush
tables with read lock前后
;② 、收缩读锁被抱有的日子内。因为第三调用在刷新读锁在此以前,所以它独自一起那一个非事务的数量的变通)

其中:

3.1.4.1 成立部分备份

一些备份有3个选项能够动用:

–include:设置正则表达式的格式,匹配的就备份

–table-file:在文书中内定要备份的表,然后通过这一个选项传入文件

–database:钦赐数据库列表

 

使用include方式


include 方式数据库名也得以合营:

$ innobackupex –include=’^mydatabase[.]mytable’
/path/to/backup                 

本条选项是传给xtrabackup
–tables,全数的数据库目录都会被成立,然则里面大概是空的。

 

使用tables-file方式


如:

$ echo “mydatabase.mytable” > /tmp/tables.txt

$ innobackupex –tables-file=/tmp/tables.txt /path/to/backup

这么些选项是运用xtrabackup
–tablefile,唯有匹配到表的数据库目录才会被创制

 

使用database方式


innobackupex能够传递用空格隔离的数组,格式为:databasename[.tablename]

$ innobackupex –databases=”mydatabase.mytable mysql” /path/to/backup

 

注意:–databasees选项只会对非innodb引擎表和frm文件发出震慑,对于innodb数据文件总是备份的

 

*
针对紧密备份和增量备份在固然有些场景下越发有用,与刘伟先生商量过暂且继续先不做陈设成功统一版本中去

innobackupex
是备份时一直运用的工具,它是3个perl脚本,内部封装xtrabackup;

3.1.4.2 预备部分备份

部分备份的备选须要选拔—export:

$ innobackupex –apply-log –export /path/to/partial/backup

会并发以下,是因为innodb表保存了数据文件不过从未保留frm文件。

111225  0:54:06  InnoDB: Error: table
‘mydatabase/mytablenotincludedinpartialb’

InnoDB: in InnoDB data dictionary has tablespace id 6,

InnoDB: but tablespace with that id or name does not exist. It will be
removed from data dictionary.

以往会意识生成了.exp和.cfg文件。exp文件适用于percona
server,cfg适用于mariadb和mysql。mariadb 10.0方可一向通过ibd和frm文件import。mysql
5.6后头方可不选拔cfg来拓展import,cfg假设存在会被用来做表结构的求证。

在曾经准备好的备份上,能够利用—export和—apply-log创设.exp文件。

release历史

innobackupex-1.5.1 是innobackupex文件的三个软链接;

3.1.4.3 还原部分备份

先创立3个表,表结构需求和被恢复生机的均等。

OTHERSERVER|mysql> CREATE TABLE mytable (…) ENGINE=InnoDB;

然后discard表空间

OTHERSERVER|mysql> ALTER TABLE mydatabase.mytable DISCARD TABLESPACE;

事后把文件复制到相应的目录下(注意文件的主人和文书权限),供给文件.ibd,.exp大概.cfg文件(.cfg文件用户mysql5.6)。

然后import表空间

OTHERSERVER|mysql> ALTER TABLE mydatabase.mytable IMPORT TABLESPACE;

2.4.1 支持MySQL5.7(5.7.10)

xtrabackup 是备份Innodb引擎的剧本;

3.1.5 窄备份

窄备份指不备份secondary索引数据。那样可以收缩备份的分寸。缺点正是亟需重建索引,会非常慢。

2.3.2
命令行语法跟随MySQL5.6的变更而变化。此外命令行辅助–datadir

xtrabackup_51 xtrabackup运营时索要调用的工具,适用于MySQL 5.1版本;

3.1.5.1 创立窄备份

$ innobackupex –compact /data/backups

创办了随后查看xtrabackup_checkpoint

backup_type = full-backuped

from_lsn =0

to_lsn =2888984349

last_lsn =2888984349

compact =1

compact=1表明该备份是窄备份。

 

2.3.1
innobackupex脚本用c重写,并且只是xtrabackup的符号连接。innobackupex援救2.2版本全部的表征,但是当前已降级在下个Major版本中移除,innobackupex将不支持具有新特色的语法,同时xtrabackup未来支撑MyISAM的正片并且协助innobakcupex的拥有个性。innobackupex先前特点的语法xtrabackup同样支撑

xtrabackup_55 xtrabackup运转时索要调用的工具,适用于MySQL 5.5版本;

3.1.5.2 预备窄备份

在预备窄备份的时候需求选取—rebuild-indexes来重新创造索引

$ innobackupex –apply-log –rebuild-indexes
/data/backups/2013-02-01_10-29-48

从出口上能够见到索引被重建

130201 10:40:20  InnoDB: Waiting for the background threads to start

Rebuilding indexes for table sbtest/sbtest1 (space id: 10)

  Found index k_1

  Dropping 1 index(es).

  Rebuilding 1 index(es).

Rebuilding indexes for table sbtest/sbtest2 (space id: 11)

  Found index k_1

  Found index c

  Found index k

  Found index c_2

  Dropping 4 index(es).

  Rebuilding 4 index(es).

对此增量备份的应用能够先不重建索引,在利用最后一个距离备份的时候利用—rebuild-index来创设索引,每一回都利用都重建索引太花时间。

 

只顾:为了重建速度,能够使用并发创设索引,使用参数—rebuild-threads钦赐并发数。

2.2.21 支持5.6(基于5.6.24版本)

三、Xtrabackup的使用

3.1.5.3 还原窄备份

窄备份还原和全备还原一样直接使用—copy-back选项。

切实看:使用innobackupex还原备份

2.2.8 基于5.6.22 (消除当总redo
log超越4G,prepare会失利的题材)

第叁来学学使用Xtrabackup那个命令工具,后面提到:它只好备份InnoDB和XtraDB二种引擎表,不能够备份MyISAM数据表。

3.1.6 备份加密

具体看:Encrypted Backups

2.2.6 通过show
variables读取Mysql选项。在起头化表扫描的时候输出更详细音讯

通过–help参数查看该命令的用法,如下:

3.1.7 其他职能

2.2.5 基于5.6.21

Usage: [xtrabackup [–default-file=#] –backup | xtrabackup
[–defaults-file=#] –prepare] [OPTIONS]

3.1.7.1 备份压缩和流

Stream情势下,Xtrabackup的STDOUT能够钦点tar或许xbstream格式输出。

流允许,其余程序过滤备份输出,提供更大的利落存款和储蓄backup。

行使流性情,必要钦定—stream选项

$ innobackupex –stream=tar /tmp

innobackupex会用子程序运行xtrabackup –log-stream 定向到目前文件,然后利用xbstream把富有数据文件steam到STDOUT。

 

当压缩运转,xtrabackup压缩全体出口数据,可是元数据和非innodb文件不能够被减弱。今后唯一帮助的压缩算法是quicklz。会生产qpress归档格式的文件。

利用xbstream能够平法复制压缩能够增强备份速度。

 

使用xbstream流备份:

$ innobackupex –stream=xbstream /root/backup/ >
/root/backup/backup.xbstream

行使流压缩:

$ innobackupex –stream=xbstream –compress /root/backup/ >
/root/backup/backup.xbstream

解包:

$ xbstream -x <  backup.xbstream -C /root/backup/

流压缩并备份到其它一台机械:

$ innobackupex –compress –stream=xbstream /root/backup/ | ssh
[email protected]
“xbstream -x -C /root/backup/”

 

使用tar备份:

$ innobackupex –stream=tar /root/backup/ > /root/backup/out.tar

应用tar流并备份到其它服务器

$ innobackupex –stream=tar ./ | ssh
[email protected]
\ “cat – > /data/backups/backup.tar”

提取tar流,需要加i参数

$ tar -xizf backup.tar.gz

也足以压缩流

$ innobackupex –stream=tar ./ | gzip – > backup.tar.gz

$ innobackupex –stream=tar ./ | bzip2 – > backup.tar.bz2

2.2.1 移除xtrabackup_56
xtrabakcup_55,只保留xtrabakcup.移除Build脚本,支持cmake编译。基于5.6.16

参数解读如下:

3.1.7.2 在复制环境下备份

有二个选项用于从复制环境下备份

 

slave-info


–slave-info,会打字与印刷binary
log的职位和master server名,并且以change master的办法写到xtrabackup_slave_info中。

 

safe-slave-backup


–safe-slave-backup,为了确定保证复制状态的一致性,这么些选项会关闭slave sql线程,等待直到SHOW
STATUS 中的Slave_open_temp_tabls为了才运转备份。要是等待时间超越—safe-slave-backup-timeout就会报错暗中认可300秒。备份成功后 slave sql
thread会自动运转。

 

2.1.6 innobackupex –force-non-empty-directories

–defaults-file=#

3.1.7.3 加快备份进度

使用parallel和compress-threads加速


当有三个文件时,能够运用使用—parallel加快备份,这么些选项会钦赐xtrabackup备份文件的线程数。

$ innobackupex –parallel=4 /path/to/backup

借使运用xbstream能够设想通过—compress-threads加快削减进程,默许为1.

$ innobackupex –stream=xbstream –compress –compress-threads=4 ./ >
backup.xbstream

 

使用rsync加速


为了加快复制进程,最小化FLUSH TABLES WITH READ
LOCK堵塞时间,使用innobackupex
–rsync。使用了那一个选项全体文件都会在二个cp命令里面,而不是每一个文件3个cp。并且innobackupex会调用二次rsync,一次在履行FLUSH
TABLES WITH READ
LOCL此前,2回在现在。第一回实施的时候会把第三回未来的修改过的数据。

 

2.1.4 MySQL versions 5.1.70, 5.5.30, 5.6.11 

标识暗中同意的配置文件,可显式手工业钦赐,也可不安装;若不安装,则Xtrabackup缺省将从以下目录查找配置文件:

3.1.7.4 节流(throttling)备份

就算innobackupex不会堵塞数据库操作,可是备份终会消耗系统能源。为了削减少资本源消耗,能够应用—throttle来界定每分钟读写对次数。

innobackupex –no-lock
,拷贝非Innodb数据时不甘休复制线程,可是规格是备份时期非事务型表上不可能有DDL或许DML操作

/etc/my.cnf

3.1.7.5 还原独立表

选拔xtrabackup来导出钦定表,然后导入到XtraDB大概Mysql
5.6(测试能够的导入mariadb 10.0)

mariadb 10.0方可一直复制 ibd然后由此import
tablespace倒入。

 

导出表


导出表使用—export选项:

$ innobackupex –apply-log –export /path/to/backup

会在发现多了3个.exp文件和.cfg文件(用于差异的mysql版本)

$ find /data/backups/mysql/ -name export_test.*

/data/backups/mysql/test/export_test.exp

/data/backups/mysql/test/export_test.ibd

/data/backups/mysql/test/export_test.cfg

 

导入表


先成立三个表,表结构须要和被复苏的一致。

OTHERSERVER|mysql> CREATE TABLE mytable (…) ENGINE=InnoDB;

然后discard表空间

OTHERSERVER|mysql> ALTER TABLE mydatabase.mytable DISCARD TABLESPACE;

自此把公文复制到相应的目录下(注意文件的全数者和文件权限),必要文件.ibd,.exp或然.cfg文件(.cfg文件用户mysql5.6)。

然后import表空间

OTHERSERVER|mysql> ALTER TABLE mydatabase.mytable IMPORT TABLESPACE;

 

innobackupex –decrypt and innobackupex
–decompress,

/etc/mysql/my.cnf

3.1.7.6 时间点复苏

和mysql手册中牵线的时光点过来一样,xtrabackup也是透过binary
log进行时间点苏醒。

先举办备份

$ innobackupex /path/to/backup –no-timestamp

接下来进行准备

$ innobackupex –apply-log /path/to/backup

 

在服务器中找出操作binary log和日前binary log状态

mysql> SHOW BINARY LOGS;

+——————+———–+

| Log_name         | File_size |

+——————+———–+

| mysql-bin.000001 |       126 |

| mysql-bin.000002 |      1306 |

| mysql-bin.000003 |       126 |

| mysql-bin.000004 |       497 |

+——————+———–+

mysql> SHOW MASTER STATUS;

+——————+———-+————–+——————+

| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |

+——————+———-+————–+——————+

| mysql-bin.000004 |      497 |              |                  |

+——————+———-+————–+——————+

然后查看 xtrabackup_binlog_info显著备份的binary log地方:

$ cat /path/to/backup/xtrabackup_binlog_info

mysql-bin.000003      57

复原数据库

$ innobackupex –copy-back /path/to/backup

然后选择mysqlbinlog取出binary log中的记录,然后输出到文件

$ mysqlbinlog /path/to/datadir/mysql-bin.000003
/path/to/datadir/mysql-bin.000004 \

    –start-position=57 > mybinlog.sql

然后检查输出的文件,分明要上升到的职位,然后实施恢复生机

$ mysqlbinlog /path/to/datadir/mysql-bin.000003
/path/to/datadir/mysql-bin.000004 \

    –start-position=57 –stop-datetime=”11-12-25 01:00:00″ | mysql -u
root -p

 

2.1.1
帮忙紧密备份,加密备份。不在协助5.0内置Innodb和5.1内置Innoddb。移除–remote-host选项

/usr/local/etc/my.cnf

3.1.7.7 提高对FLUSH TABLES WITH READ LOCK控制

在备份的时候,为了保险数据一致性,在备份非innodb表的事先会先使用FLUSH
TABLES WITH READ
LOCK,这一个讲话在有长日子查询运维的情事下也能履行,不过其余的全部事都会被堵塞,Waiting for table flush大概Waiting for master to send
event,那一个时候不应该kill FLUSH TABLES WITH
READ LOCK,而是应该kill掉那多少个大的询问。因为当有大的询问的时候,FLUSH TABLES WITH READ LOCK会被卡住。

 

为了能够制止那种事情时有爆发须要达成二个工作:

1.innobackupex等一个好的空子运营

2.innobackupex得以kiil
全数查询可能只好存在SELECT查询。即kill全体阻止获取全局锁的询问。

 

等候查询达成


为了防止innobackupex等待FLUSH TABLES WITH READ
LOCK执行太长期,能够行使innobackupex
–lock-wait-timeout,能够用来界定等待时间,一旦过期就会报错退出。

 

其余3个是设置等待查询的门类,innobackupex
 –lock-wait-query-type 可取的值是all恐怕update,要是为all那么会等待全体长运营查询完结,假如是update,会等待除select之外的DML实现。

 

–lock-wait-threshold用来定义 –locl-wait-query-type中的长运营查询,纵然跨越–lock-wait-threshold都算长运转查询。

 

Kill堵塞查询


innobackupex能够kill全数阻止获取全局锁的询问。

能够由此点名–kill-long-queries-timeout用来钦命执行FLUSH TABLES WITH READ LOCK后还是能够进行的年月,0为不kill,–kill-long-query-type用来钦定超时过后,kill的查询类型,能够是all大概select。

 

例如:

$ innobackupex –lock-wait-threshold=40 –lock-wait-query-type=all
–lock-wait-timeout=180 –kill-long-queries-timeout=20
–kill-long-query-type=all /data/backups/

2.1.0 帮助mysql5.6的持有特性(GTID,
可活动表空间,独立undo表空间,5.6体制的buffer pool导出文件)

~/.my.cnf

3.1.8 innobackupex工作原理

innobackupex是perl脚本,封装了xtrabackup和tar4ibd的功能。

 

备份


要是没有点名,innobackupex默许认为是备份方式。

 

暗中认可innobackupex会以–suspend-at-end运维xtrabackup,来复制innodb文件。当xtrabackup复制实现,innobackupex发现成立的xtrabckup_suspended_2文本,就推行FLUASH TABLES WITH READ LOCL复制其余文件。

 

xtrabackup的规定,假如运维的时候从不带ibbackup参数,那么innobackupex会从xtrabackup_binary上找,然后读取要运转xtrabackup的二进制文件。否则只可以通过连接mysql服务显著使用的二进制文件。如果无法一而再就漏洞百出。

控制好二进制文件从此,断开连接以二进制形式运维binary。

假若不是增量备份,连接受服务,要是开行了–safe-slave-backup等待slave,然后拿走全局read
lock,幸免其他内燃机的表被修改,读锁只锁定非innodb表,并且在innodb表复制完数据和日志后展开。

当全部文件备份完之后,复苏ibbackup并等待完毕对业务复制,复制在备份时期生产的事务。然后释放表锁,slave运营并且接二连三关闭,然后删除xtrabckup_suspended_2文件。

 

还原


复原数据库使用 –copy-back选项

 

innobackupex通过读取my.cnf中的 datadirinnodb_data_home_dirinnodb_data_file_path,innodb_log_group_home_dir并检讨目录是还是不是留存。

 

接下来复制MyISAM表,索引,然后复制innodb表和目录,最前几天志文件。复制的时候会保留文件属性,须求修改用户全数者。

过来除了–cop-back也得以选择–move-back,分裂的是二个是复制,一个是活动。

 

支撑5.6引入的innodb buffer pool预载。buffer pool
dumps能够转变依然导入加快开动。在备份时buffer pool
dump拷贝到备份目录,在还原星等拷贝回data目录,

接下来从中读取[mysqld]和[xtrabackup]配置段。[mysqld]中只需点名datadir、innodb_data_home_dir、innodb_data_file_path、innodb_log_group_home_dir、innodb_log_files_in_group、innodb_log_file_size那么些参数即可让Xtrabackup平常工作。

3.1.9 Reference

根本介绍一些挑选:The innobackupex Option Reference

–log-copy-interval
可配备log拷贝线程检查的间隔时间

–defaults-extra-file=#

3.2 使用Xtrabackup

假若打开gtid,xtrabackup_binlog_info储存gtid的值

若是应用了该参数,则会在读取了大局配置文件后,再读取那里钦点的陈设文件

3.2.1 选择bianry

Xtrabackup有4个binary:Xtrabackup,Xtrabackup_51,Xtrabackup_55,Xtrabackup_56。

服务和binary对照:

Server

xtrabackup binary

MySQL 5.1.*

xtrabackup_51

MySQL 5.1.* with InnoDB plugin

xtrabackup

MySQL 5.5.*

xtrabackup_55

MySQL 5.6.*

xtrabackup_56

MariaDB 5.1.*

xtrabackup

MariaDB 5.2.*

xtrabackup

MariaDB 5.3.*

xtrabackup

MariaDB 5.5.*

xtrabackup_55

MariaDB 10.0.*

xtrabackup_56

Percona Server 5.0

xtrabackup_51

Percona Server 5.1

xtrabackup

Percona Server 5.5

xtrabackup_55

Percona Server 5.6

xtrabackup_56

支撑xtrabackup
–export,那个选项生成5.6体裁的元数据文件。能够经过alter table import
tablespace导入

–target-dir=name

3.2.2 配置Xtrabackup

全体的Xtrabackup配置都以经过甄选设置,能够是命令行参数,也可以透过安排文件my.cnf。

xtrabackup会读取[mysql],[xtrabackup]选项,若Xtrabackup读入,会覆盖[mysqld]的选项。

并不是装有的配置都要写入配置文件,写配置文件只是为着有利于。

 

xtrabackup 并不接受和mysqld一样的语法,有个别语法不补助如,–set-variable=<variable>=<value>要用
–variable=value语法。

 

xtrabackup并不要求特殊的蕴藏,可是假若是NFS并不是以sync挂载,那么在实践fsync的时候恐怕并不是实在的同步数据。

 

2.0.5 –defaults-extra-file
存备份用户的用户名和密码的安顿文件

备份文件的存放路径

3.2.3 创造全备和还原

2.0.3 支持–move-back

–backup

3.2.3.1 创造全备

动用xtrabackup创制全备须求钦命选项-backup,还索要钦定–target_dir,假如target不设有,会创立三个,借使存在那么一旦是空的就会成功,要是或不是空的,不会覆盖已存在文件,并且报错。

 

根本完结2个义务:

1.打开2个log
copy线程,用来监控innodb日志文件(ib_logfile*),假诺改动就复制到xtrabackup_logfile,因为复制会不断相当长日子,所以回复进程需求全部从备份开首到结束的有所日志。

2.复制innodb数据文件到目的目录,这么些并不是不难的复制,是和innodb引擎一样,从数额目录中一页一页的复制。

 

当数据文件实现复制,xtrabackup会截止对日记的复制,并在目的目录中开创xtrabackup_checkpoint文件。

$ xtrabackup –backup –datadir=/var/lib/mysql/
–target-dir=/data/backups/mysql/

在备份输出的时候,能够看出日志的复制。

>> log scanned up to (3646475465483)

>> log scanned up to (3646475517369)

>> log scanned up to (3646475581716)

>> log scanned up to (3646475636841)

>> log scanned up to (3646475718082)

>> log scanned up to (3646475988095)

>> log scanned up to (3646476048286)

>> log scanned up to (3646476102877)

>> log scanned up to (3646476140854)

[01] Copying /usr/local/mysql/var/ibdata1

     to /usr/local/mysql/Backups/2011-04-18_21-11-15/ibdata1

[01]        …done

 

注意:日志复制线程是每秒检查一遍,查看是或不是有新的日志被写入,因为日志文件是被回绕写的,所以日志复制线程要更上日志文件的修改,假如没有复制日志被掩盖了,那么就会报错。

 

备份的岁月长短正视于数据库的深浅,然后时间都足以告一段落数据库,因为不会去修改数据库数据。

 

1.9.1
辅助压缩备份,此前能能streaming备份之后经过外部工具压缩

履行备份操作,将备份文件存放到target-dir内定的目录下

3.2.3.2 预备全备

备份完数据库之后,下一步是准备数据库,因为数据文件在某些时刻点上,并不是同一的,所以须求预备让数据文件在有个别时间点同样,–prepare便是来形成,让数据文件保持一致性。

 

留意:在innobackupex –apply-log的时候,innodb正是电动读取配置文件back-my.cnf正是接纳–defaults-file=xxx来钦命1个安顿文件,传递给xtrabackup用于预备数据库备份。

 

能够在其余机器上开展准备,没需要在原服务器大概要还原的服务器上实行。

在恢复生机阶段,xtrabackup嵌入了改动过的innodb,禁止了innodb的正式安全监察,如日志文件大小是或不是规范。

prepare阶段正是使用这些松手的innodb来做通过日记文件对数据文件进行crash苏醒。

xtrabackup –prepare –target-dir=/data/backups/mysql/

当预备达成就会有以下输出:

101107 16:40:15  InnoDB: Shutdown completed; log sequence number
<LSN>

今昔备份一致性已经没难点了,能够准备复苏,但是为了能够更快过来,能够再实施一次预备,第②次实践的时候只让数据文件保持一致性,并没有创建日志文件。首回执行的时候会创建日志文件。要是第三回预备后回复,运营服务,服务会自动成立日志文件,不过正如滑时间。当第一回运转预备的时候有弹指间输出:

$ xtrabackup –prepare –target-dir=/data/backups/mysql/

xtrabackup: This target seems to be already prepared.

xtrabackup: notice: xtrabackup_logfile was already used to ‘–prepare’.

101107 16:54:10  InnoDB: Log file ./ib_logfile0 did not exist: new to
be created

InnoDB: Setting log file ./ib_logfile0 size to <SIZE> MB

InnoDB: Database physically writes the file full: wait…

101107 16:54:10  InnoDB: Log file ./ib_logfile1 did not exist: new to
be created

InnoDB: Setting log file ./ib_logfile1 size to <SIZE> MB

InnoDB: Database physically writes the file full: wait…

101107 16:54:15  InnoDB: Shutdown completed; log sequence number 1284108

如假设第一遍运维,运营时会有以下提醒:

xtrabackup: This target seems to be already prepared.

xtrabackup: notice: xtrabackup_logfile was already used to ‘–prepare’.

不推荐在实践预备的时候终端进度,那样只怕会促成数据文件相当。

若是视图要进入增量备份,那么使用–apply-log-only,不然加不上增量备份。

支撑streaming增量备份

–prepare

3.2.3.3 还原全备

xtrabackup没有怎么效果来苏醒备份,可以一贯通过rsync,cp来还原数据库

留神:注意保持datadir必须是空的,并且mysql服务是终止的。不可能还原到已经在运行的mysql服务中。

通过rsync还原:

$ rsync -avrP /data/backup/ /var/lib/mysql/

回复后专注修改全体者

$ chown -R mysql:mysql /var/lib/mysql

专注:xtrabackup只备份innodb数据文件,不会备份其他斯特林发动机的表,和frm文件。假设要对总体库备份还原能够使用innodbbackupex

 

LRU DUMP

对备份文件执行恢复生机前的备选(生成InnoDB logfile)

3.2.4 增量备份和回复

1.6.4 innobackupex扶助–rsync选项
在datadir目录实行两阶段rsync(首先没有写锁,之后有写锁,)减少写锁具备的光阴

–print-param

3.2.4.1 增量备份

增量备份原理


xtrabackup和innobackupex都可以完成增量备份,也便是说只备份修改过的数目。

增量备份实现,注重于innodb页中的LSN(log sequence
number)增量备份会复制比从前的增量或然全备新的lsn页。

有2个算法找那样的页:

1.一向扫描数据页,并复制大于上次全备可能增量的lsn的页

2.近乎percona
server,运营 changed page tracking  会记录页的修改。那样的记录会被封存在三个map文件中。xtrabackup会使用这么些文件读取须求备份的页数据。当然也得以接纳–incremental-force-scan强制扫描全部数据页。

 

增量备份并不是比较全备的数额,假如没有上次的备份,能够利用钦定–incremental-lsn来展开增量备份。增量备份只会备份比钦命lsn大的数据页。当然须求全备来还原增量备份,否则增量备份是尚未意义的。

 

创设增量备份


第贰成立全备

xtrabackup –backup –target-dir=/data/backups/base
–datadir=/var/lib/mysql/

查看xtrabackup_checkpoint信息:

backup_type = full-backuped

from_lsn =0

to_lsn =1291135

下一场进行增量备份:

xtrabackup –backup –target-dir=/data/backups/inc1 \

–incremental-basedir=/data/backups/base –datadir=/var/lib/mysql/

在/data/backups/inc1下富含了delta文件,假设ibdata1.delta和test/table1.ibd.delta,检查增量备份的xtrabackup_checkpoint:

backup_type = incremental

from_lsn =1291135

to_lsn =1291340

在做1个增量备份:

xtrabackup –backup –target-dir=/data/backups/inc2 \

–incremental-basedir=/data/backups/inc1 –datadir=/var/lib/mysql/

 

打字与印刷备份或恢复生机时索要的参数

3.2.4.2 预备增量备份

预备增量备份和在innobackupex一样,先不回滚情势选择全备,然后选拔增量备份。

在innobackupex上运用 –apply-log-only来重做,但不回滚。

今昔已有备份:

/data/backups/base

/data/backups/inc1

/data/backups/inc2

准备全备,不回滚未提交业务:

xtrabackup –prepare –apply-log-only –target-dir=/data/backups/base

成功后输出:

101107 20:49:43  InnoDB: Shutdown completed; log sequence number 1291135

行使第②个增量备份:

xtrabackup –prepare –apply-log-only –target-dir=/data/backups/base \

–incremental-dir=/data/backups/inc1

增量备份被运用到/data/backups/base,应用后输出:

incremental backup from 1291135 is enabled.

xtrabackup: cd to /data/backups/base/

xtrabackup: This target seems to be already prepared.

xtrabackup: xtrabackup_logfile detected: size=2097152,
start_lsn=(1291340)

Applying /data/backups/inc1/ibdata1.delta …

Applying /data/backups/inc1/test/table1.ibd.delta …

…. snip

101107 20:56:30  InnoDB: Shutdown completed; log sequence number 1291340

利用最终一个增量备份:

xtrabackup –prepare –target-dir=/data/backups/base \

–incremental-dir=/data/backups/inc2

 

专注:除了最终三个外其他的都要选用–apply-log-only,如若最终二个也用了–apply-log-only,就还原了文本只怕平昔的,可是从未回滚未提交业务,当服务运转的时候会自动回滚未提交业务。

 

 

–use-memory=#

3.2.5 使用归档日志做增量备份

感兴趣的可将来后看。。。。。。

该参数在prepare的时候利用,控制prepare时innodb实例使用的内部存储器量

3.2.5.1 原理

在percona server
5.6.11-60.3加盟了新职能,为xtradb日志归档,那一个效果是,在老的日记文件被重写此前会被复制,因而保存了装有的redo日志。

归档日志的文件格式,ib_log_archive_<LSN>,LSN表示那一个归档文件开端的lsn。

ib_log_archive_00000000010145937920

ib_log_archive_00000000010196267520

 

本条效用由innodb_log_archive运转,保存的地方为innodb_log_arch_dir(默许为数据文件夹)。

 

————————————————————————————————————————————————————————————————————————————————————————————————————

–suspend-at-end

3.2.5.2 创设备份

开创三个全备

xtrabackup_56 –backup –target-dir=/data/backup/
–datadir=/var/lib/mysql/

xtrabackup_checkpoint如下:

backup_type = full-backuped

from_lsn =0

to_lsn =1546908388

last_lsn =1574827339

compact =0

xtrabackup首要职能测试

在target-dir目录下发出3个xtrabackup_suspended文件,将xtrabackup进程挂起,不停地将数据文件的更动同步到备份文件,直到用户手工业删除xtrabackup_suspended文件

3.2.5.3 使用归档日志来准备备份

xtrabackup_56 –prepare –target-dir=/data/backup/
–innodb-log-arch-dir=/data/archived-logs/

进行后翻看xtrabackup_checkpoint,backup-type被修改:

backup_type = full-prepared

from_lsn =0

to_lsn =1546908388

last_lsn =1574827339

compact =0

别的也得以内定时间点准备:

xtrabackup_56 –prepare –target-dir=/data/backup/
–innodb-log-arch-dir=/data/archived-logs/ –to-archived-lsn=5536301566

innobackupex

–throttle=#

3.2.6 部分备份和准备

当服务应用innodb_file_per_table的时候,xtrabackup协助部分备份。

创办本地Full Backup(创设,prepare,还原)

每分钟IO次数,限制backup时使用的I/O操作量,使备份对数据库不奇怪工作的震慑最小化

3.2.6.1 备份部分备份

利用–tables进行部分备份


运用–tables备份,该选取的值是一个正则表明式,匹配的表名都会被备份。

备份test下的全部表:

$ xtrabackup –backup –datadir=/var/lib/mysql
–target-dir=/data/backups/ \

–tables=”^test[.].*”

备份test.t1表

$ xtrabackup –backup –datadir=/var/lib/mysql
–target-dir=/data/backups/ \

–tables=”^test[.]t1″

 

应用–tables-file实行备份


–tables-file指向1个摘取包了表名,如:

$ echo “mydatabase.mytable” > /tmp/tables.txt $ xtrabackup –backup
–tables-file=/tmp/tables.txt

然后隐去–defaults-file=/data1/mysql5711/my5711.cnf.bakuse
–no-timestamp –slave-info –socket=/tmp/mysql5711.sock –user=mysqlha
–password=xxx 等选项

–log-stream

3.2.6.2 预备备份

在prepare的时候会现出许多warnings,是因为表存在在innodb,可是对于的ibd不设有,这么些表在还原备份运转innodb的时候会被去除。

InnoDB: Reading tablespace information from the .ibd files…

101107 22:31:30  InnoDB: Error: table ‘test1/t’

InnoDB: in InnoDB data dictionary has tablespace id 6,

InnoDB: but tablespace with that id or name does not exist. It will be
removed from data dictionary.

始建一份备份

该参数在backup时采纳,将xtrabackup_logfile的内容输出到标准输出,使用该参数时会自动使用suspend-at-end参数,innobackupex脚本的stream形式会使用该参数。

3.2.7 窄备份和准备

窄备份是在备份的是不是不备份secondary
index让备份文件边小。窄备份能够经过–compact运行。

innobackupex /data1/dbatemp/5711back

–incremental-lsn=name

3.2.7.1 成立窄备份

$ xtrabackup –backup –compact –target-dir=/data/backups

翻开备份后的xtrabackup_checkpoint,compact为1验证是窄备份

backup_type = full-backuped

from_lsn =0

to_lsn =2888984349

last_lsn =2888984349

compact =1

 

160321 10:56:00 innobackupex: Starting the backup
operation

增量备份时只拷贝LSN比该参数钦命值新的ibd
pages,前次备份到了哪个LSN能够看前次备份集的xtrabackup_checkpoints文件

3.2.7.2 预备窄备份

在预备的时候为了重建索引,须求选用选择–rebuild-indexes

$ xtrabackup –prepare –rebuild-indexes /data/backups/

输出:

[01] Checking if there are indexes to rebuild in table sakila/city
(space id: 9)

[01]   Found index idx_fk_country_id

[01]   Rebuilding 1 index(es).

[01] Checking if there are indexes to rebuild in table sakila/country
(space id: 10)

[01] Checking if there are indexes to rebuild in table sakila/customer
(space id: 11)

[01]   Found index idx_fk_store_id

[01]   Found index idx_fk_address_id

[01]   Found index idx_last_name

[01]   Rebuilding 3 index(es).

 

运用–rebuild-threads钦命重建的线程数,加速重建速度:

$ xtrabackup –prepare –rebuild-indexes –rebuild-threads=16
/data/backups/

输出:

Starting 16 threads to rebuild indexes.

 

[09] Checking if there are indexes to rebuild in table sakila/city
(space id: 9)

[09]   Found index idx_fk_country_id

[10] Checking if there are indexes to rebuild in table sakila/country
(space id: 10)

[11] Checking if there are indexes to rebuild in table sakila/customer
(space id: 11)

[11]   Found index idx_fk_store_id

[11]   Found index idx_fk_address_id

[11]   Found index idx_last_name

[11]   Rebuilding 3 index(es).

对于增量备份的使用能够先不重建索引,在应用最终二个距离备份的时候使用—rebuild-index来创制索引,每一遍都选取都重建索引太花时间。

 

–incremental-basedir=name

3.2.7.3 备份还原

选拔命令rsync可能cp来还原备份,和全备的复苏一样,请看:3.2.3.3还原全备

IMPORTANT: Please check that the backup run
completes successfully.

该参数在backup的时候利用,备份比该参数钦命地点的备份集新的idb pages

3.2.8 其他功用

           At the end of a successful
backup run innobackupex

–incremental-dir=name

3.2.8.1 节流备份

–throttle用来控制每秒io次数,一遍io,1MB。

澳门威尼斯人网址 2

只要在backup方式下,这一个选项用来决定读写对的每秒次数。

暗中认可不会节流,xtrabackup会读写是硬着头皮快的措施。

 

           prints “completed OK!”.

该参数在prepare的时候利用,钦点prepare时发生的delta文件和日志文件的寄放路径

3.2.8.2 使用脚本调用xtrabackup来执行备份

最典型的例子innobackupex,innobackupex是perl脚本调用xtrabackup来执行备份。

具体看:Scripting Backups With xtrabackup

 

 

–tables=name

3.2.8.3 分析表总括音信

切切实实查看:Analyzing Table Statistics

160321 10:56:00  version_check Connecting to MySQL
server with DSN ‘dbi:mysql:;mysql_read_default_group=xtrabackup;port=5711;mysql_socket=/tmp/mysql5711.sock’ as ‘mysqlha’ 
(using password:
YES).

在备份file-per-table类型的文书时选拔,使用正则表明式钦命须要备份的innodb表

3.2.8.4 使用binary log

xtrabackup提取了inoodb的事情日志中付出业务,对于到binary
log的岗位。使用那个岗位能够运转叁个新的复制slave只怕复苏3个时光点备份。

 

一经备份是一个来至于binary
log运营的日记,xtrabackup会创制3个文件xtrabackup_binlog_info里面包含了,binary log文件名和岗位。消息也会写在xtrabackup_binlog_pos_innodb,那个文件只会在唯有xtradb可能innodb境况下才会准确。其他意况下相应采取xtrabackup_binlog_info。

 

时刻点过来,和innobackupex的同一可以查阅 3.1.7.6时日点恢复

 

至于怎么着回复3个slave能够查阅上边包车型地铁内容:4.3.1 多个步骤安装1个Slave

 

160321 10:56:00  version_check Connected to MySQL
server

-h, –datadir=name

3.2.8.5 还原单个表

在mariadb 10.0中得以平素通过ibd文件导入表。

 

导出表


先找找是或不是有那么些文件存在

$ find /data/backups/mysql/ -name export_test.*

/data/backups/mysql/test/export_test.ibd

下一场导出表

$ xtrabackup –prepare –export –target-dir=/data/backups/mysql/

会产生exp文件

$ find /data/backups/mysql/ -name export_test.*

/data/backups/mysql/test/export_test.exp

/data/backups/mysql/test/export_test.ibd

/data/backups/mysql/test/export_test.cfg

 

小心:mysql使用cfg文件,这一个文件包括了innodb字典dump。那几个格式和exp文件的两样,exp文件用于xtradb。严峻来说cfg在mysql 5.6和percona
5.6从此是能够绝不的,假设存在cfg文件,那么innodb会通过cfg文件做schema验证 。

 

 

导入表


导入表,在percona server使用xtradb,供给安装innodb_import_table_from_xtrabackup设置为可用,mysql5.6万一表结构同样都足以导入。

1.执行alter table discard
tablespace

2.复制上一步生成的文件到对于的数据库目录

3.执行alter table import
tablespace导入

 

160321 10:56:00  version_check Executing a version
check against the
server

MySQL数据库的数据文件目录

3.2.8.6 LRU dump备份

这一个效能减弱了服务warm
up的日子,在重启的时候一贯导入ib_lru_dump文件中的数据,在备份的时候会自行备份。

澳门威尼斯人网址 3

如果my.cnf配置了,percona
server启动了innodb_buffer_pool_resotre_at_startup=1那么那几个意义会活动运营。

其一职能在mariadb中有接近的作用:XtraDB/InnoDB Server System Variables

 

160321 10:56:00  version_check
Done.

示范1:完全备份与回复(InnoDB)

3.2.8.7 xtrabackup的限制

1.在3四位的种类下一旦xtrabackup_logfile大于4gb那么–prepare会报错

2.在第四回进行–prepare的时候不会生成ib_logfile*

3.xtrabackup只复制数据文件和日志,不会复制表定义,frm文件。

4.xtrabackup不援助–set-variable那种格式设置my.cnf

 

160321 10:56:00 Connecting to MySQL server host:
localhost, user: mysqlha, password: set, port: 5711, socket:
/tmp/mysql5711.sock

(1)备份

3.2.8.8 References

具体看:The xtrabackup Option Reference

Using server version 5.7.11-log

本子内容:

3.2.9 xbstream

具体看: xbstream

/usr/local/xtrabackup/bin/innobackupex
version 2.4.1 based on MySQL
server 5.7.10 Linux (x86_64)
(revision id: a2dc9d4)

[[email protected]
xtrabak]# more xtra_backup.sh
# 2014-04-29
mkdir -p /data/xtrabak/bak_`date +%F`/
echo “backup begin” `date`
xtrabackup –defaults-file=/etc/my.cnf –backup
–target-dir=/data/xtrabak/bak_`date +%F`/
cp -r /var/lib/mysql/test /data/xtrabak/bak_`date +%F`/

3.2.10 xbcrypt

具体看:xbcrypt

xtrabackup: uses posix_fadvise().

注意:xtrabackup只备份数据文件,并不备份数据表结构文件(.frm),所以还需手动拷贝一下,以便xtrabackup恢复生机时采纳

3.2.11 Xtrabackup原理

xtrabackup是根据innodb的crash复苏效率。复制innodb数据文件,不过数量是不平等的,然后利用crash恢复生机让数据文件一贯。

当innodb运营会去检查数据文件和日志文件,然后重做已交由业务,执行未提交业务。

 

xtrabackup记下LSN,然后运转,复制数据文件。同时xtrabackup运营二个后台进度用来监督日志文件,然后复制修改,那么些过程在备份时期平素是运营的,因为日志文件时回绕的,防止数据被遮住不可能恢复生机。直到备份完结。

 

其次阶段就是准备阶段,xtrabackup通过进行crash复苏,应用日志文件到数据文件上。那一个进度在xtrabackup中贯彻。innobackupex增添了效果,会对myisam和.frm实行理并答复制。innobackupex运行xtrabackup,等待复制innodb停止,然后实施FLUSH TABLES
WITH READ LOCK,甘休对mysql数据的修改。复制非innodb引擎表,知道复制成功,然后释放锁。

 

诸如此类在prepare阶段后,innodb和非innodb相互保持了一致性。innodb会平素redo,直到备份实现。那么些日子刚好好和FLUSH TABLES WITH READ LOCK时间一向,所以innodb和非innodb是保持同步的。

 

xtrabackup: cd to /data1/mysql5711

实践备份脚本:

4 如何采纳和案例(How-tos and Recipes)

xtrabackup: open files limit requested 0, set to 204800

[[email protected]
xtrabak]# sh xtra_backup.sh
backup begin Tue Apr 29 15:22:09 CST 2014
xtrabackup version 2.0.5 for Percona Server 5.1.59 unknown-linux-gnu
(x86_64) (revision id: 499)
xtrabackup: uses posix_fadvise().
xtrabackup: cd to /var/lib/mysql/
xtrabackup: Target instance is assumed as followings.
xtrabackup: innodb_data_home_dir = /var/lib/mysql
xtrabackup: innodb_data_file_path = ibdata1:10M:autoextend
xtrabackup: innodb_log_group_home_dir = /var/lib/mysql
xtrabackup: innodb_log_files_in_group = 2
xtrabackup: innodb_log_file_size = 5242880
>> log scanned up to (1830807)
[01] Copying /var/lib/mysql/ibdata1 to
/data/xtrabak/bak_2014-04-29/ibdata1
[01] …done
xtrabackup: The latest check point (for incremental): ‘1830807’
xtrabackup: Stopping log copying thread.
.>> log scanned up to (1830807)

4.1 innobackupex案例

xtrabackup: using the following InnoDB
configuration:

xtrabackup: Transaction log of lsn (1830807) to (1830807) was copied.

4.1.1 本地全备(备份,预备,还原)

始建备份


$ innobackupex /data/backups

备份达成

100313 02:43:07  innobackupex: completed OK!

 

预备备份


行使–apply-log来准备,使用–user-memory来加快预备速度

$ innobackupex –use-memory=4G –apply-log
/data/backups/2010-03-13_02-42-44/

完成

100313 02:51:02  innobackupex: completed OK!

 

卷土重来备份


应用–copy-back来回复备份

innobackupex –copy-back /data/backups/2010-03-13_02-42-44/

## Use chmod to correct the permissions, if necessary!

 

复原的座席由my.cnf中的datadir决定。

瞩目修改文件全数者

$ chown -R mysql:mysql /var/lib/mysql

 

xtrabackup:   innodb_data_home_dir = .

从出口能够见到,备份进程首先记录LSN,然后拷贝数据文件(注意,并从未备份表结构文件.frm),最后拷贝并记录LSN。备份实现后,在钦赐指标目录除了拷贝过来的数据文件ibdata1及表结构文件夹test外,还生成了其它三个公文,分别记录日志及检查点,如下:

4.1.2 使用Stream备份

tar使用例子


是用留备份归档到文件 ‘backup.tar’

$ innobackupex –stream=tar ./ > backup.tar

调整和收缩归档文件

$ innobackupex –stream=tar ./ | gzip – > backup.tar.gz

加密备份

$ innobackupex –stream=tar . | gzip – | openssl des3 -salt -k
“password” > backup.tar.gz.des3

把备份复制到远程

$ innobackupex –stream=tar ./ | ssh
[email protected]
“cat – > /data/backups/backup.tar”

应用netcat复制到长途

## On the destination host:

$ nc -l 9999 | cat – > /data/backups/backup.tar

## On the source host:

$ innobackupex –stream=tar ./ | nc desthost 9999

和方面一样只是一律落成

$ ssh
[email protected]
“( nc -l 9999 > /data/backups/backup.tar & )” \

&& innobackupex –stream=tar ./  |  nc desthost 9999

范围传输速度为10MB/s 需求pv工具。能够由此apt-get
安装

$ innobackupex –stream=tar ./ | pv -q -L10m \

| ssh
[email protected]
“cat – > /data/backups/backup.tar”

在备份的时候总括checksum

## On the destination host:

$ nc -l 9999 | tee >(sha1sum > destination_checksum) >
/data/backups/backup.tar

## On the source host:

$ innobackupex –stream=tar ./ | tee >(sha1sum > source_checksum)
| nc desthost 9999

## compare the checksums

## On the source host:

$ cat source_checksum

65e4f916a49c1f216e0887ce54cf59bf3934dbad  –

## On the destination host:

$ destination_checksum

65e4f916a49c1f216e0887ce54cf59bf3934dbad  –

 

xbstream**选择例子**


备份并归档为‘backup.xbstream

innobackupex –stream=xbstream ./ > backup.xbstream

动用压缩归档

innobackupex –stream=xbstream –compress ./ > backup.xbstream

解包

xbstream -x <  backup.xbstream

把备份发送到其余目录

innobackupex –compress –stream=xbstream ./ | ssh
[email protected]
“xbstream -x”

并发压缩归档

innobackupex --compress --compress-threads=8 --stream=xbstream --parallel=4 ./ > backup.xbstream

xtrabackup:   innodb_data_file_path = ibdata1:100M:autoextend

[[email protected]
xtrabak]# cd bak_2014-04-29/
[[email protected]
bak_2014-04-29]# ls
ibdata1 test xtrabackup_checkpoints xtrabackup_logfile

4.1.3 成立增量备份

开创备份


先创建多少个全备:

innobackupex --user=USER --password=PASSWORD /path/to/backup/dir/

全备会转变一个年华戳的子目录,备份在子目录里,如/path/to/backup/dir/二〇一二-12-24_23-01-00/,并记为$FULLBACK

开创增量备份

innobackupex --incremental /path/to/inc/dir \

  --incremental-basedir=$FULLBACKUP --user=USER --password=PASSWORD

变迁的目录为:/path/to/inc/dir/2012-12-25_00-01-00/并记为$INCREMENTALBACKUP

 

预备备份


innobackupex –apply-log –redo-only $FULLBACKUP \

 –use-memory=1G –user=USER –password=PASSWORD

–user-memory能够加速预备速度。

输出:

111225 01:10:12 InnoDB: Shutdown completed; log sequence number 91514213

然后接纳增量

innobackupex –apply-log –redo-only $FULLBACKUP

 –incremental-dir=$INCREMENTALBACKUP

 –use-memory=1G –user=DVADER –password=D4RKS1D3

因为是行使到 $FULLBACK下的,所以不再增量备份文件夹下。

 

假设苏醒多少个增量备份,但是忘记了备份顺序能够查看xtrabackup_checkpoint文件

如:

backup_type = full-backuped

from_lsn =0

to_lsn =1291135

 

backup_type = incremental

from_lsn =1291135

to_lsn =1291340

假设都准备好现在,就能够回滚未提交业务,然后还原备份使用了

innobackupex-1.5.1 –apply-log $FULLBACKUP –use-memory=1G \

  –user=$USERNAME –password=$PASSWORD

 

xtrabackup:   innodb_log_group_home_dir = .

恢复

4.1.4 成立压缩备份

备份


带–compress创设压缩备份

$ innobackupex –compress /data/backup

假设想要加急速度,可以动用–compress-threads加快

$ innobackupex –compress –compress-threads=4 /data/backup

输出:

[01] Compressing ./imdb/comp_cast_type.ibd to
/data/backup/2013-08-01_11-24-04/./imdb/comp_cast_type.ibd.qp

[01]        …done

[01] Compressing ./imdb/aka_name.ibd to
/data/backup/2013-08-01_11-24-04/./imdb/aka_name.ibd.qp

[01]        …done

130801 11:50:24  innobackupex: completed OK

 

预备


在备选在此之前先要使用qpress解压

$ for bf in `find . -iname “*\.qp”`; do qpress -d $bf $(dirname $bf)
&& rm $bf; done

在xtrabackup2.1.4过后也足以接纳–decompress解压

$ innobackupex –decompress /data/backup/2013-08-01_11-24-04/

以此选项加压文件原来的公文子禽被轮换为解压后的公文。

在意:使用–decompress需求设置qpress,并且–parallel能够和–decompress一起利用,加快解压缩。

 

接下来利用–apply-log预备

$ innobackupex –apply-log /data/backup/2013-08-01_11-24-04/

 

还原


使用–copy-back还原数据库

$ innobackupex –copy-back /data/backups/2013-08-01_11-24-04/

–copy-back读取复制到my.cnf中的datadir的值

 

未来修改文件的全体者

$ chown -R mysql:mysql /var/lib/mysql

而后再起步服务

xtrabackup:   innodb_log_files_in_group = 3

删去库test,然后经过备份文件执行复苏,如下:

4.1.5 备份还原独立分区

xtrabackup能够部分备份,这么些也让独立区的备份还原变成大概,只要开动innodb_file_per_table。

先成立贰个分区表

create table t.tb_part (id int ,v int) partition by hash(id) partitions
4;

然后插入数据

insert t.tb_part values(1,1),(2,1),(3,1),(4,1);

这么保证各个分区都有1条记下。

xtrabackup:   innodb_log_file_size = 1363148800

本子内容:

4.1.5.1 成立备份

使用innobackupex
–include进行备份,还有好多别的措施开始展览一些备份:

innobackupex –user=root  –include=’^t[.]tb_part’
/home/tiansign/mysql_backup

 

xtrabackup: using O_DIRECT

[[email protected]
xtrabak]# more xtra_prepare.sh
xtrabackup –defaults-file=/etc/my.cnf –prepare
–target-dir=/data/xtrabak/bak_`date +%F`/
cp -r /data/xtrabak/bak_`date +%F`/test/ /var/lib/mysql/
rm /var/lib/mysql/ib*
cp /data/xtrabak/bak_`date +%F`/ib* /var/lib/mysql/
chown -R mysql:mysql /var/lib/mysql
service mysql restart

4.1.5.2 预备备份

和独立表还原类似,使用–export进行准备

innobackupex –apply-log –export
/home/tiansign/mysql_backup/2014-08-19_23-25-55/

ls

tb_part.frm       tb_part#P#p0.ibd  tb_part#P#p2.cfg 
tb_part#P#p3.exp

tb_part.par       tb_part#P#p1.cfg  tb_part#P#p2.exp 
tb_part#P#p3.ibd

tb_part#P#p0.cfg  tb_part#P#p1.exp  tb_part#P#p2.ibd

tb_part#P#p0.exp  tb_part#P#p1.ibd  tb_part#P#p3.cfg

有像样如下输出

xtrabackup: export option is specified.

xtrabackup: export metadata of table ‘t/tb_part#P#p0’ to file
`./t/tb_part#P#p0.exp` (1 indexes)

xtrabackup:     name=GEN_CLUST_INDEX, id.low=58, page=3

xtrabackup: export metadata of table ‘t/tb_part#P#p2’ to file
`./t/tb_part#P#p2.exp` (1 indexes)

xtrabackup:     name=GEN_CLUST_INDEX, id.low=60, page=3

xtrabackup: export metadata of table ‘t/tb_part#P#p3’ to file
`./t/tb_part#P#p3.exp` (1 indexes)

xtrabackup:     name=GEN_CLUST_INDEX, id.low=61, page=3

xtrabackup: export metadata of table ‘t/tb_part#P#p1’ to file
`./t/tb_part#P#p1.exp` (1 indexes)

xtrabackup:     name=GEN_CLUST_INDEX, id.low=59, page=3

InnoDB: Number
of pools: 1

证实:脚本中步骤依次为:

4.1.5.3 从备份还原

那里关键介绍maridb 10.0的法子,也适用于mysql5.6

率先创立表结构:

create table test.tb_part (id int ,v int) partition by hash(id)
partitions 4;

create table test.p3 (id int ,v int) ;

然后discard

alter table test.p3 discard tablespace;

复制cfg和ibd到数据库目录下(在mariadb
10.0事后方可不用cfg文件,直接行使ibd文件)

cp tb_part#P#p3.ibd /home/db/test/p3.ibd

下一场修改全体者

chown mysql:mysql /home/db/test/p3.ibd

最后 import 表

alter table test.p3 import tablespace;

末段通过exchange
partition情势把表数据沟通到分区表中

alter table test.tb_part exchange partition p3 with table test.p3;

验证

select *from test.tb_part;

 

160321 10:56:01 >> log scanned up to (4151116)

履行对备份文件进行复原前的预备;

4.2 xtrabackup案例

具体看:Recipes for xtrabackup

 

xtrabackup: Generating a list of
tablespaces

从备份文件拷贝数据表结构到私下认可的多寡目录;

4.3 其余案例

InnoDB: Allocated tablespace ID 30 for
slow_query_log/global_query_review_history, old maximum was
0

除去私下认可数据目录中对应的数据文件并复制备份的数据文件到暗中认可数据目录;

4.3.1 三个步骤安装3个slave

亟待的东西


1.TheMaster服务器

       a.需求设置mysql并且能公国tcp/ip访问

       b.配置了SSH服务

       c.有个类别账号,并有一些权力

       d.有个数据库账号,也有相应的权位

       e.服务的binlog启动,并且server-id为1

2.TheSlave,另二个体系设置了mysql,其余都和TheMaster一样,不过server-id要为2

3.贰个系统都要设置xtrabackup

 

步骤1:成立二个备份并预备


TheMaster$ innobackupex –user=yourDBuser –password=MaGiCdB1
/path/to/backupdir

做到之后准备

TheMaster$ innobackupex –user=yourDBuser –password=MaGiCdB1 /

           –apply-log /path/to/backupdir/$TIMESTAMP/

如果您有一定的配备文件,那么通过–defaults-file=XXXX/my.cnf内定。暗中认可使用备份目录下的backup-my.cnf。

 

手续2:把备份复制到TheSlave


行使rsync来共同备份文件

TheMaster$ rsync -avprP -e ssh /path/to/backupdir/$TIMESTAMP
TheSlave:/path/to/mysql/

闭馆,mysql服务,并保留原先的数据库

TheSlave$ mv /path/to/mysql/datadir /path/to/mysql/datadir_bak

接下来把备份复制到mysql配置的datadir下

TheSlave$ mv /path/to/mysql/$TIMESTAMP /path/to/mysql/datadir

修改文件全部者

TheSlave$ chown mysql:mysql /path/to/mysql/datadir

 

步骤3:配置Master


布署slave,master连接账号

TheMaster|mysql>GRANT REPLICATION SLAVE ON*.* 
TO‘repl’@’$slaveip’

 IDENTIFIED BY‘$slavepass’;

管教TheSlave能够因而那么些账号连接到TheMaster

TheSlave$ mysql –host=TheMaster –user=repl –password=$slavepass

注解权限

mysql> SHOW GRANTS;

 

步骤4:配置Slave


先复制master 上的布置文件

TheSlave$ scp
[email protected]:/etc/mysql/my.cnf
/etc/mysql/my.cnf

下一场修改server-id=2

server-id=2

伊始slave上的劳务

 

步骤5:运行复制


先查看xtrabackup_binlog_info来确定binary log的位置

TheSlave$ cat /var/lib/mysql/xtrabackup_binlog_info

TheMaster-bin.000001     481

利用CHANGE MASTE宝马7系,账号密码使用刚才在master中申请的账号。

TheSlave|mysql>CHANGE MASTER TO

                MASTER_HOST=’$masterip’,

                MASTER_USER=’repl’,

                MASTER_PASSWORD=’$slavepass’,

                MASTER_LOG_FILE=’TheMaster-bin.000001′,

                MASTER_LOG_POS=481;

下一场运行slave

TheSlave|mysql> START SLAVE;

 

步骤6:检查


TheSlave|mysql> SHOW SLAVE STATUS \G

         …

         Slave_IO_Running: Yes

         Slave_SQL_Running: Yes

         …

         Seconds_Behind_Master: 13

         …

io和SQL都要运行,Seconds_behind_master是明日slave执行的言语在master上是13秒以前的数量。那么些是master和slave之间的推移。

160321 10:56:01 [01]
Copying ./ibdata1 to /data1/dbatemp/5711back/ibdata1

修改私下认可数据目录权限同等看待启MySQL服务

4.3.2 再追加八个slave

进程基本上和下面类似

1.备份slave,要带上–slave-info,带上那么些选项会产生2个xtrabackup_slave_info个中的master的binary
log和任务都记录在那一个文件上

TheSlave$ innobackupex –user=yourDBuser –password=MaGiCiGaM /

          –slave-info /path/to/backupdir

2.准备,扩大了use-memory来加快预备速度

TheSlave$ innobackupex –apply-log –use-memory=2G
/path/to/backupdir/$TIMESTAMP/

3.复制到是slave

rsync -avprP -e ssh /path/to/backupdir/$TIMESTAMP
TheNewSlave:/path/to/mysql/datadir

4.在master上,再次创下制多少个账号,当然也足以选取同四个账号,只要能三番五次上就能够

heMaster|mysql>GRANT REPLICATION SLAVE ON*.* 
TO‘repl’@’$newslaveip’

             IDENTIFIED BY‘$slavepass’;

5.复制配置文件,在开行的时候不运行复制,并安装server-id为3

TheNEWSlave$ scp
[email protected]:/etc/mysql/my.cnf
/etc/mysql/my.cnf

修改配置文件

Skip-slave-start

server-id=3

启动slave的服务

6.通过xtrabackup_slave_info获取master的日志名和职位

TheNEWSlave|mysql>CHANGE MASTER TO

                   MASTER_HOST=’$masterip’,

                   MASTER_USER=’repl’,

                   MASTER_PASSWORD=’$slavepass’,

                   MASTER_LOG_FILE=’TheMaster-bin.000001′,

                   MASTER_LOG_POS=481;

启动slave

TheSlave|mysql> START SLAVE;

160321 10:56:02 >> log scanned up to (4151116)

执行苏醒脚本:

4.3.3 使用复制和pt-checksum验证备份

具体看:Verifying Backups with replication and
pt-checksum

160321 10:56:02 [01] 
     
…done

[[email protected]
xtrabak]# sh xtra_prepare.sh
xtrabackup version 2.0.5 for Percona Server 5.1.59 unknown-linux-gnu
(x86_64) (revision id: 499)
xtrabackup: cd to /data/xtrabak/bak_2014-04-29/
xtrabackup: This target seems to be not prepared yet.
xtrabackup: xtrabackup_logfile detected: size=2097152,
start_lsn=(1830807)
xtrabackup: Temporary instance for recovery is set as followings.
xtrabackup: innodb_data_home_dir = ./
xtrabackup: innodb_data_file_path = ibdata1:10M:autoextend
xtrabackup: innodb_log_group_home_dir = ./
xtrabackup: innodb_log_files_in_group = 1
xtrabackup: innodb_log_file_size = 2097152
xtrabackup: Temporary instance for recovery is set as followings.
xtrabackup: innodb_data_home_dir = ./
xtrabackup: innodb_data_file_path = ibdata1:10M:autoextend
xtrabackup: innodb_log_group_home_dir = ./
xtrabackup: innodb_log_files_in_group = 1
xtrabackup: innodb_log_file_size = 2097152
xtrabackup: Starting InnoDB instance for recovery.
xtrabackup: Using 104857600 bytes for buffer pool (set by –use-memory
parameter)
InnoDB: The InnoDB memory heap is disabled
InnoDB: Mutexes and rw_locks use GCC atomic builtins
InnoDB: Compressed tables use zlib 1.2.3
140429 15:28:34 InnoDB: Initializing buffer pool, size = 100.0M
140429 15:28:34 InnoDB: Completed initialization of buffer pool
140429 15:28:34 InnoDB: highest supported file format is Barracuda.
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
140429 15:28:34 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files…
InnoDB: Last MySQL binlog file position 0 85912, file name
./mysql-bin.000026
140429 15:28:34 Percona XtraDB (http://www.percona.com) 1.0.17-12.5
started; log sequence number 1830807

4.3.4 如何创制基于GTID的Slave

具体看:How to create a new (or repair a broken) GTID
based slave

 

160321 10:56:02 [01]
Copying ./slow_query_log/global_query_review_history.ibd to
/data1/dbatemp/5711back/slow_query_log/global_query_review_history.ibd

[notice (again)]
If you use binary log and don’t use any hack of group commit,
the binary log position seems to be:
InnoDB: Last MySQL binlog file position 0 85912, file name
./mysql-bin.000026

4.4协理理工科程师具手册

具体看:Auxiliary Guides

160321 10:56:02 [01] 
     
…done

xtrabackup: starting shutdown with innodb_fast_shutdown = 1
140429 15:28:34 InnoDB: Starting shutdown…
140429 15:28:34 InnoDB: Shutdown completed; log sequence number
1832037
Shutting down MySQL…. [ OK ]
Starting MySQL. [ OK ]

参考

Xtrabackup安装及运用

Percona Xtrabackup – Documentation

xtrabackup原理及执行

 

160321 10:56:02 [01]
Copying ./slow_query_log/global_query_review.ibd to
/data1/dbatemp/5711back/slow_query_log/global_query_review.ibd

推行到位后,检查发现test库已成功恢复生机。

160321 10:56:02 [01] 
     
…done

示例2:增量备份与还原

http://www.bkjia.com/Mysql/866432.htmlwww.bkjia.comtruehttp://www.bkjia.com/Mysql/866432.htmlTechArticlePercona XtraBackup User 马努al
阅读笔记,perconaxtrabackup XtraBackup XtraBackup .. 1 2 安装XtraBackup
.. 1 2.1 安装XtraBackup binary 版本 … 1 2.1.1 yum
的装置情势:…

160321 10:56:02 [01]
Copying ./abc/object_info.ibd to /data1/dbatemp/5711back/abc/object_info.ibd

增量备份是以完全备份或上叁遍增量备份为底蕴的备份,适合数据库相当的大的意况,协理在线热备,备份期间不锁定表,不影响用户采用,备份复苏效用都比较高。

160321 10:56:02 [01] 
     
…done

下边大家来模拟一次增量备份:

160321 10:56:02 [01]
Copying ./mysql/time_zone_transition.ibd to /data1/dbatemp/5711back/mysql/time_zone_transition.ibd

(1) 完全备份

160321 10:56:02 [01] 
     
…done

现行反革命test库有三张表,执行一次完全备份

160321 10:56:02 [01]
Copying ./mysql/time_zone_name.ibd to /data1/dbatemp/5711back/mysql/time_zone_name.ibd

--脚本内容:

160321 10:56:02 [01] 
     
…done

[[email protected]
xtrabak]# more xtra_full_bak.sh
# 2014-04-29
mkdir -p /data/xtrabak/full_bak_`date +%F`/
xtrabackup –defaults-file=/etc/my.cnf –backup
–target-dir=/data/xtrabak/full_bak_`date +%F`/
cp -r /var/lib/mysql/test/ /data/xtrabak/full_bak_`date +%F`/

160321 10:56:02 [01]
Copying ./mysql/slave_worker_info.ibd to /data1/dbatemp/5711back/mysql/slave_worker_info.ibd

--执行脚本

160321 10:56:02 [01] 
     
…done

[[email protected]
xtrabak]# sh xtra_full_bak.sh
xtrabackup version 2.0.5 for Percona Server 5.1.59 unknown-linux-gnu
(x86_64) (revision id: 499)
xtrabackup: uses posix_fadvise().
xtrabackup: cd to /var/lib/mysql
xtrabackup: Target instance is assumed as followings.
xtrabackup: innodb_data_home_dir = /var/lib/mysql
xtrabackup: innodb_data_file_path = ibdata1:10M:autoextend
xtrabackup: innodb_log_group_home_dir = /var/lib/mysql
xtrabackup: innodb_log_files_in_group = 3
xtrabackup: innodb_log_file_size = 67108864
>> log scanned up to (1653514)
[01] Copying /var/lib/mysql/ibdata1 to
/data/xtrabak/full_bak_2014-04-29/ibdata1
[01] …done
xtrabackup: The latest check point (for incremental): ‘1653514’
xtrabackup: Stopping log copying thread.
.>> log scanned up to (1653514)

160321 10:56:03 >> log scanned up to (4151116)

xtrabackup: Transaction log of lsn (1653514) to (1653514) was copied.

160321 10:56:03 Executing FLUSH
NO_WRITE_TO_BINLOG
TABLES

推行到位后,查看备份文件

160321 10:56:03 Executing FLUSH TABLES WITH
READ
LOCK

[[email protected]
xtrabak]# cd full_bak_2014-04-29/
[[email protected]
full_bak_2014-04-29]# ls
ibdata1 test xtrabackup_checkpoints xtrabackup_logfile

160321 10:56:03 Starting to backup
non-InnoDB tables and
files

(2) 增量备份

160321 10:56:03 [01]
Copying ./slow_query_log/db.opt to /data1/dbatemp/5711back/slow_query_log/db.opt

向test库中添加一张新表,然后实施增量备份

160321 10:56:03 [01] 
     
…done

--脚本内容:

160321 10:56:03 [01]
Copying ./slow_query_log/global_query_review_history.frm to
/data1/dbatemp/5711back/slow_query_log/global_query_review_history.frm

[[email protected]
xtrabak]# more xtra_delta_bak.sh
# 2014-04-29
mkdir -p /data/xtrabak/delta_bak_`date +%F`/
xtrabackup –defaults-file=/etc/my.cnf –backup
–target-dir=/data/xtrabak/delta_bak_`date +%F`/
–incremental-basedir=/data/xtrabak/full_bak_`date +%F`/
cp -r /var/lib/mysql/test/ /data/xtrabak/full_bak_`date +%F`/

160321 10:56:03 [01] 
     
…done

表明:那里供给重新拷贝test库的表结构文件,因为中间可能会大增或删除表

160321 10:56:04 [01]
Copying ./mysql/proc.MYI to /data1/dbatemp/5711back/mysql/proc.MYI

--执行脚本

160321 10:56:04 [01] 
     
…done

[[email protected]
xtrabak]# sh xtra_delta_bak.sh
xtrabackup version 2.0.5 for Percona Server 5.1.59 unknown-linux-gnu
(x86_64) (revision id: 499)
incremental backup from 1653514 is enabled.
xtrabackup: uses posix_fadvise().
xtrabackup: cd to /var/lib/mysql
xtrabackup: Target instance is assumed as followings.
xtrabackup: innodb_data_home_dir = /var/lib/mysql
xtrabackup: innodb_data_file_path = ibdata1:10M:autoextend
xtrabackup: innodb_log_group_home_dir = /var/lib/mysql
xtrabackup: innodb_log_files_in_group = 3
xtrabackup: innodb_log_file_size = 67108864
>> log scanned up to (1660436)
[01] Copying /var/lib/mysql/ibdata1 to
/data/xtrabak/delta_bak_2014-04-29/ibdata1.delta
[01] …done
xtrabackup: The latest check point (for incremental): ‘1660436’
xtrabackup: Stopping log copying thread.
.>> log scanned up to (1660436)

160321 10:56:04 >> log scanned up to (4151116)

xtrabackup: Transaction log of lsn (1660436) to (1660436) was copied.

160321 10:56:04 [01]
Copying ./mysql/time_zone_transition_type.frm to
/data1/dbatemp/5711back/mysql/time_zone_transition_type.frm

举行到位后,查看备份文件

160321 10:56:04 [01] 
     
…done

[[email protected]
xtrabak]# cd delta_bak_2014-04-29/
[[email protected]
delta_bak_2014-04-29]# ls
ibdata1.delta ibdata1.meta xtrabackup_checkpoints xtrabackup_logfile

160321 10:56:04 [01]
Copying ./mysql/func.MYD to /data1/dbatemp/5711back/mysql/func.MYD

小心:在增量备份目录下,数据文件是以.delta结尾的,增量备份只备份上2遍完全备份后被改动过的page;当然,若再一次实施增量备份,能够上一遍完全备份为根基,也能够率先次增量备份为根基,每一趟增量备份的目录都是内需修改的。

160321 10:56:06 [01] 
     
…done

(3) 恢复

160321 10:56:06 >> log scanned up to (4151116)

除去test库,模拟故障,然后通过一点一滴备份及增量备份文件执行复苏。

160321 10:56:06 [01]
Copying ./sys/schema_auto_increment_columns.frm to
/data1/dbatemp/5711back/sys/schema_auto_increment_columns.frm

--脚本内容:

160321 10:56:07 [01] 
     
…done

[[email protected]
xtrabak]# more xtra_delta_prepare.sh
xtrabackup –defaults-file=/etc/my.cnf –prepare
–target-dir=/data/xtrabak/full_bak_`date +%F`/
xtrabackup –defaults-file=/etc/my.cnf –prepare
–target-dir=/data/xtrabak/full_bak_`date +%F`/
–incremental-dir=/data/xtrabak/delta_bak_`date +%F`/
cp -r /data/xtrabak/full_bak_`date +%F`/test/ /var/lib/mysql/
rm /var/lib/mysql/ib*
cp /data/xtrabak/full_bak_`date +%F`/ib* /var/lib/mysql/
chown -R mysql:mysql /var/lib/mysql
service mysql restart

160321 10:56:07 >> log scanned up to (4151116)

--执行脚本

160321 10:56:07 [01]
Copying ./sys/sys_config_update_set_user.TRN to
/data1/dbatemp/5711back/sys/sys_config_update_set_user.TRN

[[email protected]
xtrabak]# sh xtra_delta_prepare.sh
xtrabackup version 2.0.5 for Percona Server 5.1.59 unknown-linux-gnu
(x86_64) (revision id: 499)
xtrabackup: cd to /data/xtrabak/full_bak_2014-04-29/
xtrabackup: This target seems to be not prepared yet.
xtrabackup: xtrabackup_logfile detected: size=2097152,
start_lsn=(1653514)
xtrabackup: Temporary instance for recovery is set as followings.
xtrabackup: innodb_data_home_dir = ./
xtrabackup: innodb_data_file_path = ibdata1:10M:autoextend
xtrabackup: innodb_log_group_home_dir = ./
xtrabackup: innodb_log_files_in_group = 1
xtrabackup: innodb_log_file_size = 2097152
xtrabackup: Temporary instance for recovery is set as followings.
xtrabackup: innodb_data_home_dir = ./
xtrabackup: innodb_data_file_path = ibdata1:10M:autoextend
xtrabackup: innodb_log_group_home_dir = ./
xtrabackup: innodb_log_files_in_group = 1
xtrabackup: innodb_log_file_size = 2097152
xtrabackup: Starting InnoDB instance for recovery.
xtrabackup: Using 104857600 bytes for buffer pool (set by –use-memory
parameter)
InnoDB: The InnoDB memory heap is disabled
InnoDB: Mutexes and rw_locks use GCC atomic builtins
InnoDB: Compressed tables use zlib 1.2.3
140429 18:28:21 InnoDB: Initializing buffer pool, size = 100.0M
140429 18:28:21 InnoDB: Completed initialization of buffer pool
140429 18:28:21 InnoDB: highest supported file format is Barracuda.
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
140429 18:28:21 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files…
InnoDB: Last MySQL binlog file position 0 2596, file name
./mysql-bin.000043
140429 18:28:22 Percona XtraDB (http://www.percona.com) 1.0.17-12.5
started; log sequence number 1653514

160321 10:56:07 [01] 
     
…done

[notice (again)]
If you use binary log and don’t use any hack of group commit,
the binary log position seems to be:
InnoDB: Last MySQL binlog file position 0 2596, file name
./mysql-bin.000043

160321 10:56:07 Finished backing up non-InnoDB
tables and
files

xtrabackup: starting shutdown with innodb_fast_shutdown = 1
140429 18:28:22 InnoDB: Starting shutdown…
140429 18:28:22 InnoDB: Shutdown completed; log sequence number
1653514
xtrabackup version 2.0.5 for Percona Server 5.1.59 unknown-linux-gnu
(x86_64) (revision id: 499)
incremental backup from 1653514 is enabled.
xtrabackup: cd to /data/xtrabak/full_bak_2014-04-29/
xtrabackup: This target seems to be already prepared.
xtrabackup: xtrabackup_logfile detected: size=2097152,
start_lsn=(1660436)
xtrabackup: Temporary instance for recovery is set as followings.
xtrabackup: innodb_data_home_dir = ./
xtrabackup: innodb_data_file_path = ibdata1:10M:autoextend
xtrabackup: innodb_log_group_home_dir =
/data/xtrabak/delta_bak_2014-04-29/
xtrabackup: innodb_log_files_in_group = 1
xtrabackup: innodb_log_file_size = 2097152
xtrabackup: page size for
/data/xtrabak/delta_bak_2014-04-29//ibdata1.delta is 16384 bytes
Applying /data/xtrabak/delta_bak_2014-04-29//ibdata1.delta to
././ibdata1…
xtrabackup: Temporary instance for recovery is set as followings.
xtrabackup: innodb_data_home_dir = ./
xtrabackup: innodb_data_file_path = ibdata1:10M:autoextend
xtrabackup: innodb_log_group_home_dir =
/data/xtrabak/delta_bak_2014-04-29/
xtrabackup: innodb_log_files_in_group = 1
xtrabackup: innodb_log_file_size = 2097152
xtrabackup: Starting InnoDB instance for recovery.
xtrabackup: Using 104857600 bytes for buffer pool (set by –use-memory
parameter)
InnoDB: The InnoDB memory heap is disabled
InnoDB: Mutexes and rw_locks use GCC atomic builtins
InnoDB: Compressed tables use zlib 1.2.3
140429 18:28:22 InnoDB: Initializing buffer pool, size = 100.0M
140429 18:28:22 InnoDB: Completed initialization of buffer pool
140429 18:28:22 InnoDB: highest supported file format is Barracuda.
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
140429 18:28:22 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files…
InnoDB: Last MySQL binlog file position 0 2703, file name
./mysql-bin.000045
140429 18:28:22 Percona XtraDB (http://www.percona.com) 1.0.17-12.5
started; log sequence number 1660436

160321 10:56:07 [00]
Writing
xtrabackup_slave_info

[notice (again)]
If you use binary log and don’t use any hack of group commit,
the binary log position seems to be:
InnoDB: Last MySQL binlog file position 0 2703, file name
./mysql-bin.000045

160321 10:56:07 [00] 
     
…done

xtrabackup: starting shutdown with innodb_fast_shutdown = 1
140429 18:28:22 InnoDB: Starting shutdown…
140429 18:28:23 InnoDB: Shutdown completed; log sequence number
1660436
Shutting down MySQL… [ OK ]
Starting MySQL….. [ OK ]
推行成功后,检查发现test数据库已成功苏醒。

160321 10:56:07 [00]
Writing
xtrabackup_binlog_info

四、 Innobackupex使用

160321 10:56:07 [00] 
     
…done

前方提到,Innobackupex可同时备份InnoDB和MyISAM引擎表,所以一般都一贯利用innobackupex。须求专注的是my.cnf中必须抬高datadir那个参数,因为要根据它来恒定InnoDB引擎的数据文件地点。

160321 10:56:07 Executing FLUSH
NO_WRITE_TO_BINLOG ENGINE
LOGS

innobackupex也富含一体系参数,可透过innobackupex
–help命令查看,此处不逐一表达了。

xtrabackup: The latest check point (for
incremental): ‘4151107’

下边我们透过1个完完全全的演示来演示其用法,如下:

xtrabackup: Stopping log copying thread.

(1) 备份

.160321 10:56:07 >> log scanned up to (4151116)

--脚本内容:

 

[[email protected]
xtrabak]# more backup.sh
# 2014-04-29
mkdir -p /data/xtrabak/bak_`date +%F`/
echo “backup begin” `date`
log=innobackupex_`date +%F`.log
str=bak_`date +%F`
innobackupex –user=root –password=root123 –defaults-file=/etc/my.cnf
–stream=tar /data/xtrabak/$str/ 2>/data/xtrabak/$log |
gzip>/data/xtrabak/$str/base.tar.gz
echo “backup end” `date`
cp /etc/my.cnf /data/xtrabak/my_`date +%F`.cnf

160321 10:56:07 Executing UNLOCK
TABLES

--执行脚本:

160321 10:56:07 All tables
unlocked

[[email protected]
xtrabak]# sh backup.sh
backup begin Wed Apr 30 16:15:02 CST 2014
backup end Wed Apr 30 16:15:27 CST 2014

160321 10:56:07 [00]
Copying ib_buffer_pool to /data1/dbatemp/5711back/ib_buffer_pool

[[email protected]
xtrabak]# cd bak_2014-04-30/
[[email protected]
bak_2014-04-30]# ls
base.tar.gz

160321 10:56:07 [00] 
     
…done

实践到位后,生成备份文件的压缩包

160321 10:56:07 Backup created in directory
‘/data1/dbatemp/5711back’

(2) 增量日志备份

MySQL binlog position: filename ‘mysql-bin.000002’, position ‘154’

是因为数据库不停的对外提供劳务,备份之后的操作会记录到binlong日志文件中,所以大家还应备份后续的日志文件。

MySQL slave binlog position: master
host ‘10.75.22.67’, filename ‘mysql-bin.000007’, position ‘154

此地删除几张表,并切换日志以模拟真实环境,备份完整的binlog日志文件;然后倒闭数据库,删除数据库全部文件,以便模拟故障。

160321 10:56:07 [00] Writing backup-my.cnf

--脚本内容(binlog备份到长途机器):

160321 10:56:07 [00]        …done

[[email protected]
xtrabak]# more binlog_bak.sh
cd /var/lib/
DATE=`date -d ‘-1 hour’ +%Y%m%d%H00`
touch -t “${DATE}” starttemp
echo “$DATE”
umount /mnt_log>/dev/null 2>&1
mount -t nfs 192.168.3.108:/logcenter /mnt_log
find /var/lib/mysql/mysql-bin.* -newer starttemp|xargs -I {} cp -p {}
/mnt_log/mysql-binlog/192.168.3.28/
# umount -t nfs /mnt_log

160321 10:56:07 [00] Writing xtrabackup_info

(3) 恢复

160321 10:56:07 [00]        …done

--脚本内容:

xtrabackup: Transaction log of lsn (4151107) to
(4151116) was copied.

[[email protected]
xtrabak]# more prepare.sh
# 2014-04-30
service mysql stop
mkdir -p /data/xtrabak/prepare_`date +%F`/
tar -ixzvf /data/xtrabak/bak_`date +%F`/base.tar.gz -C
/data/xtrabak/prepare_`date +%F`/
innobackupex –apply-log –user=root –defaults-file=/etc/my.cnf
/data/xtrabak/prepare_`date +%F`/
innobackupex –copy-back –user=root –defaults-file=/etc/my.cnf
/data/xtrabak/prepare_`date +%F`/
chown -R mysql:mysql /var/lib/mysql/
rm -rf /var/lib/mysql/xtrabackup_binlog_pos_innodb
service mysql restart

160321 10:56:07 completed OK!

--完全备份恢复生机后,通过binlog进行增量恢复生机

prepare

[[email protected]
test]# mysqlbinlog start-position=******
/mnt_log/mysql-binlog/192.168.3.28/mysql-bin.000052 |mysql -uroot
-proot123

innobackupex –apply-log /data1/dbatemp/5711back

注意:start-position的职位可通过解压后的备份文件查看,如下:

“`

[[email protected]
xtrabak]# cd prepare_2014-04-30/

160321 11:04:16 innobackupex: Starting the apply-log
operation

[[email protected]
prepare_2014-04-30]# more xtrabackup_binlog_info
mysql-bin.000047 1472

IMPORTANT: Please check that the apply-log run
completes successfully.

或者

At the end of a successful apply-log run
innobackupex

[[email protected]
prepare_2014-04-30]# more xtrabackup_binlog_pos_innodb
./mysql-bin.000047 1472

prints “completed OK!”.

打响复苏后,MySQL即可符合规律使用。

/usr/local/xtrabackup/bin/innobackupex version 2.4.1
based on MySQL server 5.7.10 Linux (x86_64) (revision id:
a2dc9d4)

http://www.bkjia.com/Mysql/764302.htmlwww.bkjia.comtruehttp://www.bkjia.com/Mysql/764302.htmlTechArticle一、 简介
大家明白,针对InnoDB存款和储蓄引擎,MySQL本人并未提供适宜的热备工具,ibbackup虽是一款快捷的首选热备格局,但它是是收费的。辛亏…

xtrabackup: cd to /data1/dbatemp/5711back

xtrabackup: This target seems to be not prepared
yet.

InnoDB: Number of pools: 1

xtrabackup: xtrabackup_logfile detected: size=8388608,
start_lsn=(4151107)

xtrabackup: using the following InnoDB configuration
for recovery:

xtrabackup: innodb_data_home_dir = .

xtrabackup: innodb_data_file_path =
ibdata1:100M:autoextend

xtrabackup: innodb_log_group_home_dir = .

xtrabackup: innodb_log_files_in_group = 1

xtrabackup: innodb_log_file_size = 8388608

xtrabackup: using the following InnoDB configuration
for recovery:

xtrabackup: innodb_data_home_dir = .

xtrabackup: innodb_data_file_path =
ibdata1:100M:autoextend

xtrabackup: innodb_log_group_home_dir = .

xtrabackup: innodb_log_files_in_group = 1

xtrabackup: innodb_log_file_size = 8388608

xtrabackup: Starting InnoDB instance for
recovery.

xtrabackup: Using 104857600 bytes for buffer pool (set
by –use-memory parameter)

InnoDB: PUNCH HOLE support not available

InnoDB: Mutexes and rw_locks use GCC atomic
builtins

InnoDB: Uses event mutexes

InnoDB: GCC builtin __sync_synchronize() is used for
memory barrier

InnoDB: Compressed tables use zlib 1.2.3

InnoDB: Number of pools: 1

InnoDB: Using CPU crc32 instructions

InnoDB: Initializing buffer pool, total size = 100M,
instances = 1, chunk size = 100M

InnoDB: Completed initialization of buffer pool

InnoDB: page_cleaner coordinator priority: -20

InnoDB: Highest supported file format is
Barracuda.

InnoDB: Log scan progressed past the checkpoint lsn
4151107

InnoDB: Doing recovery: scanned up to log sequence
number 4151116 (0%)

InnoDB: Doing recovery: scanned up to log sequence
number 4151116 (0%)

InnoDB: Database was not shutdown normally!

InnoDB: Starting crash recovery.

InnoDB: xtrabackup: Last MySQL binlog file position
179018, file name mysql-bin.000001

InnoDB: Creating shared tablespace for temporary
tables

InnoDB: Setting file ‘./ibtmp1’ size to 12 MB.
Physically writing the file full; Please wait …

InnoDB: File ‘./ibtmp1’ size is now 12 MB.

InnoDB: 96 redo rollback segment(s) found. 1 redo
rollback segment(s) are active.

InnoDB: 32 non-redo rollback segment(s) are
active.

InnoDB: 5.7.10 started; log sequence number
4151116

InnoDB: not started

InnoDB: xtrabackup: Last MySQL binlog file position
179018, file name mysql-bin.000001

xtrabackup: starting shutdown with
innodb_fast_shutdown = 1

InnoDB: FTS optimize thread exiting.

InnoDB: Starting shutdown…

InnoDB: Shutdown completed; log sequence number
4151291

InnoDB: Number of pools: 1

xtrabackup: using the following InnoDB configuration
for recovery:

xtrabackup: innodb_data_home_dir = .

xtrabackup: innodb_data_file_path =
ibdata1:100M:autoextend

xtrabackup: innodb_log_group_home_dir = .

xtrabackup: innodb_log_files_in_group = 3

xtrabackup: innodb_log_file_size = 1363148800

InnoDB: PUNCH HOLE support not available

InnoDB: Mutexes and rw_locks use GCC atomic
builtins

InnoDB: Uses event mutexes

InnoDB: GCC builtin __sync_synchronize() is used for
memory barrier

InnoDB: Compressed tables use zlib 1.2.3

InnoDB: Number of pools: 1

InnoDB: Using CPU crc32 instructions

InnoDB: Initializing buffer pool, total size = 100M,
instances = 1, chunk size = 100M

InnoDB: Completed initialization of buffer pool

InnoDB: page_cleaner coordinator priority: -20

InnoDB: Setting log file ./ib_logfile101 size to 1300
MB

InnoDB: Progress in MB:

100 200 300 400 500 600 700 800 900 1000 1100 1200
1300

InnoDB: Setting log file ./ib_logfile1 size to 1300
MB

InnoDB: Progress in MB:

100 200 300 400 500 600 700 800 900 1000 1100 1200
1300

InnoDB: Setting log file ./ib_logfile2 size to 1300
MB

InnoDB: Progress in MB:

100 200 300 400 500 600 700 800 900 1000 1100 1200
1300

InnoDB: Renaming log file ./ib_logfile101 to
./ib_logfile0

InnoDB: New log files created, LSN=4151291

InnoDB: Highest supported file format is
Barracuda.

InnoDB: Log scan progressed past the checkpoint lsn
4151308

InnoDB: Doing recovery: scanned up to log sequence
number 4151317 (0%)

InnoDB: Doing recovery: scanned up to log sequence
number 4151317 (0%)

InnoDB: Database was not shutdown normally!

InnoDB: Starting crash recovery.

InnoDB: xtrabackup: Last MySQL binlog file position
179018, file name mysql-bin.000001

InnoDB: Removed temporary tablespace data
file: “ibtmp1”

InnoDB: Creating shared tablespace for temporary
tables

InnoDB: Setting file ‘./ibtmp1’ size to 12 MB.
Physically writing the file full; Please wait …

InnoDB: File ‘./ibtmp1’ size is now 12 MB.

InnoDB: 96 redo rollback segment(s) found. 1 redo
rollback segment(s) are active.

InnoDB: 32 non-redo rollback segment(s) are
active.

InnoDB: Waiting for purge to start

InnoDB: page_cleaner: 1000ms intended loop took
13284ms. The settings might not be optimal. (flushed=0 and evicted=0,
during the time.)

InnoDB: 5.7.10 started; log sequence number
4151317

xtrabackup: starting shutdown with
innodb_fast_shutdown = 1

InnoDB: FTS optimize thread exiting.

InnoDB: FTS optimize thread exiting.

InnoDB: Starting shutdown…

InnoDB: Shutdown completed; log sequence number
4151336

160321 11:04:32 completed OK!

### 还原全备:

innobackupex
–defaults-file=/data1/mysql5711_bak/my5711.cnf.bakuse –copy-back
/data1/dbatemp/5711back/

 

/usr/local/xtrabackup/bin/innobackupex version 2.4.1
based on MySQL server 5.7.10 Linux (x86_64) (revision id:
a2dc9d4)

160321 11:29:27 [01] Copying ib_logfile0 to
/data1/mysql5711/ib_logfile0

160321 11:29:31 [01] …done

160321 11:29:31 [01] Copying ib_logfile1 to
/data1/mysql5711/ib_logfile1

160321 11:29:34 [01] …done

160321 11:29:34 [01] Copying ib_logfile2 to
/data1/mysql5711/ib_logfile2

160321 11:29:37 [01] …done

160321 11:29:38 [01] Copying ibdata1 to
/data1/mysql5711/ibdata1

160321 11:29:38 [01] …done

160321 11:29:38 [01] Copying ./xtrabackup_info to
/data1/mysql5711/xtrabackup_info

160321 11:29:38 [01] …done

160321 11:29:38 [01] Copying
./slow_query_log/global_query_review_history.ibd to
/data1/mysql5711/slow_query_log/global_query_review_history.ibd

160321 11:29:38 [01] …done

160321 11:29:38 [01] Copying
./slow_query_log/db.opt to
/data1/mysql5711/slow_query_log/db.opt

160321 11:29:38 [01] …done

160321 11:29:38 [01] Copying
./slow_query_log/global_query_review.ibd to
/data1/mysql5711/slow_query_log/global_query_review.ibd

160321 11:29:38 [01] …done

160321 11:29:38 [01] Copying
./slow_query_log/global_query_review_history.frm to
/data1/mysql5711/slow_query_log/global_query_review_history.frm

160321 11:29:38 [01] …done

160321 11:29:38 [01] Copying
./slow_query_log/global_query_review.frm to
/data1/mysql5711/slow_query_log/global_query_review.frm

160321 11:29:38 [01] …done

160321 11:29:38 [01] Copying
./abc/weibo_asset_info.frm to
/data1/mysql5711/abc/weibo_asset_info.frm

160321 11:29:38 [01] …done

160321 11:29:38 [01] Copying ./abc/object_info.ibd
to /data1/mysql5711/abc/object_info.ibd

160321 11:29:39 [01] …done

160321 11:29:39 [01] Copying ./mysql/user.frm to
/data1/mysql5711/mysql/user.frm

……

……

160321 11:29:42 [01] …done

160321 11:29:42 [01] Copying
./xtrabackup_slave_info to
/data1/mysql5711/xtrabackup_slave_info

160321 11:29:42 [01] …done

160321 11:29:42 [01] Copying ./ib_buffer_pool to
/data1/mysql5711/ib_buffer_pool

160321 11:29:42 [01] …done

160321 11:29:42 completed OK!

## stream bakcup

innobackupex –stream=tar ./ |gzip – >
backup.tar.gz

 

innobackupex –compress –compress-threads=8 –stream=xbstream –parallel=4 ./ >
backup.xbstream

 

## 增量备份

### base backup:

innobackupex  /data1/dbatemp/

 

### 基于base bakcup的增量备份:

innobackupex   –incremental /data/dbatemp
–incremental-basedir=/data1/dbatemp/2016-03-21_12-02-03

 

160321 12:02:03 version_check Connecting to MySQL
server with DSN
‘dbi:mysql:;mysql_read_default_group=xtrabackup;port=5711;mysql_socket=/tmp/mysql5711.sock’
as ‘mysqlha’ (using password: YES).

160321 12:02:03 version_check Connected to MySQL
server

160321 12:02:03 version_check Executing a version
check against the server…

160321 12:02:03 version_check Done.

160321 12:02:03 Connecting to MySQL server host:
localhost, user: mysqlha, password: set, port: 5711, socket:
/tmp/mysql5711.sock

Using server version 5.7.11-log

/usr/local/xtrabackup/bin/innobackupex version 2.4.1
based on MySQL server 5.7.10 Linux (x86_64) (revision id:
a2dc9d4)

xtrabackup: uses posix_fadvise().

xtrabackup: cd to /data1/mysql5711

xtrabackup: open files limit requested 0, set to
204800

xtrabackup: using the following InnoDB
configuration:

xtrabackup: innodb_data_home_dir = .

xtrabackup: innodb_data_file_path =
ibdata1:100M:autoextend

xtrabackup: innodb_log_group_home_dir = .

xtrabackup: innodb_log_files_in_group = 3

xtrabackup: innodb_log_file_size = 1363148800

xtrabackup: using O_DIRECT

InnoDB: Number of pools: 1

160321 12:02:03 >> log scanned up to
(4151364)

xtrabackup: Generating a list of tablespaces

InnoDB: Allocated tablespace ID 30 for
slow_query_log/global_query_review_history, old maximum was
0

160321 12:02:04 [01] Copying ./ibdata1 to
/data1/dbatemp/2016-03-21_12-02-03/ibdata1

160321 12:02:04 >> log scanned up to
(4151364)

160321 12:02:04 [01] …done

160321 12:02:04 [01] Copying
./slow_query_log/global_query_review_history.ibd to
/data1/dbatemp/2016-03-21_12-02-03/slow_query_log/global_query_review_history.ibd

160321 12:02:04 [01] …done

160321 12:02:04 [01] Copying
./slow_query_log/global_query_review.ibd to
/data1/dbatemp/2016-03-21_12-02-03/slow_query_log/global_query_review.ibd

160321 12:02:05 [01] Copying ./sys/sys_config.ibd to
/data1/dbatemp/2016-03-21_12-02-03/sys/sys_config.ibd

160321 12:02:05 [01] …done

160321 12:02:05 >> log scanned up to
(4151364)

160321 12:02:06 Executing FLUSH NO_WRITE_TO_BINLOG
TABLES…

160321 12:02:06 Executing FLUSH TABLES WITH READ
LOCK…

160321 12:02:06 Starting to backup non-InnoDB tables
and files

160321 12:02:06 [01] Copying
./slow_query_log/db.opt to
/data1/dbatemp/2016-03-21_12-02-03/slow_query_log/db.opt

160321 12:02:06 [01] …done

160321 12:02:06 [01] Copying
./slow_query_log/global_query_review_history.frm to
/data1/dbatemp/2016-03-21_12-02-03/slow_query_log/global_query_review_history.frm

160321 12:02:10 Finished backing up non-InnoDB tables
and files

Failed to get master binlog coordinates from SHOW SLAVE
STATUS

This means that the server is not a replication slave.
Ignoring the –slave-info option

160321 12:02:10 [00] Writing
xtrabackup_binlog_info

160321 12:02:10 [00] …done

160321 12:02:10 Executing FLUSH NO_WRITE_TO_BINLOG
ENGINE LOGS…

xtrabackup: The latest check point (for incremental):
‘4151355’

xtrabackup: Stopping log copying thread.

.160321 12:02:10 >> log scanned up to
(4151364)

160321 12:02:10 Executing UNLOCK TABLES

160321 12:02:10 All tables unlocked

160321 12:02:10 [00] Copying ib_buffer_pool to
/data1/dbatemp/2016-03-21_12-02-03/ib_buffer_pool

160321 12:02:10 [00] …done

160321 12:02:10 Backup created in directory
‘/data1/dbatemp/2016-03-21_12-02-03’

MySQL binlog position: filename ‘mysql-bin.000001’,
position ‘154’

160321 12:02:10 [00] Writing backup-my.cnf

160321 12:02:10 [00] …done

160321 12:02:10 [00] Writing xtrabackup_info

160321 12:02:10 [00] …done

xtrabackup: Transaction log of lsn (4151355) to
(4151364) was copied.

160321 12:02:10 completed OK!

### prepare增量备份

prepare base

 

innobackupex –incremental –apply-log –redo-only /data1/dbatemp/2016-03-21_12-02-03/
–use-memory=1G 

/usr/local/xtrabackup/bin/innobackupex version 2.4.1
based on MySQL server 5.7.10 Linux (x86_64) (revision id:
a2dc9d4)

xtrabackup: cd to
/data1/dbatemp/2016-03-21_12-02-03

xtrabackup: This target seems to be not prepared
yet.

InnoDB: Number of pools: 1

xtrabackup: xtrabackup_logfile detected: size=8388608,
start_lsn=(4151355)

xtrabackup: using the following InnoDB configuration
for recovery:

xtrabackup: innodb_data_home_dir = .

xtrabackup: innodb_data_file_path =
ibdata1:100M:autoextend

xtrabackup: innodb_log_group_home_dir = .

xtrabackup: innodb_log_files_in_group = 1

xtrabackup: innodb_log_file_size = 8388608

xtrabackup: using the following InnoDB configuration
for recovery:

xtrabackup: innodb_data_home_dir = .

xtrabackup: innodb_data_file_path =
ibdata1:100M:autoextend

xtrabackup: innodb_log_group_home_dir = .

xtrabackup: innodb_log_files_in_group = 1

xtrabackup: innodb_log_file_size = 8388608

xtrabackup: Starting InnoDB instance for
recovery.

xtrabackup: Using 1073741824 bytes for buffer pool (set
by –use-memory parameter)

InnoDB: PUNCH HOLE support not available

InnoDB: Mutexes and rw_locks use GCC atomic
builtins

InnoDB: Uses event mutexes

InnoDB: GCC builtin __sync_synchronize() is used for
memory barrier

InnoDB: Compressed tables use zlib 1.2.3

InnoDB: Number of pools: 1

InnoDB: Using CPU crc32 instructions

InnoDB: Initializing buffer pool, total size = 1G,
instances = 1, chunk size = 128M

InnoDB: Completed initialization of buffer pool

InnoDB: page_cleaner coordinator priority: -20

InnoDB: Highest supported file format is
Barracuda.

InnoDB: Log scan progressed past the checkpoint lsn
4151355

InnoDB: Doing recovery: scanned up to log sequence
number 4151364 (0%)

InnoDB: Doing recovery: scanned up to log sequence
number 4151364 (0%)

InnoDB: Database was not shutdown normally!

InnoDB: Starting crash recovery.

InnoDB: xtrabackup: Last MySQL binlog file position
179018, file name mysql-bin.000001

InnoDB: not started

InnoDB: xtrabackup: Last MySQL binlog file position
179018, file name mysql-bin.000001

xtrabackup: starting shutdown with
innodb_fast_shutdown = 1

InnoDB: Starting shutdown…

InnoDB: Shutdown completed; log sequence number
4151373

InnoDB: Number of pools: 1

160321 12:15:37 completed OK!

“`

prepare增量:

innobackupex –incremental –apply-log –redo-only
/data1/dbatemp/2016-03-21_12-02-03/ –use-memory=1G
–incremental-dir=/data1/dbatemp/2016-03-21_12-19-21/

/usr/local/xtrabackup/bin/innobackupex version 2.4.1 based on MySQL server 5.7.10 Linux (x86_64) (revision id:
a2dc9d4)

incremental backup from 4151355 is enabled.

xtrabackup: cd to /data1/dbatemp/2016-03-21_12-02-03

xtrabackup: This target seems to be
already prepared with –apply-log-only.

InnoDB: Number of pools: 1

xtrabackup: xtrabackup_logfile detected: size=8388608, start_lsn=(4151355)

xtrabackup: using the following InnoDB
configuration for recovery:

xtrabackup:   innodb_data_home_dir
= .

xtrabackup:   innodb_data_file_path
= ibdata1:100M:autoextend

xtrabackup:  
innodb_log_group_home_dir = /data1/dbatemp/2016-03-21_12-19-21/

xtrabackup:  
innodb_log_files_in_group = 1

xtrabackup:   innodb_log_file_size
= 8388608

xtrabackup: Generating a list of
tablespaces

InnoDB: Allocated tablespace ID 30 for
slow_query_log/global_query_review_history, old maximum was 0

xtrabackup: page size for /data1/dbatemp/2016-03-21_12-19-21//ibdata1.delta is
16384
bytes

Applying /data1/dbatemp/2016-03-21_12-19-21//ibdata1.delta
to ./ibdata1…

xtrabackup: page size for /data1/dbatemp/2016-03-21_12-19-21//slow_query_log/global_query_review.ibd.delta is 16384
bytes

Applying /data1/dbatemp/2016-03-21_12-19-21//slow_query_log/global_query_review.ibd.delta to ./slow_query_log/global_query_review.ibd…

xtrabackup: page size for /data1/dbatemp/2016-03-21_12-19-21//slow_query_log/global_query_review_history.ibd.delta is 16384
bytes

Applying /data1/dbatemp/2016-03-21_12-19-21//slow_query_log/global_query_review_history.ibd.delta to ./slow_query_log/global_query_review_history.ibd…

xtrabackup: page size for /data1/dbatemp/2016-03-21_12-19-21//abc/weibo_asset_info.ibd.delta is 16384
bytes

Applying /data1/dbatemp/2016-03-21_12-19-21//abc/weibo_asset_info.ibd.delta to ./abc/weibo_asset_info.ibd…

xtrabackup: page size for /data1/dbatemp/2016-03-21_12-19-21//abc/object_info.ibd.delta is 16384
bytes

Applying /data1/dbatemp/2016-03-21_12-19-21//abc/object_info.ibd.delta to ./abc/object_info.ibd…

xtrabackup: page size for /data1/dbatemp/2016-03-21_12-19-21//mysql/time_zone_transition.ibd.delta is 16384
bytes

Applying /data1/dbatemp/2016-03-21_12-19-21//mysql/time_zone_transition.ibd.delta to ./mysql/time_zone_transition.ibd…

xtrabackup: page size for /data1/dbatemp/2016-03-21_12-19-21//mysql/slave_relay_log_info.ibd.delta is 16384
bytes

Applying /data1/dbatemp/2016-03-21_12-19-21//mysql/slave_relay_log_info.ibd.delta to ./mysql/slave_relay_log_info.ibd…

xtrabackup: page size for /data1/dbatemp/2016-03-21_12-19-21//mysql/engine_cost.ibd.delta is 16384
bytes

Applying /data1/dbatemp/2016-03-21_12-19-21//mysql/engine_cost.ibd.delta to ./mysql/engine_cost.ibd…

xtrabackup: page size for /data1/dbatemp/2016-03-21_12-19-21//mysql/slave_worker_info.ibd.delta is 16384
bytes

Applying /data1/dbatemp/2016-03-21_12-19-21//mysql/slave_worker_info.ibd.delta to ./mysql/slave_worker_info.ibd…

xtrabackup: page size for /data1/dbatemp/2016-03-21_12-19-21//mysql/time_zone_leap_second.ibd.delta is 16384
bytes

Applying /data1/dbatemp/2016-03-21_12-19-21//mysql/time_zone_leap_second.ibd.delta to ./mysql/time_zone_leap_second.ibd…

xtrabackup: page size for /data1/dbatemp/2016-03-21_12-19-21//mysql/help_category.ibd.delta is 16384
bytes

Applying /data1/dbatemp/2016-03-21_12-19-21//mysql/help_category.ibd.delta to ./mysql/help_category.ibd…

xtrabackup: page size for /data1/dbatemp/2016-03-21_12-19-21//mysql/slave_master_info.ibd.delta is 16384
bytes

Applying /data1/dbatemp/2016-03-21_12-19-21//mysql/slave_master_info.ibd.delta to ./mysql/slave_master_info.ibd…

xtrabackup: page size for /data1/dbatemp/2016-03-21_12-19-21//mysql/servers.ibd.delta is 16384
bytes

Applying /data1/dbatemp/2016-03-21_12-19-21//mysql/servers.ibd.delta to ./mysql/servers.ibd…

xtrabackup: page size for /data1/dbatemp/2016-03-21_12-19-21//mysql/time_zone_name.ibd.delta is 16384
bytes

Applying /data1/dbatemp/2016-03-21_12-19-21//mysql/time_zone_name.ibd.delta to ./mysql/time_zone_name.ibd…

xtrabackup: page size for /data1/dbatemp/2016-03-21_12-19-21//mysql/plugin.ibd.delta is 16384
bytes

Applying /data1/dbatemp/2016-03-21_12-19-21//mysql/plugin.ibd.delta to ./mysql/plugin.ibd…

xtrabackup: page size for /data1/dbatemp/2016-03-21_12-19-21//mysql/innodb_index_stats.ibd.delta is 16384
bytes

Applying /data1/dbatemp/2016-03-21_12-19-21//mysql/innodb_index_stats.ibd.delta to ./mysql/innodb_index_stats.ibd…

xtrabackup: page size for /data1/dbatemp/2016-03-21_12-19-21//mysql/server_cost.ibd.delta is 16384
bytes

Applying /data1/dbatemp/2016-03-21_12-19-21//mysql/server_cost.ibd.delta to ./mysql/server_cost.ibd…

xtrabackup: page size for /data1/dbatemp/2016-03-21_12-19-21//mysql/help_topic.ibd.delta is 16384
bytes

Applying /data1/dbatemp/2016-03-21_12-19-21//mysql/help_topic.ibd.delta to ./mysql/help_topic.ibd…

xtrabackup: page size for /data1/dbatemp/2016-03-21_12-19-21//mysql/time_zone_transition_type.ibd.delta is 16384
bytes

Applying /data1/dbatemp/2016-03-21_12-19-21//mysql/time_zone_transition_type.ibd.delta to ./mysql/time_zone_transition_type.ibd…

xtrabackup: page size for /data1/dbatemp/2016-03-21_12-19-21//mysql/help_relation.ibd.delta is 16384
bytes

Applying /data1/dbatemp/2016-03-21_12-19-21//mysql/help_relation.ibd.delta to ./mysql/help_relation.ibd…

xtrabackup: page size for /data1/dbatemp/2016-03-21_12-19-21//mysql/gtid_executed.ibd.delta is 16384
bytes

Applying /data1/dbatemp/2016-03-21_12-19-21//mysql/gtid_executed.ibd.delta to ./mysql/gtid_executed.ibd…

xtrabackup: page size for /data1/dbatemp/2016-03-21_12-19-21//mysql/innodb_table_stats.ibd.delta is 16384
bytes

Applying /data1/dbatemp/2016-03-21_12-19-21//mysql/innodb_table_stats.ibd.delta to ./mysql/innodb_table_stats.ibd…

xtrabackup: page size for /data1/dbatemp/2016-03-21_12-19-21//mysql/time_zone.ibd.delta is 16384
bytes

Applying /data1/dbatemp/2016-03-21_12-19-21//mysql/time_zone.ibd.delta to ./mysql/time_zone.ibd…

xtrabackup: page size for /data1/dbatemp/2016-03-21_12-19-21//mysql/help_keyword.ibd.delta is 16384
bytes

Applying /data1/dbatemp/2016-03-21_12-19-21//mysql/help_keyword.ibd.delta to ./mysql/help_keyword.ibd…

xtrabackup: page size for /data1/dbatemp/2016-03-21_12-19-21//sys/sys_config.ibd.delta is 16384
bytes

Applying /data1/dbatemp/2016-03-21_12-19-21//sys/sys_config.ibd.delta to ./sys/sys_config.ibd…

xtrabackup: using the following InnoDB
configuration for recovery:

xtrabackup:   innodb_data_home_dir
= .

xtrabackup:   innodb_data_file_path
= ibdata1:100M:autoextend

xtrabackup:  
innodb_log_group_home_dir = /data1/dbatemp/2016-03-21_12-19-21/

xtrabackup:  
innodb_log_files_in_group = 1

xtrabackup:   innodb_log_file_size
= 8388608

xtrabackup: Starting InnoDB instance
for recovery.

xtrabackup: Using 1073741824 bytes for buffer pool (set by
–use-memory parameter)

InnoDB: PUNCH HOLE support not
available

InnoDB: Mutexes and rw_locks use GCC
atomic builtins

InnoDB: Uses event
mutexes

InnoDB: GCC builtin
__sync_synchronize() is used for memory barrier

InnoDB: Compressed tables use zlib
1.2.3

InnoDB: Number of pools: 1

InnoDB: Using CPU crc32
instructions

InnoDB: Initializing buffer pool,
total size = 1G, instances = 1, chunk size = 128M

InnoDB: Completed initialization of
buffer pool

InnoDB: page_cleaner coordinator
priority: -20

InnoDB: Highest supported file format
is Barracuda.

InnoDB: Log scan progressed past the
checkpoint lsn 4151355

InnoDB: Doing recovery: scanned up to log sequence number
4151364 (0%)

InnoDB: Doing recovery: scanned up to log sequence number
4151364 (0%)

InnoDB:  Are you sure you are using
the right ib_logfiles to start up the database? Log sequence number in
the ib_logfiles is 4151355, less than the log sequence number in the
first system tablespace file header, 4151373.

InnoDB: Database was not shutdown normally!

InnoDB: Starting crash
recovery.

InnoDB: xtrabackup: Last MySQL binlog file position
179018, file name mysql-bin.000001

InnoDB: not started

InnoDB: xtrabackup: Last MySQL binlog file position
179018, file name mysql-bin.000001

 

xtrabackup: starting shutdown with
innodb_fast_shutdown = 1

InnoDB: Starting
shutdown…

InnoDB: Shutdown completed; log
sequence number 4151373

InnoDB: Number of pools: 1

160321 12:21:44 [01]
Copying /data1/dbatemp/2016-03-21_12-19-21/slow_query_log/db.opt to ./slow_query_log/db.opt

160321 12:21:44 [01] 
     
…done

160321 12:21:44 [01]
Copying /data1/dbatemp/2016-03-21_12-19-21/slow_query_log/global_query_review_history.frm to ./slow_query_log/global_query_review_history.frm

160321 12:21:44 [01] 
     
…done

160321 12:21:44 [01]
Copying /data1/dbatemp/2016-03-21_12-19-21/slow_query_log/global_query_review.frm to ./slow_query_log/global_query_review.frm

160321 12:21:44 [01] 
     
…done

160321 12:21:44 [01]
Copying /data1/dbatemp/2016-03-21_12-19-21/abc/weibo_asset_info.frm to ./abc/weibo_asset_info.frm

160321 12:21:44 [01] 
     
…done

160321 12:21:44 [01]
Copying /data1/dbatemp/2016-03-21_12-19-21/abc/db.opt to ./abc/db.opt

160321 12:21:44 [01] 
     
…done

160321 12:21:48 [01]
Copying /data1/dbatemp/2016-03-21_12-19-21/sys/session.frm to ./sys/session.frm

160321 12:21:48 [01] 
     
…done

160321 12:21:48 [00]
Copying /data1/dbatemp/2016-03-21_12-19-21//xtrabackup_binlog_info to ./xtrabackup_binlog_info

160321 12:21:48 [00] 
     
…done

160321 12:21:48 [00]
Copying /data1/dbatemp/2016-03-21_12-19-21//xtrabackup_info to ./xtrabackup_info

160321 12:21:48 [00] 
     
…done

160321 12:21:48 completed
OK!

 

[root@hebe211 dbatemp]# cat
2016-03-21_12-02-03/xtrabackup_checkpoints 

backup_type = log-applied

from_lsn = 0

to_lsn = 4151355

last_lsn = 4151364

compact = 0

recover_binlog_info = 0

[root@hebe211 dbatemp]# cat
2016-03-21_12-19-21/xtrabackup_checkpoints 

backup_type = incremental

from_lsn = 4151355

to_lsn = 4151355

last_lsn = 4151364

compact = 0

recover_binlog_info = 0

prepare(base+incremental) 可选

压缩备份

innobackupex –compress –compress-threads=8
/data1/dbatemp/

生成QP文件

解压缩:

innobackupex –decompress
/data1/dbatemp/2016-03-21_12-32-46/

亟待设置qpress

备份还原单表

创制单表的Backup

innobackupex –include=’abc.weibo_asset_info’
/data1/dbatemp/

prepare单表bakcup

innobackupex –apply-log –export
/data1/dbatemp/2016-03-21_12-46-24/

xtrabackup: export metadata of table
‘abc/weibo_asset_info’ to file `./abc/weibo_asset_info.exp` (4
indexes)
xtrabackup: name=PRIMARY, id.low=68, page=3
xtrabackup: name=ip_in, id.low=69, page=4
xtrabackup: name=owner, id.low=70, page=5

-rw-r–r– 1 root root 1309 Mar 21 12:49
weibo_asset_info.cfg
-rw-r—– 1 root root 16384 Mar 21 12:49
weibo_asset_info.exp
-rw-r—– 1 root root 8980 Mar 21 12:46
weibo_asset_info.frm
-rw-r—– 1 root root 589824 Mar 21 12:46
weibo_asset_info.ibd

复原单表

回复机上执行:

alter table weibo_asset_info discard
tablespace;

将weibo_asset_info.exp和weibo_asset_ibd文件传到指标机目的目录中

执行:

alter table weibo_asset_info import
tablespace;

xtrabackup

fullbackup

创建full backup

xtrabackup –backup
–target-dir=/data1/dbatemp/testx/

prepare backup

xtrabackup –prepare
–target-dir=/data1/dbatemp/testx/

增量backup

始建叁个full backup

xtrabackup –backup
–target-dir=/data1/dbatemp/testa/

开创增量

xtrabackup –backup
–target-dir=/data1/dbatemp/testa_incremental
–incremental-basedir=/data1/dbatemp/testa

prepare base

xtrabackup –prepare –apply-log-only
–target-dir=/data1/dbatemp/testa/

prepare incremental

xtrabackup –prepare –apply-log-only
–target-dir=/data1/dbatemp/testa/
–incremental-dir=/data1/dbatemp/testa_incremental

prepare base+incremental

xtrabackup –prepare
–target-dir=/data1/dbatemp/testa/

还原备份(需手动)

mkdir mysql5711

cd /data1/dbatemp/testa

rsync -rvt –exclude ‘xtrabackup_checkpoints’
–exclude ‘xtrabackup_logfile’ ./ /data1/mysql5711

cp my5711.cnf /data1/mysql5711

chown -R my5711:mysql mysql5711

创建基于GTID的SLAVE

始建全备

xtrabackup –backup
–target-dir=/data1/dbatemp/testb/

MySQL binlog position: filename ‘mysql-bin.000002’,
position ‘1099’, GTID of the last change
‘a34b5a32-e04e-11e5-a5bf-782b22675711:1’
MySQL slave binlog position: master host ‘10.75.22.67’,
purge list
‘a34b5a32-e04e-11e5-a5bf-782b22675711:1’

prepare

xtrabackup –prepare
–target-dir=/data1/dbatemp/testb/

restore,将backup移动到目的目录大概服务器

计划开启gtid的slave

set global
gtid_purged=“a34b5a32-e04e-11e5-a5bf-782b22675711:1”;

change master to master_host=’10.75.22.67′,
master_user=’replica’,
master_password=’eHnNCaQE3ND’,MASTER_PORT=5711,MASTER_AUTO_POSITION
= 1;

 

 

 

 

 

 

 

————————————————————————————————————————————————————————————————————————————————————————————————————

 

xtrabackup2.4.1文档

  • innobackupex
    innobackupex只是xtrabackup的一个符号链接,innobackupex依然支撑像2.2版本相同辅助具有的特征及语法,在明天的版本中会被降级大概移除
  • xtrabackup
    备份整个MySQL实例的MyISAM,InnoDB表,XtraDB表
  • xbcrpt 加密和平化解密备份文件
  • xbstream
    允许streaming和透过xbstream格式中领到文件
  • xbcloud
    从云中上传大概下载全部依旧有个别xbstream归档文件
  • 2.3后头的版本推荐通过xtrabackup脚本备份

Percona Xtrabackup Features

  • 热备
  • 增量复制
  • 将压缩后的备份stream到其余server
  • 在线的在mysql server实例之间移动表
  • 更随意的搭建新的从库
  • 备份不增添server的下压力

Innobackupex

前提

  • 连日和权杖 连接server,databases
    user通过–user和–password选项,假若不点名,xtrabackup认为是系统用户执行

$ innobackupexuser=DBUSERpassword=SECRET /path/to/backup/dir/

$ innobackupexuser=LUKE  —password=US3TH3F0RC3stream=tar ./ |

bzip2

$ xtrabackupuser=DVADERpassword=14MY0URF4TH3Rbackuptargetdir=/data/bkps/

  • 任何连接选项
  • Option
  • Description
  • –port
  • 通过TCP/IP连接数据库的端口号
  • –socket
  • 本地连接sockect
  • –host
  • 通过TCP/IP连接的数据库的IP
  • 获准和权杖
    延续数据库之后,须要server文件系统层面datadir目录的读写和履行权限
    至于数据库层面,须要如下权限:
    1,RELOAD和LOCK TABLES权限
    须求在拷贝文件在此以前FLUSH TABLES WITH READLOCKS和FLUSH ENGINE
    LOGS。此外当打开Backup Locks,执行LOCK TABLES FO奥德赛 BACKUP和LOCK BINLOG
    FO景逸SUV BACKUP须要这两样权限
    2,REPLICATION CLIENT权限 获得binlog的点位
    3,CREATE TABLESPACE权限 指标是为了导入tables
    4,PROCESS权限 show processlist
    5, SUPE君越权限 复制环境下start slave 和stop slave
    6,CREATE权限
    指标是成立PECR-VCONA_SECHEMA.xtrabackup_history数据库和表
    7,INSERT权限
    在PERCONA_SCHEAM.xtrabackup_history表中扩展历史记录
    8,SELECT权限 使用innobackupex –incremental-history-name
    只怕innobackupex
    –incremental-history-uuid目标是为着查询PE奥德赛CONA_SCHEMA.xtrabackup表中innodb_tolsn的值
    创建贰个能够full backup最小权限的数据库用户:
    mysql> CREATE USER ‘bkpuser’@’localhost’ IDENTIFIED BY ‘s3cret’;
  • mysql> GRANT RELOAD,LOCK TABLES,REPLICATION
    CLIENT ON *.* TO ‘bkpuser’@’localhost’;
  • mysql> FLUSH PRIVILEGES;
  • 全量备份生命周期-FULL Backups
    **
    因而Innobackupex创造二个备份**

innobackupex是二个透过xtrabackup结合了xbstream和xbcrypt等来备份一整个数据库实例的工具

蒋健二个一体化备份,除了连接数据库的选项还只需求三个参数,备份存款和储蓄目录的不二法门

$ innobackupex –user=DBUSER –password=DBUSERPASS
/path/to/BACKUP-DIR/

后来检查确认音信输出的尾声一行:

innobackupex: Backup created in directory
’/path/to/BACKUP-DIR/2013-03-25_00-00-09’

innobackupex: MySQL binlog position: filename
’mysql-bin.000003’, position 1946

111225 00:00:53  innobackupex: completed
OK!

备份会最后存款和储蓄在以时日戳命名的目录内 

在底层,在后台,innobackupex被称作二进制xtrabackup来备份Innodb全数表的数码同时拷贝全数的frm表定义文件,数据,和MyISAM,ME奥德赛GE,CSV表相关的文件,触发器,数据库配置文件到三个小时戳的目录中去

任何急需考虑的抉择

–no-timestamp:告诉innobackupex不要创立1个年华戳目录来储存备份

–defaults-file:可以提供innobackupex其余的数据库配置文件。唯一的限量就是必须放在第二个参数的地点

innobackupexdefaultsfile=/tmp/othermy.cnfuser=XXXpassword=XXX /path/to/backup

PREPARE阶段,用innobackupex prepare Full
Backup

在开创了2个backup之后,数据还不能够用于苏醒,因为有未提交的作业未形成可能业务日志供给重播,做那个待定的操作需求数据文件一致.那些都以prepare阶段的指标,一旦这一个成就,数据就能够用了

内需内定选项apply-log:

innobakupex –apply-log
/path/to/BACKUP-DIR

只要成功了,innobackupex操作之后,数据是登时可用的

在后台,innobackupex通过读取backup-my.cnf起头prepare进度,在随后,innobackupe重播已交给的业务并回滚未提交的事务,一旦那个操作实现,全数讯息在表空间中(innodb文件),Log文件被重建.这几个验证了调用xtrabackup
–prepare三回。

瞩目那么些preparation不切合增量备份,假如依照增量备份,将无法’add’增量部分

通过Innobackupex还原Full Backup

–copy-back选项,在server的datadir目录执行一份备份的回复

innobakupex —copy-back /path/to/BACKUP-DIR

–copy-back:做数据恢复生机时将备份数据文件拷贝到MySQL服务器的datadir 

会跟实际my.cnf文件里的配置,拷贝全部数据有关的文本到datadir。

注意:

1.datadir目录必须为空。除非钦赐innobackupex
–force-non-empty-directorires选项钦赐,不然–copy-backup选项不会覆盖

2.在restore在此以前,必须shutdown
MySQL实例,你无法将2个运作中的实例restore到datadir目录中

3.由于文件属性会被封存,当先1/2情况下你须求在启动实例此前将文件的属主改为mysql,那个文件将属于成立备份的用户

chown -R my5711:mysql /data1/dbrestore

以上亟待在用户调用Innobackupex此前到位

其他品种备份

由此Innobackupex进行增量备份

在各种备份之间并不是有所的消息都有变化,增量备份的指标是收缩需求的储存体量和创办一份备份的时光

这一个足以成功是因为各类InnoDB的页都有3个LSN,这几个LSN相当于一整个数据库的本子号码,每便数据库更改,那个Number就会递增

增量备份便是拷贝某多少个钦赐LSN起始的兼具page

若果那么些pages以他们分其余相继被安放一起,应用那么些日记将再度创建影响数据库的过程,在创制backup时刻产生多少

由此innobakupex创制一份增量备份

第3,创造一份全量备份作为基础用于之后的增量备份

innobackupex /data1/dbbackup 

将会在/data1/dbbackup目录生成三个分包时间戳的目录,比如假若备份是在上个月月中最终一天成立.BASEDIEnclave是/data1/dbbackup/二零一六-02-29_23-01-18

能够通过innobackupex
–no-timestamp选项覆盖那种表现,备份将会被创制在内定的目录中

设若检查BASE-DI路虎极光目录中的xtrabackup-checkpoints文件,你能见到如下:

backup_type = full-backuped

from_lsn = 0

to_lsn = 1291135

第三天创设一份增量备份,通过–incremental选项并提供BASEDI汉兰达:

innobackupexincremental /data1/backupsincrementalbasedir=BASEDIR

会在/data1/backups目录里生成另一份蕴涵时间戳的目录,便是/data1/backups/二零一五-03-01_23-01-18,该目录包罗了增量备份,大家称之为INCREMENTAL-DIENCORE-1,假若检查该目录的xtrabackup-checkpoints文件。会看出如下:

backup_type = incremental

from_len = 1291135

to_lsn = 1352113

恍如的,第玖日创制另一份增量备份。但是第叁天的增量备份变成了BASEDI奇骏

innobackupex –incremental /data/backups
–incremental-basedir=INCRENMENTAL-DIR-1

结果生成/data1/backups/二〇一六-03-02_23-01-18,用INCREMENTAL-DIR-2来表示:

backup_type = incremental

from_lsn = 1352113

to_lsn  = 1358967

像我们前边所说,增量备份只拷贝LSN大于一个内定值的pages,提供LSN会产生相同数量的目录:

innobackupexincremental /data/backupsincrementallsn=1291135

innobackupexincremental /data/bakcupsincrementallsn=1358967

因为全备或上3个增备并不是总在系统中(如备份后传输到长途),用那种方法做增量备份万分实惠。那种进度只可以影响XtraDB和InnoDB表,其余汽油发动机的表如MyISAM.在做增量备份的经过中时候会拷贝全部。

因而innobakupex prepare一份增量备份

prepare增量备份与全量备份分歧。那里须求相当注意:

  • 率先唯有付出过的政工须要在每份备份中个重播(apply-log BASEDI昂Cora)
  • 这么些将增量的一部分联合到全量备份的base中去()
  • 下一场,未提交的政工必须回滚,为了有3个整日可用的备份

倘诺在遵照base
backup中重放提交业务回滚未提交业务,是不能够add增量的。要是对于增量的如此做,是无法add从那刻起的数目和此外的增量。

–redo-only –apply-log:

强制备份日志时只redo
,跳过rollback。那在做增量备份时那么些须求

innobackupex –apply-log —redoonly BASE-DIR

下一场,第四个增量Backup能apply给base backup:

innobackupex –apply-log –redo-only BASE-DIR
–incremental-dir=INCRENMENTAL-DIR-1

 

借使没有–incremental-dir被安装了,innobackupex会选拔在basedir里近来创建的二个子目录

此刻,BASE-DI冠道包涵了第壹手到第2遍增量备份的数据,注意全备永远都在base
backup目录里

接下来在其次个增量备份上再也那几个历程:

innobackupex –apply-log BASE-DIR
–incremental-dir=INCREMENTAL-DIR-2

假若出现’complete ok’,最终的数据会都merge到base
backup目录中去(BASE-DILAND)

只顾:–redo-only用于merging全部的增量除了最终二个

您能够通过以上的进度给base扩展越多的增量,只要遵守备份的姣好的年月顺序依次即可。假如用错误的各种Merge增量,备份就全盘无用了。假诺对apply的依次有疑点,能够检查各种目录的xtrabackup_checkpoints文件

就算你对base
backup目录merge完全体的增量,接下去prepare,回滚未提交的事情:

innobackupex –apply-log BASE-DIR 
(innobackupex回滚未提交的工作)

此时的backup能够即时用于还原了,此步preparation是可选的,然和,若是您复苏没有那步,database
server会开端rollback未提交的工作。倘使发生crash时,database
server会做相同的工作。那会延迟db
server的起步时间,假设此步prepare则会制止

瞩目innobacupex不会创建iblog*这一个文件,假设想要创设,用xtrabackup
-prepare效能于该目录,不然,那几个文件在server运行的时候被成立

通过innobackupex还原增量备份

preparing增量备份之后,base dir正是3个full
backup,还原格局:

innobackupex —copy-back BASE-DIR

经过xbstream和tar实行增量流式备份

运用xbstream
streaming选项,备份能够被打包成自定义的xbstream格式,同样供给八个Base
backup

innobakcupex
/data/bakcups

地面备份:

innobackupexincrementalincrementallsn=LSNnumberstream=xbstream ./ > incremental.xbstream

解压备份:

xbstream -x < incremental.xbstream

做一份本地备份并streaming到长途服务器然后解压:

innobackupex  –incremental
–incremental-lsn=LSN-number –stream=xbstream ./ |
/

ssh user@hostname ” cat – | xbstream
-x -C > /backup-dir/”

–stream=[tar]

备 份文件输出格式, tar时选用tar4ibd ,
该文件可在XtarBackup binary文件中得到.如果备份时有钦定–stream=tar,
则tar4ibd文件所处目录一定要在$PATH中(因为使用的是tar4ibd去缩短,
在XtraBackup的binary包中可取得该公文)。


使用参数stream=tar备份的时候,你的xtrabackup_logfile恐怕会一时半刻放在/tmp目录下,即便你备份的时候出现写入较大的话
xtrabackup_logfile可能会不小(5G+),很恐怕会撑满你的/tmp目录,能够因此参数–tmpdir钦命目录来化解那个题材

有的备份

只备份部分的表大概db,前提是打开innodb_file_per_table选项,每张表有独立的表空间。你无法透过简单地将prepared的有的备份使用–copy-back选项直接复制回数据目录,而是要因此导入表的趋势来完毕恢复生机。当然,某个意况下,部分备份也得以一向通过–copy-back进行理并答复原,但那种措施还原而来的数目多数会生出多少区其他标题,由此,无论如何不推荐应用那种方法。

始建部分备份

有三种情势钦点备份那有些数量

  • –include选项
    使用正则表达式方式时,须要为其钦点匹配要备份的表的一体化名称,即databasename.tablename

innobackupex –include=’^mydatabase[.]mytable’ /path/to/backup

地点的通令只备份表名相匹配的多少。–include选项传递给xtrabackup
–tables,对各样库中的每种表逐一匹配,因而会创建全部的库,可是是空的目录。

  • –tables-file选项
    此选项的参数需若是2个文本名,此文件中每行包涵二个要备份的表的总体名称,格式为databasename.tablename。

echo “mydatabase.mytable” > /tmp/tables.txt

innobackupex –tables-file=/tmp/tables.txt
/path/to/backup

该选项传递给xtrabackup
–tables-file,与–table选项差别,唯有要备份的表的库才会被创制

  • –databases选项
    此选项接受的参数为多少名,要是要钦点八个数据库,互相间要求以空格隔断;同时,在钦点某数据库时,也得以只钦点个中的某张表。别的,此选项也足以承受2个文本为参数,文件中每一行事三个要备份的目标

innobackupex –databases=”mydatabase.mytable mysql” /path/to/backup

该选拔对innodb引擎表无效,如故会备份的

prepare部分备份

prepare部分备份的进程看似于导出表的经过,要动用–export选项进行:

innobackupex –apply-log –export
/path/to/partial/backup

此命令执行进度中,innobackupex会调用xtrabackup命令从数额字典中移除缺点和失误的表,由此,会议及展览示出不少有关“表不存在”类的警告消息。同时,也会显得出为备份文件中留存的表成立.exp文件的有关新闻。

光复部分备份

恢复生机部分备份的历程跟导入表的历程一样。当然,也能够经过一贯复制prepared状态的备份直接至数据目录中落到实处恢复生机,不要此时需要数据目录处于同一状态。

削减备份

备份innodb表的时候大概会忽视帮衬索引,会使备份更紧密并且节约磁盘空间。缺点是帮忙索引重建导致backup
prepare的历程会供给更长的时光。备份大小不一样在于协理索引大小的区分。。例如没有加–compat选项的full
backup.

留神:压缩备份不协助系统表空间,,所以需求开辟innodb-file-per-table选项

始建压缩备份

innobackupex –compact /data/backups

会在/data/backups目录下创办个日子戳目录

假定检查BASE-DILacrosse里面包车型大巴xtrabackup_checkpoints文件,能来看如下:

backup_type = full-backuped
from_lsn = 0
to_lsn = 2888984349
last_lsn = 2888984349
compact = 1

未曾–compact选项compact的值为0,那种措施方便的反省备份是还是不是带有帮助索引

preparing压缩备份

preparing压缩备份供给重建索引,prepare
backup须求–rebuild-index跟随–apply-logs

innobackupex –apply-log –rebuild-indexes
/data/backups/2016-03-14_10-29-48

一声令下输出,除了标准innobackupex输出,还包罗了目录重建的新闻

光复压缩备份

innnobackupex有1个–copy-back选项。功用是讲一份backup还原到server的datadir目录中去

innobackupex –copy-back /path/to/backup-dir

会将有着数据有关的兼具文件拷贝到datadir目录,由my.cnf配置文件定义

加密备份

2.1版本引入,加密可能解密本地备份可能由xbstream选项备份的流式备份,加密由libgcrypt库完结

始建加密备份

加密亟需钦点以下选项(–encrypt-key和–encrypt-key-file只需点名在这之中之一即可)

  • –encryption=ALGOTucsonITHM
    最近支撑的算法有ASE128,AES192,AES256
  • –encrypt-key=ENCRYPTION_KEY
    使用合适长度加密key,因为会记录到命令行,所以不引进应用
  • –encrypt-key-file=KEYFILE
    文件必须是多个简约二进制或然文本文件
    加密key可透过以下命令行命令生成,生成的值可用来Key  openssl rand -base64 24 

–encrypt-key选项使用栗子:

innobackupex –encrypt=AES256
–encrypt-key=”GCHFLrDFVx6UAsRb88uLVbAVWbK+Yzfs”
/data/backups

优化加密进度

引入多少个新的选项增长速度加密进程,–encrypt-threads和–encrypt-chunk-size

–encrypt-threads选项并行加密,–encrypt-chunk-size钦点每一种加密线程buffer的轻重缓急(字节,暗中认可64K)

解密加密备份

可透过xbcrypt二进制解密,以下一行解密全部目录:

for i in ‘find . -iname “*\.xbcrypt”‘; do xbcrypt -d
–encrypt-key-file=/root/secret_key –encrypt-

prepare加密备份

在备份解密之后,能够因而full
backup一样的不二法门通过–apply-logs prepare

innobackupex –apply-log
/data/backups/2016-03-14_08-31-35/

在意,xtrabackup不会自行移除加密文书,为了清理Backup目录,必要用户手动rm
*.xbcrypt文件

光复加密备份

–copy-back选项,通过拷贝文件到datadir目录还原备份

innobackupex –copy-back
/path/to/BACKUP-DIR

高级天性

流式和压缩备份

streaming格局,发送backup以tar或然xbstream格式到专业输出,取代拷贝文件到backup目录,那样允许你使用其余程序过滤bakcup的出口提供更灵敏的备份,比如,通过管道将backup的输出压缩工具进行压缩,流式备份在那之中的一项好处是是因此unix管道备份能够活动加密

采纳streaming本性,须求利用–stream选项并提供stream的格式(tar可能stream),和在哪个地方存权且文件

innobackpex –stream=tar /tmp

innobackup以–log-stream形式在子进度中运营xtrabackup,并且重定向日志到一时半刻文件,之后采用xbstream以异样的xbstream格式将持有数据文件stream到标准输出。

翻开压缩时,xtrabakup以钦命的压缩算法,压缩全部数据,除了元数据和非innodb文件等不被压缩文件,如今算法只协助quicklz。结果文件为qpress归档文件

使用xbstream作为stream选项,备份能够相互拷贝和压缩,大大的加快了备份进度,以预防范份同时削减和加密。必要首先先解密之后再解压缩

使用xbstream栗子

仓库储存完整备份到单一文件

innobackupex –stream=xbstream /root/backup/ >
/root/backup/backup.xbtream

stream并且压缩那些备份:

innobackupex –stream=xbstream –compress /root/backup/
> /root/backup/backup.xbstream

解包到/root/backup/目录:

xbstream -x < backup.xbstream -C /root/backup/

将压缩backup发送到此外host并解压缩:

innobackupex –compress –stream=xbstream /root/backup/ | ssh
user@otherhost “xbstream -x -C /root/

使用tar的栗子

将全部的backup存到三个tar归档

innobackupex –stream=tar /root/backup/ >
/root/backup/out.tar

将tar归档发送到其他host

innobackupex –stream=tar ./ | ssh user@destination \
“cat – > /data/backups/backup.tar”

留意提取percona xtrabackup归档必要钦定-i选项

tar -xizf backup.tar.gz

可钦命喜欢的压缩工具:

innobackupex –stream=tar ./ | gzip – >
backup.tar.gz
innobackupex –stream=tar ./ | bzip2 – >
backup.tar.bz2

亟需小心的是,流式备份要求在平复在此以前Prepare,流情势不要求prepare

复制环境中备份

从库备份需求内定以下选项:

  • –slave-info选项
    从库备份,它会打字与印刷binlog的点位,还有主库的名字,同样会将这一个音信座位change
    master语句写入xtrabckup_slave_info文件
    利用情状,能够透过那一个备份搭建2个开立这些主库的从库。
  • –safe-slave-backup
    为确认保证一致性复制状态,那几个选项结束SQL线程并且等到show
    status中的slave_open_temp_tables为0的时候开端备份,假使没有打开一时表,bakcup会霎时先河,不然SQL线程运维或然关闭知道没有打开的权且表。假使slave_open_temp_tables在–safe-slave-backup-timeount(暗中同意300秒)秒未来不为0,从库sql线程会在备份完结的时候重启
    强烈推荐

加快备份进程

  • 通过–parallel拷贝和-compress-threads加速当进行地面备份可能经过xbstream选项流式备份时,能够透过–parallel选项多少个文本出现拷贝,那一个选项钦命xtrabackup创建生成的线程数来拷贝数据文件
    前提要求打开innodb_file_per_table和共享表空间存在多少个ibdata文件中,此性情实施级别为文件级别,在高碎片化的数据文件做并发文件转换会大增IO负载,因为极大的随机读请求重叠,你可以设想对文件系统调优以得到最大的天性假诺数额存到单一文件中,这些选项没有任何影响。使用办法: 本地:  innobackupex –parallel=4 /path/to/backup  如若采纳xbstream在流式备份中能够透过–compress-threads选项增长速度削减进程。那一个选项钦赐了由并行数据压缩中xtrabackup制造的线程数,默许值为1
    选用这些性子,只需加上该选项 innobackupex
    –stream=xbstream –compress –compress-threads=4 ./ >
    backup.xbstream 

在applying log以前,压缩文件供给被解压缩

  • 通过–rsync选项增速

为了加快备份过程,同时减小FLUSH TBALES WITH READ
LOCAK阻塞写的时间,当该接纳钦点时,innobackupex使用rsync拷贝全数的非InnoDB文件替换cp。尤其适用于有大批量的库和表的时候会更快。innobackup会调用rsync三次。一 、执行flush
tables with read
lock以前;贰 、裁减读锁被抱有的时光内。因为第①调用在刷新读锁从前,所以它只是一起那个非事务的数指标更动

(它不可能和–remote-host、–stream一起使用)

节流(Throttling)备份

纵然innobackupex不会堵塞任何数据库的操作,不过备份那一个历程会给系统扩展Load,要是系统绝非越来越多的IO能力,那么能够限制innoabckupex读写Innodb数据的频率,通过–throttle选项决定

该选取直接传给xtrabackup二进制造进度序,并仅限制了innodb表的日记和文书操作的

iostat命令能够检查系统上IO操作,

在意innobackup
–throttle选项只在备份阶段工作,innobackupex –apply-log and
innobackupex –copy-back并不办事

–throttle选项很像mysqlbackup中的–sleep选项

卷土重来单表

早于5.6b版本,是非常小概在server中间拷贝文件来拷贝表。但是通过Xtrabackup,你能够别的innodb数据库中间导出单个表,并且把它们导入到MySQL5.6中(source不肯定是MySQL5.6,但是destination必须是),并且只对独立ibd文件有效

导出表

exporting不是在创立backup的时候,而是在prepare阶段完结,一旦full
backup建好,用–export选项prepare它

innobackupex –apply-log –export
/path/to/backup

会为每一种有独立表空间的Innodb创造2个.exp扩大的文件。

举个栗子:

find /data/backups/mysql/ -name export_test.*
/data/backups/mysql/test/export_test.exp
/data/backups/mysql/test/export_test.ibd
/data/backups/mysql/test/export_test.cfg

有五个文本须要导入线上5.6的表中

MySQL通过dump成一种尤其格式的的Innodb字典的.cfg文件,这种格式不相同于.exp。严谨来说,.cfg文件不需要导入mysql5.6表空间。表空间即便从分裂的server上也会导入成功。假诺相关的.cfg文件在相同的目录中,innodb会做schema验证

各类.exp(只怕.cfg)用来导入表

留神:innodb 慢停实例(full purge+change buffer
merge)通过on
–export,不然表空间会区别等并且不会被导入。全体科普的性质难点会被考虑:丰盛的buffer
pool(例如–use-memory,暗中同意100M)和丰裕的蕴藏,不然将会花费很久实现导出

导入表

将一张表导入到其他服务器上,首先以同一的表结构创造一张新表用于导入:

OTHERSERVER|mysql> CREATE TABLE mytable (…)
ENGINE=InnoDB;

下一场遗弃表空间:

OTHERSERVER|mysql> ALTER TABLE mydatabase.mytable
DISCARD TABLESPACE;

然后,拷贝mytable.ibd和mytable.exp(假若导入到5.6则是mytable.cfg)到数据库家目录,然后导入表空间:

OTHERSERVER|mysql> ALTER TABLE mydatabase.mytable
IMPORT TABLESPACE;

假设推行到位。导入表的书库是即时可用的

据悉时间点过来

经过innobackupex和二进制日志可还原内定时间点的数量

留意二进制日志包蕴从过去的叁个小时点起来数据库的变动操作,你供给1个full
datadir作为base,然后能够从二进制日志中apply一一日千里的操作使数据匹配你想要的老大时间点的操作

做一份snapshot,我们能够透过innobackupex做一份全备full
backup

innobackupex /path/to/backup –no-timestamp

鉴于方便使用–no-timestamp选项。之后我们开端prepare,为了未来做好苏醒的准备

innobackupex –apply-log /path/to/bakcup

今日,如果过去了一段时间,你指望苏醒数据库到千古的某部特定点,想下制作快速照相时点的限量

想要找出二进制日志景况,执行show binary logs和show
master status

接下来找出快速照相生成时候的pos点。找到backup目录下的xtrabackup_binlog_info

cat /path/to/backup/xtrabackup_binlog_info
mysql-bin.000003 57

那会告诉备份的时间点的binlog日志及Pos点,这些pos点在平复备份时候尤其有效

innobackupex –copy-back /path/to/backup

下一步正是从二进制日志中用mysqlbinlog从快速照相的pos点初步提前查询语句不分厚薄定向到贰个文件中

mysqlbinlog /path/to/datadir/mysql-bin.000003
/path/to/datadir/mysql-bin.000004 –start-position=57 >
mybinlog.sql

只顾假诺有多个binlog,须求列出全数

整日观看来控制哪些POS点或然时间点是你要还原的不胜点。一旦决定好了。管道传向server,假若时间点是11-12-25
01:00:00:

mysqlbinlog /path/to/datadir/mysql-bin.000003
/path/to/datadir/mysql-bin.000004 \
–start-position=57 –stop-datetime=”11-12-25 01:00:00″
| mysql -u root -p

提升FLUSH TABLES WITH READ LOCKING handling

备份时,FLUSH TABLES WITH READ
LOCK会在备份非innodb文件在此以前运用来有限帮助备份的一致性,FLUSH TABLES WITH
READ
LOCK甚至有查询执行了多少个小时的时候还是可以够运作,那种景观下,任何都会锁在Waiting
for table flush or Waiting for master to send
event那三种情况下,kill掉也不化解任何难题。唯有kill掉导致FLUSH锁住的慢查才能让server重元辰常运转。那就代表一旦长日子运作的询问时,FLUSH
TABLES WITH READ LOCK会被堵塞,

留意,上述情状在backup locks是不行的,Percona Server
5.6+中天性,XtraBackup会自动拷贝非Innodb数据幸免阻塞修改InnoDB表的DML查询

两件事足以幸免上述难题:

innobackupex 等待好机会

innobackupex
能够Kill阻止得到全局锁的询问(全数大概仅select查询)

伺机查询达成

获得全局锁的好机遇是指具有长查询都施行完毕,为防备innobackupex等待执行LUSH太长时间。新选项被引入:

innobakcupex
–ftwrl-wait-timeout选项,限制等待时间,一旦过期就会报错退出。私下认可值为0,关闭此特性

另五个是安装等待查询的项目,innobackupex
–ftwrl-sait-query-type,可选址为all和update,设置为all时,innobackupex会在推行FLUSH
TABLES WITH READ
LOCK以前等待全数长时查询完结(执行时间超越innobackupex–ftwrl-wait-threshold),当班值日为update时会等待UPDATE/ALTE奥迪Q7/REPLACE/INSEKugaT查询达成

–lock-wait-threshold用来定义
–locl-wait-query-type中的长运行查询,借使当先–lock-wait-threshold都算长运营查询。

kill掉阻塞查询

能够通过点名–kill-long-queries-timeout用来钦定执行FLUSH
TABLES WITH READ
LOCK后还足以推行的大运,0为不kill,–kill-long-query-type用来钦点超时过后,kill的查询类型,能够是all可能select

innobackupex –lock-wait-threshold=40
–lock-wait-query-type=all –lock-wait-timeout=180
–kill-long-queries-timeout=20 –kill-long-query-type=all
/data/backups/

innobacupex开支不超越3分钟时间等待抢先40秒的查询完结,FLUSH之后,innobackupex会等待20秒时间获得全局锁,尽管超越20秒还是没有取得,会kill全数的运作时刻当先FLUSH命令的询问

innobackupex是何许做事的

2.3起innobackupex用c重写并且作为xtrabackup的号子连接,innobackupex扶助2.2本子的具有本性和语法。但是以往已降级并且在下三个major版本少校被移除,。新的特色语法将加在xtrabakup中,而不是innobackupex中

making a backup

假使没有格局内定,innobakucpex暗许为backup方式

暗中同意的,innobackupex通过–suspend-at-end选项运行xtrabackup,并且让它拷贝innodb数据文件,当xtrabackup完毕,innobackupex看着它创立xtarbackup_suspended_2文件同时实施FLUSH
TABLES WITH READ LOCK.

innoabackupex之后检查MySQL变量来决定server帮助什么特色,特别是backup
locks,change page bitmaps,GTID
mode等等,若是一切顺遂,二进制作为三个子进度运行

innobackupex在安装–safe-slave-backup选项后拭目以待同步,并且flush全部表with
read lock.阻止全体myisam表写入(除非钦命–mo-lock)。

设若成功,开头备份全部非Innodb文件,.frm,.MCRUISERG,.MYD,.MYI,.CSV,.OPT文件等等

当有着文件备份后,执行ibbackup并且等待直到完结备份完结拷贝事务达成。之后,表被解锁,开启联合(假诺钦赐–safe-slave-backup)并且与server的连接关闭。之后,移除xtrabackup_suspended_2文本并同意xtrabackup退出

并且在备份的目录创制如下文件:

xtrabackcup_checkpoints 包蕴备份类型和LSN

xtrabackcup_binlog_info
包括开启备份时刻的binlog和POS

xtrabackcup_binlog_pos_innodb
包蕴早先备份InnoDB事务相关的binlog的POS

xtrabackup_slave_info
包含master的binlog和POS(需指定–slave-info)

backup-my.cnf 备份必要的my.cnf中的选项

xtrabackup_binary 包罗backup供给的二进制文件

mysql-stderr

mysql-stdout

末段binlog
pos打字与印刷在行业内部错误输出并且Innobackupex退出码为0退出

由此备份还原

平复备份通过–copy-back选项

innobackupex读取my.cnf中的变量并检查相关目录是不是留存

以后拷贝MyISAM表,索引等等。首先是innodb表其次索引,最后是log文件。拷贝时保留文件属性。

作为替换,–move-back选项用来还原备份。这几个选项与–copy-back相似。唯一的区分是它不拷贝文件,而是移动文件到指标地。这几个选项移除backup文件,用时候必须小心。使用境况:没有丰富的磁盘空间同事保留数据文件和Backup副本

innobackupex 命令行选项

选项

  • –apply-log 
    通过apply名叫xtrabackup_logfile的事情日志来在BACKUP-DIRAV4目录中Prepare二个backup,同样,创制新的事体日志。innodb配置从生成bakcup进度中innobakcupex成立的backup-my.cnf文件读取,innobackupex
    –apply-log
    暗许使用bakcup-my.cnf中的innodb配置.那里说的Innodb配置指的是潜移默化多少格式的系统变量,例如:innodb_page_size,innodb_log_block_size等等,本地相关变量例如innodb_log_group_home_dir或者innodb_data_file_path.
    一般处境下,在备份实现后,数据尚且不能够用来复苏操作,因为备份的多少中或者会含有尚未提交的事体或曾经交付但绝非同步至数据文件中的事务。因而,此时数据文件仍处理不一样状态。“准备”的要害效用正是通过回滚未提交的作业及联合已经交由的业务至数据文件也使得数据文件处于一致性状态。
    对xtrabackup的–prepare参数的包装
  • –backup-locks
    仅匡助percona
    server5.6,假如server不补助,开启不读私人和爆发潜移默化
  • –close-files
    2.2.5引入的新特色
    关门不再访问的文件句柄,那几个选项直接传送给xtrabackup,当xtrabackup打开表空间平日并不关门文件句柄指标是天经地义的拍卖DDL操作。倘诺表空间数据巨大,那是一种可以关闭不再访问的文件句柄的方法。使用该选项有高危机,会有发出不一致备份的或许
  • –compact
    始建一份没有援助索引的严密的备份,该选择直接传送给xtrabackup
  • –compress
    该选取指引xtrabackup压缩innodb数据文件的backup的正片,直接传送给xtrabackup的子进度
  • –compress-threads = #
    该选择钦赐并行压缩的worker线程的数量,直接传送给xtrabackup的子进度
  • –compress-chunk-size = #
    其一选项钦点每种压缩线程的里边worker
    buffer的深浅。单位是字节,私下认可是64K。直接传送给xtrabackup子进度
  • –copy-back
    推行还原操作,从备份目录中近日的一份备份中拷贝全体文件到datadir,innobackupex
    –copy-back选项除非钦命innobackupex
    –force-non-empty-directories选项,否则不会拷贝覆盖全体的文本
  • –databases=LIST
    钦命innoabckupex备份的DB列表,该选取接受三个一个字符串参数可能隐含DB列表的文书的全路径。借使没有点名该选取,全部包涵innodb和myam表的DB会被备份,请确认–databases包罗全数的innodb数据库和表,,以便全部的innodb.frm文件也一样备份,假若列表十分长的话。能够以文件替代
  • –decompress
    解压全部值钱通过–compress选项压缩成的.qp文件。innodbakcupex
    –parallel选项允许两个文件同时解压。为掌握压,qpress工具必须有安装还要访问那个文件的权杖。这几个历程将在同1个职位移除原来的减少/加密文件
  • –decrypt=ENCRYPTION-ALGORITHM
    解密全数以前经过–encrypt选项加密的.xbcrypt文件。–innobackup
    –parallel选项允许同时八个公文解密
  • –defaults-file=[MY.CNF]
    该选拔钦命了从哪个文件读取MySQL配置,必须放在命令行第三个挑选的岗位
  • –defaults-extra-file=[MY.CNF]
    点名了在专业defaults-file在此之前从哪些额外的文书读取MySQL配置,必须在命令行的第3个选项的职分
  • –default-group=GROUP-NAME
    其一选项接受了一个字符串参数钦定读取配置文件的group,在一机多实例的时候须求钦定
  • –encrypt=ENCRYPTION_ALGORITHM
    该选取钦点了xtrabackup通过ENCPAJEROYPTION_ALGOHighlanderITHM的算法加密innodb数据文件的备份拷贝,该接纳直接传送给xtrabackup子进度
  • –encrypt-key=ENCRYPTION_KEY
    辅导xtrabackup使用了–encrypt选项时候利用ENC路虎极光YPTION_KEY那么些KEY,直接传送给xtrabackup子进度
  • –encrypt-key-file=ENCRYPTION_KEY_FILE
    其一选项告诉xtrabackup使用–encrypt的时候。Key存在了ENCKugaYPTION_KEY_FILE这几个文件中
  • –encrypt-chunk-size=#
    以此选项钦赐了各类加密线程内部worker
    buffer的大大小小,单位字节,直接传送给xtrabackup子进程
  • –export=DIRECTORY
    本条选项直接传送给 xtrabackup
    –export选项。开启可导出单身的表之后再导入其余Mysql中
  • –extra-lsndir=DIRECTORY
    这么些选项接受2个字符串参数钦定保存额外一份xtrabackup_checkpoints文件的目录,直接传送给xtrabackup
    –extra-lsndir选项
  • –force-non-empty-directories
    点名该参数时候,使得innobackupex –copy-back或innobackupex
    –move-back选项转移文件到非空目录,已存在的文本不会被覆盖,即便–copy-back和–move-back文件须求从备份目录拷贝四个在datadir已经存在的文件,会报错退步
  • –galera-info
    该选项生成了包涵创立备份时候本地节点状态的文书xtrabackup_galera_info文件,该选拔只适用于备份PXC。
  • –history=NAME
    percona
    server5.6的备份历史记录在percona_schema.xtrabackup_history表
  • –host=HOST
    选料内定了TCP/IP连接的数据库实例IP
  • –ibbackup=IBBACKUP-BINARY
    那几个选项钦点了动用哪个xtrabackup二进制造进程序。IBBACKUP-BINAMuranoY是运作percona
    xtrabackup的一声令下,。这些选项适用于xtrbackup二进制不在你是寻找和做事目录,假设钦命了该选项,innoabackupex自动决定用的二进制造进程序
  • –include=REGEXP
    正则表达式匹配表的名字[db.tb],直接传送给xtrabackup
    –tables选项。
  • –incremental
    这些选项告诉xtrabackup成立三个增量备份,直接传送给xtrabakcup子进度,当那么些选项内定,必要同时钦定–incremental-lisn或然–incremental-basedir。假诺没有点名,暗中同意传给xtrabackup
    –incremental-basedir,值为Backup
    BASE目录中的第3个时间戳目录
  • –incremental-basedir=DIRECTORY
    那些选项接受了一个字符串参数钦定含有full
    backup的目录为增量备份的base目录,与–incremental同时选择
  • –incremental-dir=DIRECTORY
    点名了增量备份的目录,结合full backup生成生成一份新的full
    bakcup
  • –incremettal-history-name=NAME
    本条选项钦定了蕴藏在PEQashqaiCONA_SCHEMA.xtrabackup_history基于增量备份的历史记录的名字。Percona
    Xtrabackup搜索历史表查找目前(innodb_to_lsn)成功备份并且将to_lsn值作为增量备份运维出事lsn.与innobackupex–incremental-history-uuid互斥。假使没有检查和测试到实惠的lsn,xtrabackup会再次来到error
  • –incremetal-history-uuid=UUID
    那些选项钦赐了储存在percona_schema.xtrabackup_history基于增量备份的一定历史记录的UUID
  • –incremental-lsn=LSN
    以此选项钦点增量备份的LSN,与–incremental选项联合利用
  • –kill-long-queries-timeout=SECONDS
    本条选项钦赐innobackupex从开头推行FLUSH TABLES WITH READ
    LOCK到kill掉阻塞它的这一个查询之间等待的秒数,私下认可值为0.以为着Innobakcupex不会kill任何查询,使用这一个选项xtrabackup需求有Process和super权限。
  • –kill-long-query-type=all|select
    指定kill的类型,默认是all
  • –ftwrl-wait-timeout=SECONDS
    履行FLUSH TABLES WITH READ
    LOCK以前,innobackupex等待绿灯查询执行到位等待秒数,超时的时候假使查询还是没有实施完,innobackupex会终止并报错,暗中同意为0,innobakcupex不等待查询实现立即FLUSH
  • –ftwrl-wait-threshold=SECONDS
    点名innoabckupex检测到长查询和 innobackupex
    –ftwrl-wait-timeount不为0,那些长查询能够运行的阈值,
  • –ftwrl-wait-query-type=all|update
    钦命innobakcupex获得全局锁以前允许那种查询达成,暗中同意是ALL
  • –log-copy-interval=#
    那一个选项钦命了历次拷贝log线程实现检查时期的间距(阿秒)
  • –move-back
    从备份目录大校方今一份备份中的全部文件移动到datadir目录中
  • –no-lock
    关门FTW大切诺基L的表锁,唯有在您全体表都以Innodb表并且你不关切backup的binlog
    pos点
    倘使有其余DDL语句正在执行可能非InnoDB正在更新时(包罗mysql库下的表),都不应有选取这一个选项,后果是引致备份数据不一样
    假若考虑备份因为获得锁失利,,能够设想–safe-slave-backup立即终止复制线程
  • –no-timestamp
    本条选项阻止在BACKUP-ROOT-DI奇骏里创建三个岁月戳子目录,钦命了该选用的话,备份在BACKUP-ROOT-DI帕杰罗实现
  • –no-version-check
    本条选项禁用由–version-check打开的version check
  • –parallel=NUMBER-OF-THREADS
    点名xtrabackup并行复制的子进度数。注意是文本级别并行,如若有五个ibd文件,他们会相互拷贝,假使全数的表存在二个表空间文件中,没有任何效能。。直接传送给xtrabakcup
    –parallel选项
  • –password=PASSWORD
  • –port=PORT
  • –rebuild-indexes
    与–apply-log一起用时候才使得。并且一贯传送给xtrabackup,在apply
    log之后重建全部援救索引,该选用用于Prepare紧密备份。
  • –rebuild-threads=NUMBER-OF-THREADS
    与–apply-log和–rebuild-index选项一起用时候才生效,重建索引的时候,xtrabacup以钦赐的线程数并行的处理表空间文件
  • –redo-only
    其一选项在prepare base full
    backup,往里面merge增量备份(但不包含倒数)时候使用。传递给xtrabackup
    –apply-log-only的选项。那么些强制xtrabackup跳过rollback并且只重做redo
  • –rsync 
    因而rsync工具优化地面传输,当钦赐那几个选项,innobackupex使用rsync拷贝非Innodb文件而替换cp,当有这么些DB和表的时候会快很多。不能够–stream一起使用
  • –safe-slave-backup
    钦命的时候innobackupex会在执行FLUSH TABLES WITH READ
    LOCK结束sql线程,并且直到show
    status里slave_open_temp_tables的值为0的时候start
    backup,。如若没有打开的目前表,就从头备份,不然sql线程start恐怕stop直到没有打开的权且表,若是在innobackupex
    –safe-slave-backup-timeout之后slave_open_temp_tables的值仍没有变成0备份就会破产。SQL线程会在backup实现之后重启。
  • –safe-slave-backup-timeout=SECONDS
    innobackupex
    –safe-slave-backup应该等多少秒等slave_open_temp_tables变成0,默认是300秒
  • –scpopt=SCP-OPTIONS
    当–remost-host钦点的时候,钦命传给scp的通令行选项。若是没有点名,暗中认可为-Cp
    -c arcfour
  • –slave-info
    对slave举办备份的时候使用,打字与印刷出master的名字和binlog
    pos,同样将这几个消息以change
    master的指令写入xtrabackup_slave_info文件。能够通过依照那份备份运维3个从库并且保留在xtrabackup_slave_info文件中的binlog
    pos点创设一个新的从库
  • –socket
    老是本地实例的时候使用
  • –sshopt=SSH-OPTIONS
    在钦命了–remost-host的时候,钦命传给ssh的一声令下行选项
  • –stream=STREAMNAME
    流式备份的格式,backup实现现在以钦点格式到STDOUT,近日只支持tar和xbstream。使用xbstream为percona
    xtrabakcup发型版本,假如在这些选项之后内定了路子。会掌握值为tmpdir
  • –tables-file=FILE
    钦定含有表列表的文件,格式为database.table,该选用直接传给xtrabackup’s
    –tables-file
  • –throttle=IOS
    点名每秒IO操作的次数,直接传送给xtrabackup
    –throttle选项。只遵循于bakcup阶段有效。apply-log和–copy-back不见效不要一起用
  • –tmpdir=DIRECTORY
    钦赐–stream的时候,钦定一时半刻文件存在何地,在streaming和拷贝到远程server在此以前,事务日志首先存在一时半刻文件里。
  • –use-memory=#
    不得不和–apply-log选项一起利用,prepare a
    backup的时候,xtrabackup做crash
    recovery分配的内部存款和储蓄器大小,单位字节。也可(1MB,1M,1G,1GB),直接传给xtrabackup
    –use-memory选项
  • –version
    彰显Innobackupex版本和版权新闻后退出
  • –version-check
    innobackupex在与server创造连接之后的备份阶段举办版本检查

Xtrabackup 二进制

get started

配置xtrabackup

xtrabackup读取配置文件中的[mysqld]和[xtrabackup]一部分,读取datardir和innodb选项,能够透过将这么些都钦定在[xtrabackup]部分。越靠后,越优先。

最简易的在[xtrabackup]有的只钦赐target_dir,该选拔钦命backup暗中认可放的目录,例如:

[xtrabackup]

target_dir = /data/backups/mysql

Xtrabackup-FULL BAKCUPS

创建二个备份

运行xtrabackup指定–backup
,–target_dir,–datadir.

一经不钦赐target_dir,xtrabacup会创立它。要是目录存在且为空,xtrabackup会成功,xtrabackup不会覆盖已有文件。会报“file
exist”的错误

其一工具将工作目录转换来datadir,并且实施两项首要的天职:(后台运转的log扫描线程扫描redo
log,ibdata1上的文件拷贝线程)

  • 后台运转二个正片日志的线程,那一个线程关切innodb日志文件,当redo
    log有转变,那么些线程拷贝变化的块到到target目录成为xtrabackup_logfile的文件
  • 拷贝Innodb数据文件到指标目录,那不是个大致拷贝文件那么简单,它像Innodb那样打开读取文件,读取数据字典并且逐一的正片2个page
    当拷贝完数据文件,xtrabackup结束log-copying线程,并在target目录生成包罗了备份类型和始发和末段的lsn号的xtarabckup_checkpoints文件,
    比喻命令如下:

    xtrabakcup –backup –datadir=/data1/mysql/
    –target-dir=/data/backups/

    备份/data1/mysql目录并储存在/data/backups/mysql/。假如您内定1个相对路径,target目录会波及到当前路线
    在备份进程里面,你能来看一大堆输出突显了文件正在拷贝中,同时log
    file线程重复的扫描redo
    log,并且文件拷贝线程将innodb数据文件拷贝到target目录
    最后一件要求关心的事务是,LSN的值在哪个地方成为二个数字操纵于你的系统
    在意:log拷贝线程每秒检查作业日志去看是不是写入了新的日志记录供给拷贝,也有有时的log拷贝线程赶不上海南大学学量的写入事务日志的快慢,redo
    log在被读取在此之前就被覆盖了,就会报错!!!!
    当Backup甘休,target目录包括了:

    /data/backups/ibdata11
    /data/backups/test
    /data/backups/test/tbl1.ibd
    /data/backups/xtrabackup_checkpoints
    /data/backups/xtrabackup_logfile

    备份会持续时间决定于数据库大小,在其他时刻cancel都是安全的,因为它并不转移数据库
    下一步要让backup变为可复原:prepare
    backup

preparing the backup

用–backup生成备份后,下一步正是prepare。数据文件不是岁月点同样的甘休他们被prepare,因为他们在程序运行时不一致时间拷贝,并且发生时曾经变更了,假设你品味用这一个数据文件运行innodb,之后会检查和测试到崩溃,并且crash本人来严防在破坏的数量上百折不回运转。–prepare阶段让那个文件在肆意时间都一致性,所以你能够在地点运维Innodb

小心:innobakcupex –apply-log
自动从bakcup-my.cnf读取innodb配置,或许–defaults-file=bakcup-my.cnf选项传递给xtrabackup。不然会招致不正确还原因为xtrabackup已经用了错误的安插选项

你能够在其余机器上运维Prepare操作,不必要在备份机上大概恢复机上操作,你能够拷贝backup到一台专门的中央控制机并且在prepare

在意:你能够用新本子prepare一个较老版本创立的backup,但反过来不行。在一台不支持的Mysql
server版本上prepare3个bakcup应该用帮忙该server的风行版本,例如,如若通过1.6本子xtrabackup备份mysql5.0,用2.2prepare是不帮忙的。因为2.1本子中移除了5.0

在prepare阶段,xtarbackup嵌入了改动过的innodb,禁止了innodb的反省,比如日志文件大小是或不是可信赖。

prepare阶段正是采纳那几个松手的innodb来做通过日记文件对数据文件举行crash复苏

xtrabackup –prepare —target-dir=/data/backups/mysql

姣好之后,能够观看innodb shutdown的音讯和lsn

您的备份未来是彻底并且相同的了,并且准备好还原,不过,你或然希望额外的步子让还原更快。那亟需首回Prepare。第1次prepare让数据文件完美的一致性。不过不常见新鲜的Innodb日志文件,如果那时还原备份并且运维Mysql,它须求创建新的日志文件,那须求一段时间。你可能不想等待。假若您第一遍运维–prepare,xtrabackup会创制日志文件,redo
log的大小决定于mysql的配置文件

xtrabackup –prepare
–target-dir=/data/backups/mysql/

xtrabackup: This target seems to be already prepared.

xtrabackup: notice: xtrabackup_logfile was already
used to ’–prepare’.

101107 16:54:10 InnoDB: Log file ./ib_logfile0 did not exist: new to be created InnoDB:
Setting log file ./ib_logfile0 size to
<SIZE>
MB

InnoDB: Database physically writes the file full: wait…

101107 16:54:10 InnoDB: Log file ./ib_logfile1 did not exist: new to be created InnoDB:
Setting log file ./ib_logfile1 size to
<SIZE>
MB

InnoDB: Database physically writes the file full: wait…

101107 16:54:15 InnoDB: Shutdown completed; log sequence number 1284108

第2次依然第3遍prepare不会改变一度Prepare的数据文件,你能够看输出:

xtrabackup: This target seems to be already
prepared.
xtrabackup: notice: xtrabackup_logfile was already
used to ’–prepare’.

不推荐prepare的时候抛锚xtrabackup进程,会造成数据文件损坏并且backup不可用,中断prepare进度不有限支撑backup可用性

假如以后会拿这份那份backup作为基础而进展增量备份,prepare的时候要采取–apply-log-only选项,不然你不能apply增量备份到那份basic全备。

还原全备

xtrabackup没有过来备份的效益。由用户来做,你能够经过rsync或许cp来还原,你应当检查还原文件有不利的属主和权杖

小心:datadir在平复备份从前务必为空,同样相当重要的是Mysql
server要求苏醒从前shutdown,你无法在Mysql运营时还原到datadir目录(除非是导入部分备份)

rsync命令还原:

rsync -avrP /data1/backup/ /data1/mysql

文件属性保留,当先一半景况下必要在启动实例以前改变文件的属主

chown -R mysql5711:mysql /data1/mysql5711

专注,xtrabackup只备份Innodb数据,你不可能不独立还原mysql系统库,myisam数据,表定义文件。或然innobakcupex

其他门类备份

增量备份

xtrabackup和Innobacupex都扶助增量备份,意味着能够只拷贝自从上次全备之后变化的多少,你能够在各种full
backup之间做过多份增量备份,那样您能够做那样一个备份程序一周做2遍full
backup天天一遍增量,可能一天做一回full backup每小时做二次增量

增量备份原理,每一个Innodb页都有两个LSN号,一份增量备份拷贝各样比上次增量备份大概全备LSN更新的page。

有八个算法能够找到那样的急需拷贝的Page的聚集

  • 对此全体server和本子可用,通过读取全部的数码页检查page的LSN
  • 仅对Percona Server适用,忽略

增量备份不会不会实际的和上次的备份相比数据文件。你只要驾驭LSN的话甚至在未曾从前备份的动静下使用通过–incremental-lsn执行二遍增量备份。增量备份不难的读取page并且相比较他们的LSN与上次备份的LSN。然则你照样须要三个full
bakcup来复苏增量的转移。假使没有1个full
bakcup作为三个base,增量备份是不曾用的

成立一份增量备份

开创一份增量备份,供给从1个full
backup伊始,xtrabakcup写一个叫xtrabackup_checkporints的公文到备份指标目录,那个文件包蕴一行彰显to_lsn(backup甘休时候的lsn)

xtrabackup –backup –target-dir=/data/backups/base
–datadir=/data1/mysql5711

xtrabakcup_checkpoints文件包涵

backup_type = full-bakcuped
from_lsn =0
to_lsn =1291135

基于这么些full backup创立一份增量:

xtrabackup –backup –target-dir=/data/backups/inc1
–incremental-basedir=/data/backups/base –datadir=/data1/mysql5711

/data/backup/inc1/目录包蕴了增量的公文,比如ibdata1.delta和test/table1.idb.delta
,代表了从LSN1291135以来的变迁,要是检查那几个目录的xtrabacup_checkpoints文件,会看见如下:

bacup_type = incremental
from_lsn = 1291135
to_lsn = 1291340

明天能够拿inc1看成接下去增量备份的base目录:

xtrabackup –backup –target-dir=/data/backups/inc2
–incremental-basedir=/data/backups/inc1
–datadir=/data1/mysql5711/

prepare增量备份

增量备份的–prepare阶段与常规备份分裂,在例行备份中,执行三种类型操作来保管数据库一致性,已交付的事务会在数据文件中重放,未提交的政工回滚,prepare备份的时候你需求跳过未提交业务的回滚,因为在备份的卓殊时刻未提交的业务正在拓展中,并且众人周知的它们会在下次增量备份的交付。你须求使用–apply-log-only选项来阻拦回滚阶段

即便您不要–apply-log-only选项阻止回滚,那么以往的增量备份就没用了。事务若是被回滚,那之后的增量备份就不能够被重播

从您从头创设的full
backup,你能够Prepare它,之后回放增量的界别,纪念您早就有如下备份base/,inc1/,inc2/

prepare base备份,然后阻止回滚:

xtrabackup –prepare –apply-log-only
–target-dir=/data/backups/base

出口呈现lsn为1291135.

备份假诺今日还原是13分安全的,甚至回滚的步子被跳过了,倘若您未来回复并运行MySQL,InnoDB会检查和测试到回滚没有实行,之后再在后台举办初阶crash复苏,通告你多少没有被符合规律关闭

重播第3个增量备份给full backup:

xtrabackup –prepare –apply-log-only
–target-dir=/data/backups/base
–incremental-dir=/data/backups/inc1

那般给/data/backups/base目录重放delta文件。将备份的日子发展到增量备份的时间点,之后照常重播事务日志,最后数额是在/data/backups/base并不在增量目录里.

来得如下:

incremental backup from 1291135 is enabled.
xtrabackup: cd to /data/backups/base/
xtrabackup: This target seems to be already
prepared.
xtrabackup: xtrabackup_logfile detected: size=2097152,
start_lsn=(1291340)
Applying /data/backups/inc1/ibdata1.delta …
Applying /data/backups/inc1/test/table1.ibd.delta

…. snip
101107 20:56:30 InnoDB: Shutdown completed; log
sequence number 1291340

万一经过/data/backups/base目录还原,你能够望见数据库的情况是第二次备份时的状态

prepare第③次增量备份以平等的步子,apply增量到上步的base,将数据的时光点一块到第二遍增量备份的年华点

xtrabackup –prepare –target-dir=/data/backups/base
–incremental-dir=/data/backups/inc2

–apply-log-only用在merging全数增量除最终三个。最终一步还能够用,备份最后也是直接的只是server不会执行回滚步骤

一对备份

内需敞开innodb_file_per_table,有两种艺术协理部分备份

瞩目:若是其它匹配的或然列入的表在备份时期删除,xtrabackup会失利

  • 使用–tables选项匹配databasename.tablename  xtrabackup –backup –datadir=/data1/mysql5711
    –target-dir=/data/backups/ –tables=”^test[.].*”  备份整个test库
  • 使用–tables-file选项
  • 使用 –databases 和 –databases-file选项 ####
    prepare 部分备份
    会用–prepare选项举办一些备份的时候,你相会到有关表不设有的告警,原因是这一个表存在于InnoDB的数额字典中可是相应的.ibd文件不设有,他们没有被拷贝到备份目录中去,那一个表将会从数额字典中移除,然而当您回复备份并且运转InnoDB的时候,他们讲不会存在并在日记文件中报错

削减备份

不带有支持索引页,占用更少磁盘空间,缺点是prepare的时间更长因为供给重建支持索引

留意:压缩备份不辅助系统表空间,所以理应开辟innodb-file-per-table选项

创建压缩备份

通过–compact选项

xtrabackup –bakcup –compact
–target-dir=/data/backups

检查target-dir目录下的xtrabackup-checkpoints文件。如下:

backup_type = full-backuped
from_lsn = 0
to_lsn = 2888984349
last_lsn = 2888984349
compact = 1

假如不选择–compact的话–value的值为0,那些办法能够急忙检查和测试备份是或不是含有协助索引页

prepare 压缩备份

透过–rebuild-indexes和–apply-logs一起使用

xtrabackup –prepare –rebuild-indexes
/data/backups

通过–rebuild-threads选项多线程重建索引

xtrabackup –prepare –rebuild-indexes
–rebuild-threads=16 /data/backups/

复原压缩备份

未曾现成工具,可以透过rsync或然cp完成,须求检讨还原文件是还是不是有不易权限

高级本性:

throttling备份

xtrabackup不会堵塞数据库读写,backup扩大系统压力,能够经过–throttle选项,这一个选项限制IO操作的多寡为每秒每MB

在–backup格局,这一个选项限制了xtrabackup每秒执行的对(read和write)。即使您创造3个增量备份。然后限制每秒读IO的多少

私下认可,no
throttling,xtrabackup最快的读写数据,假若您IO限制过于严刻,备份会相当的慢并且追不上innodb写作业日志的速度,备份将永久不或然做到

编纂备份脚本

suspending after copying

在备份格局中,xtarbackup在后台拷贝日志文件,前端线程拷贝数据文件,,之后甘休日志线程并形成。如果您使用–suspend-at-end选项而不是终止日志线程并完成。xtrabacup会继续拷贝日志文件,并在target目录生成一个xtrabackup_suspended文件,之后要那一个文件存在,xtrabackup会继续考察事务日志并把她们拷贝到target目录中xtrabackup_logfile文件。当那一个文件移除的时候,xtrabackup会停止拷贝事务日志并退出

该效率协调备份Innodb数据和其余动作时那贰个有用,最显然的是拷贝表定义文件(.frm)以便备份能被还原,你可以后台运维xtrabakcup,等待xtrabackup_suspended文件被创制,然后拷贝所有你必要达成这么些备份的其他公文。。那些正是innobakcupex工具做的行事

生成元数据

备份包涵其余你须求还原备份时候供给的音信是个好主意,xtarbackup能打字与印刷my.cnf文件中必要还原的数量和日志文件的剧情,假设扩充–print-param选项。会打字与印刷如下内容:

“`

This MySQL options file was generated by
XtraBackup.

[mysqld]

datadir = /data/mysql/

innodb_data_home_dir = /data/innodb/

innodb_data_file_path =
ibdata1:10M:autoextend

innodb_log_group_home_dir =
/data/innodb-logs/

“`

能够重定向输出到backup的target目录

协商source目录

布置文件大概其他因素会促成xtrabackup从区其他任务备份数据。为了防范那一个,你能够用–print-param来查找从哪个地方copy数据。你能够用输出来保险xtrabackup和你的脚本处理同样的数据集

log streaming

能够透过–log-stream 让xtrabackup将redo
log文件streaming而不是拷贝,那样会自动添加–suspend-at-end选项。你的剧本能够进行

stream远程备份并由此管道将log文件传给ssh并且经过rsync只怕xbstream等工具将数据拷贝到远程服务器上

浅析表总计音信

xtrabackup以只读情势分析InnoDB数据文件并提供给计算。可以透过–stats选项。能够同–ables选项一起使用范围检查的的公文。还有–use-memory选项。

你能够在一台运维实例的机械上推行分析,在条分缕析时期数据变动会有疏失的可能率。大概能够分析备份的正片。假如急需使用总括的风味,你必要1个到底的正片包蕴科学的Logfile大小,,所以你要求在贰遍备份上实施–prepare三回

使用binlog

xtrabakcup提取了innodb事务日志关于对应已交由业务的binlog
pos,这么些能够打字与印刷出backup对应的binlog
pos,你能够经过搭建一些列从库恐怕拓展基于时间点的复原

找到binlog pos

一旦backup prepare之后您能够找到binlog
pos,通过运转xtrabakcup –prepare可能innobackupex
–apply-log都能够做到。若是bakcup是源于打开binlog的实例。xtrabackup会在target目录创设二个xtrabakcup_binglog_info的公文。这几个文件包括了与prepare对应的binlog名字和pos点位

输出的消息在xtrabakcup_binlog_pos_info文件中找到,唯有应用innodb引擎才会规范

别的电动机,比如myisam,你应当使用xtrabackup_binlog_info文件得到地方

依据时间点过来

从一份xtrabackup的备份里基于时间点的上升,你须求prepare并且恢复备份,之后重播xtrabackup_binlog_info中记录的点开首的binlog

搭建八个新的从库

亟需先prepare,然后在新从库的data目录中回复,之后采用change
master
to命令,使用xtrabackup_binlog_info文件的binlog和pos运行复制

复原单独表

在5.6本子从前,就算打开innodb_file_per_table选项,依然不容许通过在实例之间通过拷贝文件来拷贝表。然则,通过Xtrabackup你可以从此外InnoDB数据库中程导弹出单表,并且导入到5.6中去(source不必是5.6可是destination必须是!!!!!)只在独立.ibd文件生效,假如没有独立ibd文件是不可见导出单表的!!!!!

导出单表

其一表必须在开辟innodb_file_per_table形式下创设。所以在在–bakcup创制一份备份之后,.ibd文件应当早就存在于target目录中

当你prepare的时候,要求额外加–export命令:

xtrabacup –prepare –export
–target-dir=/data/backups/mysql5711

今昔你能够在target目录找到.exp文件

$ find /data/backups/mysql5711/ -name
export_test.*
/data/backups/mysql5711/test/export_test.exp
/data/backups/mysql5711/test/export_test.ibd
/data/backups/mysql711/test/export_test.cfg

那多个公文是您将表导入5.6的具备文件

表明:mysql使用cfg文件,那几个文件包括了Innodb字典dump。那种格式分歧于xtrabDB的.exp文件。严苛来讲,.cfg文件在5.6以及后来是不在需求的。假设存在cfg文件,那么Innodb会通过cfg文件做schema验证

导入表

在5.6,以平等表结构创建一张表,然后实施以下步骤:

  • 执行alter table test.export_test discard
    tablespace;需求开拓innodb_file_per_table
  • 拷贝以前导出到文件指标服务器的数量目录test/子目录
  • 执行alter table test.export_test import
    tablespace; 那张表未来已经导入,你能够经过select命令查看导入数据
    ### LRU dump备份
    那个特点减少了通过在实例重启之后从ib_lru_dump文件还原buffer
    pool状态的预热时间。xtrabakcup自动发现ib_lru_dump并且自动备份
    借使my.cnf中开启buffer还原摘取,buffer
    pool会在从备份还原之后自动预热。只在Percona
    server中有那些选项。mysql没有

实施

xtrabakcup的限制

有以下必要注意:

*
如果xtrabakcup_logfile当先4G,三十二人系统上的xtrabakcup在–prepare阶段会破产

* xtrabackup在率先次–prepare的不会转移新的redo
log文件,必须–prepare三遍,在其次次的时候才会转变

* 不援救my.cnf里有–set-variable那种格式设置

履行细节

文件权限

xtrabacup以读写情势打开源数据文件,但不更改那几个文件,意味着你必须以有写这么些文件权限的用户来运营xtrabackup。以读写情势打开文件的原委是xtrabakcup使用内置的Innodb库来开辟读写文件,并且Innodb以读写方式打开因为健康假诺是亟需写那一个文件了

调整os buffers

因为xtrabackup读取文件系统的雅量数额,大概它利用posix_fadvise()指点操作系统不要品味缓存从磁盘读取的block。没有这几个提示。假使xtrabackup相当的慢再一次索要那一个块,操作系统更愿意缓存那个块。缓存如此大的文书会给操作系统的虚拟内部存款和储蓄器增添压力并到底其他进程,比如数据库swap
out。xtrabakcup工具通过source和destination如下提示来幸免那种意况时有产生:

posix_fadvise(file,0,0,POSIX_FADV_DONTNEED)

此外,xtrabackup让操作系统在源文件上来执行更挑战性的read-ahead优化

posix_fadvise(file, 0, 0,
POSIX_FADV_SEQUENTIAL)

拷贝数据文件

当向target目录拷贝数据文件的时候,xtrabakcup二回读写1MB数据。那是不足配置的。当拷贝事务日志,xtrabackup2次读写512字节。着同样不可能配备。是适合Innodb的(percona
server的化解办法是有至极的参数innodb_log_block_size)

读取文件从此,xtrabackup1回1MBbuffer遍历page。并通过innodb
buf_page_is
corrupted()函数检查每种Page的corruption。假如page损坏,便会重读并且每一种page重试十一次,3次写buffer会跳过那几个检查

手册

xtrabackup选项

选项

  • –apply-log-only 
    prepare备份的时候只进行redo阶段,对增量备份分外主要
  • –backup
    创建备份并且放入–target-dir目录中
  • –close-files
    不保证文件打开状态,xtrabackup打开表空间的时候一般不会倒闭文件句柄指标是为了正确处理DDL操作。不过,要是表空间数据尤其巨大并且不合乎任何限制,一旦文件不在被访问的时候那几个选项能够关闭文件句柄.打开那几个选项会时有发生不雷同的备份。本人评估风险。。
  • –compact
    始建一份没有帮忙索引的紧凑备份
  • –compress
    缩减全数出口数据,包含工作日志文件和元数据文件,通过点名的压缩算法,近期唯一援救的算法是quicklz.结果文件是qpress归档格式,每种xtrabackup制造的*.qp文件都能够通过qpress程序领取恐怕解压缩
  • –compress-chunk-size=#
    压缩线程工作buffer的字节大小,暗中认可是64K
  • –compress-threads=#
    xtrabackup实行互动数据压缩时的worker线程的数码,该选项暗中同意值是1,并行压缩(’compress-threads’)能够和交互文件拷贝(‘parallel’)一起利用。例如:’–parallel=4
    –compress
    –compress-threads=2’会创制陆个IO线程读取数据并透过管道传送给二个减弱线程
  • –create-ib-logfile
    以此选项如今还平昔不兑现,方今开立Innodb事务日志,你如故须要prepare一回bakcup
  • –datadir=DIRECTORY
    backup的源目录,mysql实例的数目目录。从my.cnf中读取,或然命令行钦定
  • –defaults-extra-file=[MY.CNF]
    在global files文件从此读取,必须在命令行的首先挑选地方钦定
  • –defaults-file=[MY.CNF]
    唯一从给定文件读取私下认可选项,必须是个诚实文件,必须在命令行第3个选项地点钦命
  • –defaults-group=GROUP-NAME
    从布局文件读取的组,innobakcupex四个实例计划时使用
  • –export
    为导出的表成立须求的文本
  • –extra-lsndir=DIRECTORY
    (for
    –bakcup):在钦定目录创造一份xtrabakcup_checkpoints文件的额外的备份
  • –incremental-basedir=DIRECTORY
    开创一份增量备份时,这么些目录是增量别分的一份包罗了full
    bakcup的Base数据集
  • –incremental-dir=DIRECTORY
    prepare增量备份的时候,增量备份在DIRECTOHavalY结合full
    backup成立出一份新的full backup
  • –incremental-force-scan
    创立一份增量备份时,强制扫描全部增在备份中的数据页尽管完全改观的page
    bitmap数据可用
  • –incremetal-lsn=LSN
    始建增量备份的时候钦点lsn。
  • –innodb-log-arch-dir
    点名包括归档日志的目录。只好和xtrabackup
    –prepare选项联合行使
  • –innodb-miscellaneous
    从My.cnf文件读取的一组Innodb选项。以便xtrabackup以同一的布局运转松开的Innodb。平日不必要显示钦点
  • –log-copy-interval=#
    本条选项内定了log拷贝线程check的日子间隔(暗中认可1秒)
  • –log-stream
    xtrabakcup不拷贝数据文件,将事情日志内容重定向到正式输出直到–suspend-at-end文件被去除。这几个选项自动开启–suspend-at-end
  • –no-defaults
    不从其他选取文件中读取任何默许选项,必须在命令行第多少个选项
  • –databases=#
    钦点了索要备份的数据库和表
  • –database-file=#
    点名包涵数据库和表的文件格式为databasename1.tablename1为三个成分,三个成分一行
  • –parallel=#
    点名备份时拷贝多少个数据文件并发的历程数,暗中同意值为1
  • –prepare
    xtrabackup在一份通过–backup生成的备份执行还原操作,以便准备利用
  • –print-default
    打字与印刷程序参数列表并退出,必须放在命令行第几人
  • –print-param
    使xtrabackup打字与印刷参数用来将数据文件拷贝到datadir并上涨它们
  • –rebuild_indexes
    在apply事务日志之后重建innodb支持索引,唯有和–prepare一起才生效
  • –rebuild_threads=#
    在严密备份重建帮助索引的线程数,唯有和–prepare和rebuild-index一起才生效
  • –stats
    xtrabakcup扫描钦点数据文件并打字与印刷出索引总括
  • –stream=name
    将拥有备份文件以内定格式流向标准输出,近年来支撑的格式有xbstream和tar
  • –suspend-at-end
    使xtrabackup在–target-dir目录中生成xtrabakcup_suspended文件。在拷贝数据文件之后xtrabackup不是退出而是继续拷贝日志文件同时等待知道xtrabakcup_suspended文件被删除。那项能够使xtrabackup和其他程序协同工作
  • –tables=name
    正则表达式匹配database.tablename。备份匹配的表
  • –tables-file=name
    钦定文件,三个表名一行
  • –target-dir=DIRECTORY
    点名backup的目标地,要是目录不设有,xtrabakcup会成立。要是目录存在且为空则成功。不会覆盖已存在的公文
  • –throttle=#
    钦赐每秒操作读写对的数额
  • –tmpdir=name
    当使用–print-param钦点的时候打字与印刷出正确的tmpdir参数,除此之外没有其它用。。
  • –to-archived-lsn=LSN
    点名prepare备份时apply事务日志的LSN,只好和xtarbackup
    –prepare选项联合用
  • –user-memory = #
    因而–prepare
    prepare备份时候分配多大内部存款和储蓄器,目标像innodb_buffer_pool_size。暗中同意值100M假如您有丰硕大的内部存款和储蓄器。1-2G是推荐值,补助各类单位(1MB,1M,1GB,1G)
  • –version
    打字与印刷xtrabackup版本并脱离

xbstream

帮助同时削减和流式化。要求客服守旧归档tar,cpio和任何不容许动态streaming生成的文件的限制,例如动态压缩文件,xbstream当先其他古板流式/归档格式的的独到之处是,并发stream多少个文件同时更紧密的数量存款和储蓄(所以能够和–parallel选项选项一起行使xbstream格式举行streaming)

像tar一样使用:

* -x 选项 从规范输入stream
read中领到文件到当前目录,除非钦命其他-C选项

* -c 选项 stream命令行内定的文本到标准输出

目的,通过posix_fadvise()调用减弱对OS page
cache的影响

xtrabackup开启压缩的时候根本数据被缩减,包罗工作日志和元数据文件,通过点名的压缩算法,唯一当前支撑度呃算法是quicklz,结果文件是qpress归档个事。每隔xtrabakcup生成的.qp文件能够经过qpress文件归档提取恐怕解压缩。那就代表不须要通过tar.gz解压缩整个bakcup来还原一个单表

文件能够因此qpress解压缩,qpress援救二十四线程解压缩

xtrabakcup工作原理

xtrabackup基于InnoDB
crash-recovery功用,拷贝innodb数据文件,那会导致数据里面不雷同,,可是随后它在文书上执行crash
recovery使数据文件一致

innodb维护redo log又称工作日志。redo
log日志中涵盖innodb数据的历次变更。当innodb运行时会去检查数据文件和事情日志,然后又五个步骤,1,apply应用已交付的作业日志到数据文件,2,已转移但未提交的业务举行undo操作

percona
xtrabackup在运转的时候记录LSN,然后拷贝数据文件,那会需求某个时刻,,所以一旦文件改变了,它体现出分裂时间点数据库的情事,。同时,xtrabakcup运转五个后台实行监督工作日志,并拷贝变动(复制修改).xtrabakcup必要持续运作以上因为业务日志是循环写的,过段时间之后会被复用,xtrabackup必要每一趟数据文件变化对应的作业日志记录

上述是备份的进度,下一步是prepare的进度,在那些历程中,xtarabakcup通过已拷贝的作业日志在已拷贝的数据文件上进行crash
recovery。之后,数据库已经得以开始展览还原并得以应用了

上述通过编写翻译好的二进制xtrabakcup实施了。

Innobackup在此基础上增添了更加多职能,比如备份Myisam表和.frm文件。它运转xtrabakcup并且等待它做到拷贝文件,之后执行FLUSH
TABLES WITH READ
LOCK防止mysql数据变动,获得表全局锁,然后flush全部的myisam表到磁盘,之后再释放表全局锁

备份的myisam和innodb表最终会同样,因为在prepare(recovery)之后,innodb数据会前滚到备份完毕时候的时间点,而不是回滚到备份伊始时候的时间点。这些时刻点与FLUSH TABLES WITH READ LOCK产生时同样,全体myisam与已prepare过的Innodb数据是联合署名的

percona xtrabakcup是有些列如下的工具:

innobackupex:xtrabackup的符号连接,innobakcupex援助2.2本子的富有天性和语法,可是未来早就降级并且在以2个重庆大学版本中remove

xtrabackup:编写翻译的C程序提供备份一整个数据库实例myisam和Innodb表

xbstream:以xbstream格式streaming和领取文件

相关文章