基于Innobackupex的增备及恢复

    MySQL的热备(物理备份)可以采取全备加增量备份的方式来减轻数据库I/O压力及系统资源的占用。增量备份主要是以全备或增量备份为基础，备份那些变更过的页面。其备份的原理是基于一个不断增长的LSN序列，这个LSN与Oracle的SCN类似。在恢复期间，我们需要将已提交的事务前滚，未提交的事务回滚。本文主要描述了增量备份及增量恢复。

 

1、增备的相关知识点
    As not all information changes between each backup, the incremental backup strategy uses this to reduce the storage needs and the duration of making a backup. This can be done because each InnoDB page has a log sequence number, LSN, which acts as a version number of the entire database. Every time the database is modified, this number gets incremented. An incremental backup copies all pages since a specific LSN. Once the pages have been put together in their respective order, applying the logs will recreate the process that affected the database, yielding the data at the moment of the most recently created backup.

    增备是备份上次以来发生变化的页面，通过增备可以减轻存储以及系统资源开销。增量备份主要针对于InnoDB，因为InnoDB采用了日志序列号(LSN)的方式。InnoDB的LSN是一个增长的序列，类似于Oracle的SCN，记录了InnoDB的变化情况。增量备份则是备份特定的LSN之后变化的情况。通过按序重组这些LSN即可将数据库恢复到故障点或任意时刻。

    innobackupex --incremental /data/backups --incremental-lsn=1291135
    innobackupex --incremental /data/backups --incremental-lsn=1358967 
    如上，我们可以使用--incremental-lsn选项来实施增量备份

 

    Warning: This procedure only affects XtraDB or InnoDB-based tables. Other tables with a different storage engine, e.g. MyISAM, will be copied entirely each time an incremental backup is performed.

    对于非XtraDB或者InnoDB存储引擎，热备方式依旧会全部备份所有的数据文件，索引文件，格式文件等。

 

    Preparing an Incremental Backup with innobackupex Preparing incremental backups is a bit different than full ones. This is, perhaps, the stage where more attention is needed:
    • First, only the committed transactions must be replayed on each backup. This will merge the base full backup with the incremental ones.
    • Then, the uncommitted transaction must be rolled back in order to have a ready-to-use backup.

    对于增量备份的Prepare阶段，有2个需要注意的地方，一个是提交的事务需要replayed，一个未提交的事务需要rollback。

 

    If you replay the committed transactions and rollback the uncommitted ones on the base backup, you will not be able to add the incremental ones. If you do this on an incremental one, you won’t be able to add data from that moment and the remaining increments. Having this in mind, the procedure is very straight-forward using the --redo-only option, starting with the base backup:

    如果在Prepare阶段replay了已提交的事务以及回滚了未提交的事务，则后续的增量备份无法添加到当前全备。因此在Prepare阶段全备应使用--redo-only选项。

 

    --redo-only should be used when merging all incrementals except the last one. That’s why the previous line doesn’t contain the --redo-only option. Even if the --redo-only was used on the last step, backup would still be consistent but in that case server would perform the rollback phase.

    对于存在多次增量的情形，仅仅只有最后一个增量不需要使用--redo-only 选项。如果使用了的话，rollback将由服务器启动的时候来完成。

 

2、演示增量备份

a、创建演示环境
robin@localhost[(none)]> create database tempdb;

robin@localhost[(none)]> use tempdb;

robin@localhost[tempdb]> create table tb(id smallint,val varchar(20));

robin@localhost[tempdb]> insert into tb  values(1,'fullbak');

b、启动一个全备
SHELL> innobackupex --user=robin -password=xxx --port=3606 --socket=/tmp/mysql3606.sock --defaults-file=/etc/my3606.cnf \
> /hotbak/full --no-timestamp

--再新增一条记录，以便区分全备与增备
robin@localhost[tempdb]> insert into tb values(2,'Incbak');

