[TOC] 1.Xtrabackup介紹 Xtrabackup是Percona公司專門針對MySQL資料庫開發的一款開源免費的物理備份（熱備）工具，可以對InnoDB和XtraDB等事務引擎的資料庫實現非阻塞（即不鎖表）方式的備份，也可以針對MyISAM等非事務引擎實現鎖表方式備份。 Xtrabac ...
目錄
1.Xtrabackup介紹
Xtrabackup是Percona公司專門針對MySQL資料庫開發的一款開源免費的物理備份（熱備）工具，可以對InnoDB和XtraDB等事務引擎的資料庫實現非阻塞（即不鎖表）方式的備份，也可以針對MyISAM等非事務引擎實現鎖表方式備份。
Xtrabackup的主要特點：
1、直接複製物理文件，備份和恢複數據的速度非常快，安全可靠。
2、在備份期間執行的事務不會間斷，備份InnoDB數據不會影響業務。
3、備份期間不會增加太多資料庫的性能壓力。
4、支持對備份的數據進行自動校驗。
5、支持全量、增量、壓縮備份及流備份。
6、支持線上遷移表以及快速創建新的從庫。
7、支持幾乎所有版本的MySQL和MariaDB。
2.Xtrabackup備份涉及的資料庫名詞
2.1.MySQL數據文件擴展名知識說明
Xtrabackup備份中涉及的一些資料庫專業信息知識：
| 文件擴展名 | 文件作用說明 |
|---|---|
| .idb文件 | 以獨立表空間存儲的InnoDB引擎類型的數據文件擴展名 |
| .ibdata文件 | 以共用表空間存儲的InnoDB引擎類型的數據文件擴展名 |
| .frm文件 | 存放與表相關的元數據（meta）信息以及表結構的定義信息 |
| .MYD文件 | 存放MyISAM引擎表的數據文件擴展名 |
| .MYI文件 | 存放MyISAM引擎表的索引信息文件擴展名 |
2.2.事務型引擎的ACID特性
在MySQL中，InnoDB和MariaDB中的XtraDB都是事務型引擎，事務型引擎的共同特征是具備事務的4個特性，這4個特性分別是：原子性（atomicity）、一致性（consistency）、隔離性（isolation）、持久性（durability），又稱為ACID特性。
ACID特性說明：
| ACID特性 | 說明 |
|---|---|
| 原子性 | 事務的所有SQL語句操作，要麼全部成功，要麼全部失敗 |
| 一致性 | 事務開始之前和結束之後，資料庫應保證數據的完整性不被破壞 |
| 隔離性 | 當多個事務併發訪問同一個數據源時，資料庫能夠保持每個訪問的事務之間是隔離的，互不影響的 |
| 持久性 | 事務處理完成之後，事務所做的更改都會是持久化存儲，不會丟失數據 |
2.3.InnoDB引擎內部知識概念
InnoDB基礎概念知識：
| 概念名稱 | 說明 |
|---|---|
| 表空間（tablespaces） | 表空間是一個邏輯的概念，表空間里存放的是表的數據和索引，這些表的數據和索引又有不同的存儲方式，表空間最終體現的是磁碟上資料庫的各種物理數據文件 |
| 獨立表空間（independent tablespaces） | 在開啟InnoDB的innodb_file_per_table=On這個參數之後，對於每一個新建的InnoDB表，資料庫目錄下都會多出來一個對應的存放該表數據的.ibd文件 |
| 共用表空間（shared tablespaces） | 5.6版本以前，MySQL的預設配置就是共用表空間模式，即所有表的數據都會在一個或幾個大數據文件中存放 |
| 頁（page） | MySQL的每個表空間都是由若幹個頁組成的，且每個實例里的每個表空間內都有相同的頁大小，預設值是16KB，可以通過innodb_page_size調整頁大小，每個頁中都包含了表的數據。組成表空間數據的最小單位是頁 |
| 區段（extent） | 在表空間中，系統會把每若幹個頁進行分組管理，這個組就叫作區段，預設一個區段的大小是64頁 |
| 段（segments） | 段是由多個不同的區段組成的更大的分組。當一個段增加的時候，InnoDB第一次分配32個頁給這個段，此後，InnoDB開始分配整個區段給這個段，InnoDB可以一次性添加4個區段給一個大的段，從而確保數據存儲時能有一個良好的順序性 |
2.4.InnoDB引擎內部知識及說明
InnoDB的表空間分為共用表空間和獨立表空間（推薦）兩種，表空間里存放數據的最小單位是頁，每個頁的預設值為16KB；多個連續的頁（預設是64個）組成一個區段；而多個區段和頁構成一個段。初始時，InnoDB首先會為每個段分配32個頁，之後根據實際需要再將區段分配給段，InnoDB可以一次性添加4個區給一個大的段，從而確保數據存儲時能有一個良好的順序性。
2.5.InnoDB備份相關名詞
InnoDB日誌及Xtrabackup備份原理所涉及的辭彙知識：
| 相關名詞 | 說明 |
|---|---|
| redo日誌 | redo日誌，也稱為事務日誌，是InnoDB引擎的重要組成部分，作用是記錄InnoDB引擎中每一個數據發生的變化信息。主要用於保證InnoDB數據的完整性，以及丟失數據後的恢復，同時還可以有效提升資料庫的IO等性能。redo日誌對應的配置參數為innodb_log_file_size和innodb_log_files_in_group |
| undo日誌 | undo日誌是記錄事務的逆向邏輯操作或者逆向物理操作對應的數據變化的內容，undo日誌預設存放在共用表空間中（ibdata*文件），與redo日誌功能不同的是undo日誌主要用於回滾資料庫崩潰前未完整提交的事務數據，確保數據恢復前後是一致的 |
| LSN | LSN（log sequence number）是指日誌序列號，是一個64位的整型數字。LSN的作用是記錄redo日誌時，使用LSN唯一標識一條變化的數據 |
| checkpoint | 用來標識資料庫崩潰後，應恢復的redo日誌的起始點 |
3.Xtrabackup備份的工作原理
3.1.Xtrabackup恢復的工作原理
Percona Xtrabackup軟體是基於InnoDB等事務引擎自帶的redo日誌和undo日誌功能來保持備份和恢復前後數據一致性的，從而確保資料庫的數據安全可靠。在InnoDB引擎中存在一個redo日誌（事務日誌）功能。redo日誌文件會存儲每一個InnoDB表中的數據修改記錄。當InnoDB資料庫啟動時，會檢查數據文件和redo日誌文件，將已經提交到事務日誌（redo日誌文件）中的信息應用（提交）到數據文件並保存，然後根據undo日誌信息將修改過但沒有提交的數據記錄進行回滾（不提交到數據文件）。
3.2.Xtrabackup執行全備份的原理
當執行Xtrabackup程式開始備份時，Xtrabackup首先會記錄當前redo日誌的位置（即對應的LSN號），同時還會在後臺啟動一個進程持續監視redo日誌文件的變化，並將變化的信息都記錄到Xtrabackup_logfile中，之後就會針對所有的InnoDB數據文件進行備份（複製），待InnoDB數據文件備份完成之後，再執行“flush tables with read lock”命令對整個資料庫鎖表，然後備份（複製）MyISAM等非事務引擎的數據文件。待數據文件全部（包括InnoDB、MyISAM數據文件和redo日誌數據記錄）都備份完畢之後，獲取binlog二進位日誌位置點信息，最後執行unlock tables解鎖命令，恢復整個資料庫的可讀寫狀態。
3.3.Xtrabackup執行全備份恢復的過程
當執行Xtrabackup工具恢複數據時，要經過準備恢復（prepare）和實際恢復（restore）兩個步驟。在準備恢復過程結束後，InnoDB表的數據（即備份的物理文件）就恢復到了複製InnoDB文件結束時的時間點，這個時間點也是全庫鎖表複製MyISAM引擎數據時的起點，所以最終恢復的數據和資料庫的數據是一致的。全備的數據有兩部分，一部分是全備的物理文件，一部分是Xtrabackup log日誌文件。
3.4.Xtrabackup執行增量備份的過程
Innobackupex增量備份的（僅對InnoDB引擎有效）核心就是複製全備之後的InnoDB中變更的“頁”數據，複製時會以全備中xtrabackup_checkpoints文件對應的LSN號為依據，將大於給定的LSN號的頁數據（就是增量數據）進行備份，因為要比對全備的LSN號，所以第一次增量備份是基於全備的，以後實施的每一次增量備份都要基於上一次的增量備份，最終實現備份的數據是連續的、無缺失的，針對MyISAM引擎的備份依然是鎖表備份。
增量備份的過程：
首先在全備的xtrabackup_checkpoints logfile中找到並記錄最後一個checkpoint（last checkpoint LSN），然後從該LSN的位置開始複製InnoDB的redo日誌到Xtrabackup_logfile，然後開始複製全部的數據文件.ibd，待全部數據複製結束後，就停止複製logfile，增量備份的過程與全備基本類似，區別就是第二步，僅複製InnoDB中變化的頁數據，而非所有物理文件。
3.5.Xtrabackup執行增量恢復的過程
增量數據的恢復過程與全量備份的恢復過程類似，所不同的是增量恢復是以全備份數據為基礎的，增量恢復的數據主要涉及全備的數據、增量的數據、Xtrabackup_log日誌文件。恢復過程是先將增量備份中變化的頁數據應用到全備數據中，然後，讀取Xtrabackup_log應用redo數據到全備數據中，同時回滾未提交的事務。
