研發(fā)的童鞋每次對MySQL庫表做重大操作之前，例如：

• 修改表結(jié)構(gòu);
• 批量修改或者刪除數(shù)據(jù);

都會向DBA申請進行數(shù)據(jù)庫的備份。

畫外音：又或者說，不備份直接操作啦?

那DBA童鞋是怎么進行MySQL備份的呢?

調(diào)研了幾十個RD和QA，基本是3種答案：

• 不太清楚;
• 在線邏輯備份，mysqldump;
• 離線物理備份(冷備)，拷貝從庫庫文件;

那實際上，DBA是如何對MySQL進行庫備份的呢?

現(xiàn)在基本上使用的是PXB方案。

今天，和大家說說MySQL備份的來龍去脈，以及內(nèi)核原理。

在線邏輯備份，mysqldump是咋回事?

mysqldump是MySQL工具集中的一個工具，可以用來導出或備份數(shù)據(jù)。

mysqldump的產(chǎn)出物是一個包含了建表，插入數(shù)據(jù)的SQL語句集合，類似于這樣：

-- MySQL dump 1.2.3 
-- Host: localhost Database: test 
-- Server version 4.5.6 
 
CREATE TABLE t_user ( 
 id int(11)NOT NULL unique, 
 name varchar(40) NOT NULL default '', 
 PRIMARY KEY  (id) 
); 
 
INSERT INTO t_user VALUES (1,'shenjian'); 
INSERT INTO t_user VALUES (2,'zhangsan'); 
INSERT INTO t_user VALUES (3,'lisi'); 

因此，它才稱為邏輯備份。

使用mysqldump進行備份的優(yōu)點是：可以在線進行，不影響數(shù)據(jù)庫對線上持續(xù)提供服務。

缺點也顯而易見：相比物理備份拷貝庫文件，備份和恢復都要慢非常多。

離線物理備份，拷貝從庫庫文件又是咋回事?

為了提高備份效率，縮短備份時間，這也就引發(fā)了第二種方案，直接物理備份庫文件。

如上圖所示，數(shù)據(jù)庫集群設置為左側(cè)的1主2從架構(gòu)，離線物理備份是如何實施的呢?

• 第一步，將一個從庫從集群里摘下并下線，此時離線庫文件不會再發(fā)生變化;
• 第二步，scp拷貝庫文件，即完成了庫的物理備份;
• 文件拷貝完成后，將從庫掛回集群;

使用離線物理備份的優(yōu)點是：備份和恢復都非常快。

缺點也顯而易見：備份過程中從庫無法對線上持續(xù)提供服務。

那么問題來了，有沒有一種方案，又能夠快速備份物理文件，又能夠持續(xù)對線上提供服務呢?

這就是如今MySQL備份最流行的PXB方案。

什么是PXB?

PXB的全稱是，Percona XtraBackup，官網(wǎng)是這么吹的：PXB是全世界唯一一款開源免費的，支持MySQL熱備的，非阻塞備份工具。

畫外音：Percona XtraBackup is the world’s only open-source, free MySQL hotbackup software that performs non-blocking backups tool.

那么，PXB是如何實現(xiàn)：

• 保持數(shù)據(jù)庫持續(xù)提供線上服務，庫文件不斷變化時;
• 通過MySQL文件;
• 來進行庫文件物理熱備份的呢?

為了把問題講透，這就要從redo log，從LSN，從MySQL的故障恢復(crash-recovery)機制聊起。

一、redo log

(1) 為什么要有redo log?

事務提交后，必須將事務對數(shù)據(jù)頁的修改刷(fsync)到磁盤上，才能保證事務的ACID特性。

這個刷盤，是一個隨機寫，隨機寫性能較低，如果每次事務提交都刷盤，會極大影響數(shù)據(jù)庫的性能。

(2) 隨機寫性能差，有什么優(yōu)化方法呢?

架構(gòu)設計中有兩個常見的優(yōu)化方法：

• 先寫日志(write log first)，將隨機寫優(yōu)化為順序?qū)?
• 將每次寫優(yōu)化為批量寫;

這兩個優(yōu)化，數(shù)據(jù)庫都用上了。

第一個優(yōu)化，將對數(shù)據(jù)的修改先順序?qū)懙饺罩纠?，這個日志就是redo log。第二個優(yōu)化，就是redo log的三層架構(gòu)：

• log buffer：應用層緩沖;
• OS cache：操作系統(tǒng)緩存;
• redo log file：物理文件;

畫外音：此處不是本文的重點，不再展開詳述。