c、启动一个增量备份
SHELL> innobackupex --user=robin -password=xxx --port=3606 --socket=/tmp/mysql3606.sock --defaults-file=/etc/my3606.cnf \
> --incremental /hotbak/inc --incremental-basedir=/hotbak/full --no-timestamp
      --........非重要信息忽略........
innobackupex: Using mysql server version 5.6.12-log             --当前mysql的版本
innobackupex: Created backup directory /hotbak/inc              -- 创建备份目录
innobackupex: Suspend file '/hotbak/inc/xtrabackup_suspended_2' -- 同时会创建相应的suspended目录供临时使用
            --........非重要信息忽略........
xtrabackup: using the full scan for incremental backup
[01] Copying ./ibdata1 to /hotbak/inc/ibdata1.delta             --可以看到生产了相应的delta文件，即增量部分
[01]        ...done
>> log scanned up to (391476794)
xtrabackup: Creating suspend file '/hotbak/inc/xtrabackup_suspended_2' with pid '25001'
   --........非重要信息忽略........
141222 14:55:08  innobackupex: Executing FLUSH TABLES WITH READ LOCK...        --这个主要是针对非innodb
141222 14:55:08  innobackupex: All tables locked and flushed to disk

141222 14:55:08  innobackupex: Starting to backup non-InnoDB tables and files  --开始备份非innodb
innobackupex: in subdirectories of '/data/inst3606/data3606'                   --所有的非innodb会被重新备份一次
innobackupex: Backing up files '/data/inst3606/data3606/mysql/*.{frm,isl,MYD,...,CSV,opt,par}' (77 files)

141222 14:55:09  innobackupex: Executing FLUSH ENGINE LOGS...                   --日志切换
141222 14:55:09  innobackupex: Waiting for log copying to finish

xtrabackup: The latest check point (for incremental): '391476794'               --检查点位置
xtrabackup: Stopping log copying thread.
.>> log scanned up to (391476794)
   --........非重要信息忽略........
xtrabackup: Creating suspend file '/hotbak/inc/xtrabackup_log_copied' with pid '25001'
xtrabackup: Transaction log of lsn (391476794) to (391476794) was copied.        --复制事务日志
141222 14:55:10  innobackupex: All tables unlocked                               --表解锁
   --........非重要信息忽略........
141222 14:55:10  innobackupex: completed OK!

