Xtrabackup工做原理

目錄

• 1.Xtrabackup介紹
• 2.Xtrabackup備份涉及的數據庫名詞
  • 2.1.MySQL數據文件擴展名知識說明
  • 2.2.事務型引擎的ACID特性
  • 2.3.InnoDB引擎內部知識概念
  • 2.4.InnoDB引擎內部知識及說明
  • 2.5.InnoDB備份相關名詞
• 3.Xtrabackup備份的工做原理
  • 3.1.Xtrabackup恢復的工做原理
  • 3.2.Xtrabackup執行全備份的原理
  • 3.3.Xtrabackup執行全備份恢復的過程
  • 3.4.Xtrabackup執行增量備份的過程
  • 3.5.Xtrabackup執行增量恢復的過程

1.Xtrabackup介紹

Xtrabackup是Percona公司專門針對MySQL數據庫開發的一款開源免費的物理備份（熱備）工具，能夠對InnoDB和XtraDB等事務引擎的數據庫實現非阻塞（即不鎖表）方式的備份，也能夠針對MyISAM等非事務引擎實現鎖表方式備份。

Xtrabackup的主要特色：

一、直接複製物理文件，備份和恢復數據的速度很是快，安全可靠。
二、在備份期間執行的事務不會間斷，備份InnoDB數據不會影響業務。
三、備份期間不會增長太多數據庫的性能壓力。
四、支持對備份的數據進行自動校驗。
五、支持全量、增量、壓縮備份及流備份。
六、支持在線遷移表以及快速建立新的從庫。
七、支持幾乎全部版本的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數據到全備數據中，同時回滾未提交的事務。