假如某一時刻，數(shù)據(jù)庫崩潰，還沒來得及將數(shù)據(jù)頁刷盤，數(shù)據(jù)庫重啟時，會重做redo log里的內(nèi)容，以保證已提交事務對數(shù)據(jù)的影響被刷到磁盤上。

一句話，redo log是為了保證已提交事務的ACID特性，同時能夠提高數(shù)據(jù)庫性能的技術(shù)。

二、redo log的格式

邏輯上，MySQL以行(row)為單位管理數(shù)據(jù);物理上，MySQL以頁(page)為單位管理數(shù)據(jù)，MySQL的緩沖池(buffer)機制，也是以頁為單位管理數(shù)據(jù)，事務提交之后，不用每次都隨機寫落盤刷新數(shù)據(jù)頁，而是通過順序?qū)憆edo log來提高性能，那么redo log是直接保存等待刷盤的數(shù)據(jù)頁嗎?

如果redo log直接保存待刷盤的數(shù)據(jù)頁，存在這樣的問題，假如某個SQL語句只修改了一行記錄里的一個屬性，例如：

update set sex=1 where name='shenjian' 

物理上，其實只修改了1個字節(jié)，難道redo log要將這個屬性所在的一頁數(shù)據(jù)(16K)全部保存下來嗎?

完全不用，redo log只需要記錄：

• 某個數(shù)據(jù)頁中(page num);
• 某個某個偏移位置(offset);
• 某個類型的數(shù)據(jù)(type);
• 改成了什么值(value);

如此一來，redo log既能夠?qū)崿F(xiàn)以頁為單位順序刷盤數(shù)據(jù)，又極大縮小了日志大小，其性能又進一步的增加了。

update set sex=1 where name='shenjian' 

仍以這個SQL為例，假設它修改了第1234頁，偏移量為5678處，1個字節(jié)的數(shù)據(jù)，這個字節(jié)的sex由0改成了1，那么，很容易想到redo log是類似于這樣的一個結(jié)構(gòu)：

如此一來，當數(shù)據(jù)庫崩潰的時候，如果緩沖池中的數(shù)據(jù)沒有來得及刷盤，就可以通過redo log，把第1234頁，偏移量為5678處的1個字節(jié)改為1，以此來恢復數(shù)據(jù)。

當然，MySQL會通過一系列的數(shù)據(jù)結(jié)構(gòu)對redo log來進行管理，最小單位的redo log是一個512字節(jié)的數(shù)據(jù)塊(block)，這個數(shù)塊由12字節(jié)的header，508字節(jié)的body，4字節(jié)的trailer組成，body里保存的就是上述數(shù)據(jù)頁如何進行修改的記錄。

記錄redo log的文件有若干個，每個都固定大小，循環(huán)使用。

畫外音：為了使得行文通俗易懂，本文盡量沒有提及Mini-Transaction(mtr)的概念。

三、LSN

要聊redo log，要聊故障恢復，LSN是一個繞不開的概念。

(1) 什么是LSN?

LSN，Log Sequeue Number，直譯過來叫日志序列號，是InnoDB中，隨著日志的寫入，一個只增不減的8字節(jié)序列號。

聽上去叫日志序列號，但LSN并不只存在redo log中，它還存儲在數(shù)據(jù)頁里。

畫外音：緩沖池中的數(shù)據(jù)頁，磁盤上的數(shù)據(jù)頁都存儲了LSN。

數(shù)據(jù)頁(page)里存儲的LSN，可以用來標記數(shù)據(jù)頁的“版本號”，記錄該數(shù)據(jù)頁最后一次被修改的日志序列的位置。

舉個例子，假設邏輯上連續(xù)執(zhí)行了兩個事物，且都已經(jīng)提交：

trx1: 
update set sex=0 where name='shenjian' 
        redolog lsn=1000 
trx2: 
update set sex=1 where name='shenjian' 
        redolog lsn=1001 

畫外音：lsn增加了。

又假設，第一個事務trx1已經(jīng)刷盤，而第二個事務trx2還沒有刷盤，只寫了redo log。

畫外音：最近一次刷盤的頁，即最近一次檢查點(checkpoint)，也是通過LSN來記錄的，它也會被寫入redo log里。

這兩個事務修改的是同一個數(shù)據(jù)頁，很容易想到：

磁盤數(shù)據(jù)頁上的LSN=1000

而redo log里有兩條記錄：

• 第一條，redo log lsn=1000
• 第二條，redo log lsn=1001