d、查看增备后的相关文件
SHELL>  ls -hltr /hotbak/inc/*delta*
-rw-r----- 1 root root 96K 2014/12/22 14:55 /hotbak/inc/ibdata1.delta

SHELL>  more /hotbak/inc/xtrabackup_info|grep ^incremental
incremental = Y

--文件xtrabackup_checkpoints包含了备份的相关检查点信息
SHELL>  more /hotbak/inc/xtrabackup_checkpoints
backup_type = incremental
from_lsn = 391476482
to_lsn = 391476794
last_lsn = 391476794
compact = 0

--文件xtrabackup_binlog_info包含了binlog的位置
SHELL>  more xtrabackup_binlog_info
inst3606bin.000010      874

--再次新增一条记录，看看增备能否恢复
robin@localhost[tempdb]> insert into tb values(3,'Inbinlog');
Query OK, 1 row affected (0.00 sec)

3、恢复增量备份

a、先做基于全备的apply，注意，此时使用了--redo-only
SHELL> innobackupex --apply-log --redo-only --user=robin -password=xxx --port=3606 \
> --defaults-file=/etc/my3606.cnf /hotbak/full

b、基于增备的apply，
--此时没有--redo-only，如果有多个增备，仅仅最后一个增备无需指定--redo-only
SHELL> innobackupex --apply-log --user=robin -password=xxx --port=3606 --defaults-file=/etc/my3606.cnf \
> /hotbak/full --incremental-dir=/hotbak/inc
   --........非重要信息忽略........
xtrabackup: page size for /hotbak/inc/tempdb/tb.ibd.delta is 16384 bytes
Applying /hotbak/inc/tempdb/tb.ibd.delta to ./tempdb/tb.ibd...  --可以看到数据库tempdb下表tb被apply到全备目录
xtrabackup: page size for /hotbak/inc/sakila/t.ibd.delta is 16384 bytes
Applying /hotbak/inc/sakila/t.ibd.delta to ./sakila/t.ibd...
           -- ........非重要信息忽略........
xtrabackup: Starting InnoDB instance for recovery.               --启动InnoDB实例恢复
xtrabackup: Using 104857600 bytes for buffer pool (set by --use-memory parameter)
   --........非重要信息忽略........
InnoDB: Highest supported file format is Barracuda.
InnoDB: The log sequence numbers 391476482 and 391476482 in ibdata files do not match
   the log sequence number 391476794 in the ib_logfiles! --提示log sequence不一致
InnoDB: Database was not shutdown normally!
InnoDB: Starting crash recovery.                         --启动crash recovery
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages
InnoDB: from the doublewrite buffer...
InnoDB: Last MySQL binlog file position 0 874, file name inst3606bin.000010
InnoDB: 128 rollback segment(s) are active.             --提示有一些rollback段是活动的
InnoDB: Waiting for purge to start
InnoDB: 5.6.21 started; log sequence number 391476794
   --........非重要信息忽略........ Author: Leshami Blog: http://blog.csdn.net/leshami
innobackupex: Starting to copy non-InnoDB files in '/hotbak/inc'
innobackupex: to the full backup directory '/hotbak/full'   --将非InnoDB表复制到全备目录，覆盖方式
innobackupex: Copying '/hotbak/inc/xtrabackup_binlog_info' to '/hotbak/full/xtrabackup_binlog_info'
   ........非重要信息忽略........
141222 16:19:52  innobackupex: completed OK!             --完成基于增量的合并

c、进行copy back
SHELL>  mv /data/inst3606/data3606 /data/inst3606/data3606bk --更正@2014122251018，在mv之前建议先关闭实例，即先执行后面的mysqldown
SHELL>  mkdir -p /data/inst3606/data3606

SHELL> mysqldown -P3606     --copy back前关闭实例
SHELL> netstat -nltp|grep mysql|grep 3606 

SHELL> innobackupex --user=robin -password=xxx --port=3606 --copy-back /hotbak/full --defaults-file=/etc/my3606.cnf
SHELL> chown -R mysql:mysql /data/inst3606/data3606  

--启动恢复后的实例
SHELL> mysqld_safe --defaults-file=/etc/my3606.cnf &

--验证结果
[mysql@app inst3606]$ sql -P3606

--如下查询，由于我们未使用binlog做完全恢复，因此无法查询到id为3的记录
robin@localhost[(none)]> select * from tempdb.tb;
+------+---------+
| id   | val     |
+------+---------+
|    1 | fullbak |
|    2 | Incbak  |
+------+---------+

4、小结
a、增量备份是基于增量或全备的基础之上完成的。
b、增量备份的基础是InnoDB引擎使用了LSN机制，非InnoDB引擎不存在增量备份的说法，每次都是全备。
c、对于增量备份的恢复期间需要对已提交的事务前滚，未提交的事务回滚。
d、增量备份的恢复应按照备份的顺利逐个逐个replay，需要使用--apply-log --redo-only选项。
e、仅仅最后一个增量备份不需要使用--redo-only选项。
f、如果要做完全恢复或时点恢复，需要结合binlog来实现。

时间： 2024-03-24 00:56:21

基于Innobackupex的增备及恢复的相关文章

基于Innobackupex的完全恢复

    对于MySQL的完全恢复,我们可以借助于Innobackupex的多重备份加上binlog来将数据库恢复到故障点.这里的完全恢复是相对于时点恢复(也叫不完全恢复).本文主要演示了基于Innobackupex如何做一个完全恢复,供大家参考.     有关Innobackupex的备份恢复的知识点请参考以下链接:        Innobackupex 全备数据库        使用mysqlbinlog提取二进制日志        基于Innobackupex的全备恢复         基

基于Innobackupex的全备恢复

    对于MySQL数据库的热备,xtrabackup是大多数DBA朋友们的选择.xtrabackup内嵌了一个innobackupex可用于热备MySQL数据库.本文描述了基于innobackupex这个工具全备下的恢复并给出演示供大家参考.    有关Innobackupex的全备可参考:Innobackupex 全备数据库   1.Innobackupex恢复原理    After creating a backup, the data is not ready to be restor

mysql xtrabackup在线备份还原（全备+增备）

工具安装: [root@mysqlserver var]# tar -xvf Percona-XtraBackup-2.3.4-re80c779-el6-x86_64-bundle.tar   --解压包 percona-xtrabackup-2.3.4-1.el6.x86_64.rpm percona-xtrabackup-debuginfo-2.3.4-1.el6.x86_64.rpm percona-xtrabackup-test-2.3.4-1.el6.x86_64.rpm  [root

基于Innobackupex的MySQL备份脚本

    Innobackupex是Xtrabackup的一部分,其实质也是调用xtrabackup.主要的不同是Xtrabackup除了支持innodb引擎外还支持xtradb引擎.本文主要封装了Innobackupex到shell脚本进行定期备份,供大家参考.   1.脚本描述a.支持增量备份以及全备b.需要传递到备份脚本(如备份路径,连接相关参数等)c.基于周日,周三的全量备份,其他增量备份d.可根据需要调整脚本,比如压缩备份的文件夹以及rsync等   2.脚本内容 ###########

Oracle技术：基于时间点的表空间恢复

TSPITR(表空间时间点恢复)用于将一个或多个表空间恢复到过去某个时间点的状态,而其他表空间仍然保持现有状态. TSPITR 相关的概念和术语: (1) TSPITR (Tablespace Point-In-Time Recover).TSPITR 是表空间时间点恢复的英文缩写格式,它表示将一个或多个表空间恢复到过去时间点的状态,而其他 表空间仍然保持现有状态. (2) TSPITR 实现方法.当实现表空间时间点恢复时,既可以使用用户管理的表空间时间点恢复方法,也可以使用RMAN 管理的表空

基于RMAN实现坏块介质恢复(blockrecover)

      对于物理损坏的数据块,我们可以通过RMAN块介质恢复(BLOCK MEDIA RECOVERY)功能来完成受损块的恢复,而不需要恢复整个数据库或所有文件来修复这些少量受损的数据块.恢复整个数据库或数据文件那不是大炮用来打蚊子,有点不值得!但前提条件是你得有一个可用的RMAN备份存在,因此,无论何时备份就是一切.本文演示了产生坏块即使用RMAN实现坏块恢复的全过程.   1.创建演示环境 SQL> select * from v$version where rownum<2; BAN

硅谷杂志：基于倒频谱的运动模糊图像恢复

[硅谷网12月4日文]据<硅谷>杂志2012年第18期刊文,图像去模糊是图像处理中的基本问题,在成像系统中,引起图像退化的原因有很多. 例如噪声的影响,就是引起图像降质的http://www.aliyun.com/zixun/aggregation/33196.html">主要原因之一,但另一个主要原因就是在成像系统的散焦,成像设备与物体的相对运动,成像器材的固有缺陷或外部干扰等过程中成像产生模糊.主要针对图像恢复中的模糊情况,利用倒频谱把模糊信息和原图像信息分离出来,从而可以

Oracle技术：基于表空间的时间点恢复

1.测试环境 03:57:50 SQL> conn scott/tiger Connected. 03:57:57 SQL> 03:59:43 SQL> select * from tab; TNAME                          TABTYPE  CLUSTERID ------------------------------ ------- ---------- EXCEPTIONS                     TABLE LXTB1        

javascript基于jQuery的表格悬停变色/恢复,表格点击变色/恢复,点击行选Checkbox_jquery

// 版本: 1.0 // 日期: 2007/08/01 // 备注: 需要jQuery库 // 参考: Dodo(tableRowCheckboxToggle) 和 softcomplex(tigra_tables) function Kin_Tables(                     Kin_Table_GetTableMethod, //得到Table的方法 同$()功能 必选参数                     Kin_Table_Header_Offset, //从