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 modi?ed, this number gets incremented. An incremental backup copies all pages since a speci?c 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將由服務器啟動的時候來完成。


二、 演示
1. 準備實驗環境
mysql> select version();
+------------+
| version() |
+------------+
| 5.6.25-log |
+------------+
1 row in set (0.00 sec)
mysql> create database inc_rec;
Query OK, 1 row affected (0.00 sec)
mysql> use inc_rec;
Database changed
mysql> create table andy (id int);
Query OK, 0 rows affected (0.08 sec)
mysql> insert into andy values(1),(2);
Query OK, 2 rows affected (0.00 sec)
Records: 2 Duplicates: 0 Warnings: 0
2. 全備
[[email protected]