為了提高數(shù)據(jù)庫性能，數(shù)據(jù)庫基本都是使用WAL(Write Ahead Log)的方式，先寫日志再刷盤，所以很容易能夠想到，磁盤數(shù)據(jù)頁里的LSN，會小于最新redo log中的LSN。

畫外音：此時，redo log中記錄的checkpoint也是1000。

(2) LSN有什么用呢?

它和MySQL的故障恢復(crash-recovery)機制緊密相關。

四、InnoDB故障恢復(crash-recovery)

這里的故障恢復，是指MySQL非正常退出，然后再次啟動之前，要恢復數(shù)據(jù)一致性的操作。

畫外音：可能直譯叫崩潰恢復更準確一些。

(1) InnoDB的崩潰恢復過程是怎么樣的?

主要分為四個步驟：

第一步，redo log操作：保證已提交事務影響的最新數(shù)據(jù)刷到數(shù)據(jù)頁里。

第二步，undo log操作：保證未提交事務影響的數(shù)據(jù)頁回滾。

第三步，寫緩沖(change buffer)合并。

畫外音：不是今天的重點，關于寫緩沖的概念，詳見《寫緩沖(change buffer)，這次徹底懂了!》。

第四步，purge操作。

畫外音：InnoDB的一種垃圾收集機制，使用單獨的后臺線程周期性處理索引中標記刪除的數(shù)據(jù)，也不是今天的重點，未來可以詳細講。

(2) 第一個步驟中，redo log操作是如何恢復最新的數(shù)據(jù)頁的呢?

• 從redo log中讀取checkpoint lsn，它記錄的是最后一次刷盤的頁，對應日志的LSN;
• 如果redo log中記錄的日志LSN小于checkpoint，說明相關數(shù)據(jù)已經(jīng)被刷盤，不用額外操作;
• 如果redo log中記錄的日志LSN大于checkpoint，說明相關數(shù)據(jù)只寫了redo log，沒來得及刷盤，就需要對相關數(shù)據(jù)頁重做日志，例如：

將第1234頁，偏移量為5678處的1個字節(jié)改為1，以此來恢復數(shù)據(jù)。

崩潰恢復過程中，MySQL的啟動日志更形象的說明了這一點：

• 先找到checkpoint。
• 然后不斷的掃描大于checkpoint的redo log，不斷的恢復數(shù)據(jù)。

畫外音：redo log的LSN可以看到恢復的進程。

多說一句，redo log還有兩個特性：

• 第一，冪等性，同一條redo log執(zhí)行多次，不影響數(shù)據(jù)的恢復。
• 第二，崩潰恢復時，從比checkpoint更早的LSN開始執(zhí)行恢復，也不影響數(shù)據(jù)最終的一致性，因為一個數(shù)據(jù)頁，最終一定會被更大值的LSN日志恢復到最新的數(shù)據(jù)上來。

五、PXB在線熱備原理

不知不覺寫了幾千字，差點忘了緣起的問題。

PXB是如何實現(xiàn)：

• 保持數(shù)據(jù)庫持續(xù)提供線上服務，庫文件不斷變化時;
• 通過MySQL文件;
• 來進行庫文件物理熱備份的呢?

通過上面大把的鋪墊，這個問題的回答就容易了。

首先，PXB啟動一個線程，并不斷監(jiān)聽并復制redo log的增量到另外的文件，不能直接備份redo log的原因是，redo log循環(huán)使用的，PXB則必須記錄下checkpoint LSN之后的所有redo log。

然后，PXB啟動另一個線程，然后開始復制數(shù)據(jù)文件，復制數(shù)據(jù)文件過程可能會比較長，整個過程中數(shù)據(jù)文件可能在不停的修改，導致數(shù)據(jù)不一致。但沒有關系，所有的修改都已經(jīng)記錄在了第一步中，額外記錄的redo log里。

畫外音：務必注意，備份redo log的線程，必須在開始備份數(shù)據(jù)文件之前啟動，之后結(jié)束。

最后，通過備份的數(shù)據(jù)文件，重放redo log，執(zhí)行類似于MySQL崩潰恢復過程中的動作，就能夠使得數(shù)據(jù)文件恢復到能保證一致性的checkpoint檢查點。

畫外音：PXB還可以對非MySQL，非InnoDB進行在線熱備，這里就不展開了。

是不是很神奇啊!

【本文為51CTO專欄作者“58沈劍”原創(chuàng)稿件，轉(zhuǎn)載請聯(lián)系原作者】

戳這里，看該作者更多好文