mysql數據庫熱備問題（sqlserver數據庫熱備）

本文目錄一覽：

• 1、mysql 多機 熱備
• 2、w10系統能不能配mysql數據庫雙擊熱備？
• 3、查看mysql是否為雙機
• 4、MySQL 熱備份之xtrabackup
• 5、MySQL 常用備份工具流程解析

mysql 多機 熱備

2,3問題，這樣的話可以用mysqldump進行熱備，但是這樣會鎖表，應用無法向數據庫進行寫操作，如果必須有寫操作的話，可以使用xtrabackup熱備工具，支持在線熱備，對innodb表不會有讀寫影響，但是對myisam表會鎖住，如果你庫裏面大部分是myisam表…（火星人）0208

w10系統能不能配mysql數據庫雙擊熱備？

　1.mysql數據庫沒有增量備份的機制，當數據量太大的時候備份是一個很大的問題。還好mysql數據庫提供zhidao了一種主從備份的機制，其實就是把主數據庫的所有的數據同時寫到備份數據庫中。實現mysql數據庫的熱備版份。

2.要想實現雙機的熱備首先要了解主從數據庫服務器的版本的需求。要實現熱備mysql的版本都要高於3.2，還有一個基本的原則就是作為從數據庫的數據庫版本可權以高於主服務器數據庫的版本，但是不可以低於主服務器的數據庫版本。

查看mysql是否為雙機

mysql雙機熱備實現原理分析，在本文經過深思熟慮和多次用不同的方式實測試後。最後在這篇文章中，用一個小例子來完成mysql雙機熱備的實現。

Mysql數據庫沒有增量備份的機制，當數據量太大的時候備份是一個很大的問題。還好mysql數據庫提供了一種主從備份的機制，其實就是把主數據庫的所有的數據同時寫到備份的數據庫中。實現mysql數據庫的熱備份。

要想實現雙機的熱備，首先要了解主從數據庫服務器的版本的需求。要實現熱備mysql的版本都高於3.2。還有一個基本的原則就是作為從數據庫的數據版本可以高於主服務器數據庫的版本，但是不可以低於主服務器的數據庫版本。

當然要實現mysql雙機熱備，除了mysql本身自帶的REPLICATION功能可以實現外，也可以用Heartbeat這個開源軟件來實現。不過本文主要還是講如何用mysql自帶的REPLICATION來實現mysql雙機熱備的功能。

1. 準備服務器

由於Mysql不同版本之間的（二進制日誌）binlog格式可能會不太一樣，因此最好的搭配組合是主（Master）服務器的Mysql版本和從（Slave）服務器版本相同或者更低，主服務器的版本肯定不能高於從服務器版本。

本次我用於測試的兩台服務器版本都是Mysql-5.5.17。

2. Mysql 建立主－從服務器雙機熱備配置步驟

2.1環境描述

A服務器（主服務器Master）：59.151.15.36

B服務器（從服務器Slave）：218.206.70.146

主從服務器的Mysql版本皆為5.5.17

Linux環境下

將主服務器需要同步的數據庫內容進行備份一份，上傳到從服務器上，保證始初時兩服務器中數據庫內容一致。

不過這裡說明下，由於我是利用Mysql在安裝後就有的數據庫test進行測試的，所以兩台服務器裏面是沒有建立表的，只不分別在test裏面建立了同樣的一張空表tb_mobile;

Sql語句如下：

mysql create table tb_mobile( mobile VARCHAR(20) comment’手機號碼’, time timestamp DEFAULT now() comment’時間’ );

2.2 主服務器Master配置

2.2.1 創建同步用戶

進入mysql操作界面，在主服務器上為從服務器建立一個連接帳戶，該帳戶必須授予REPLICATION SLAVE權限。因為從mysql版本3.2以後就可以通過REPLICATION對其進行雙機熱備的功能操作。

操作指令如下：

mysql grant replication slave on *.* to ‘replicate’@’218.206.70.146’ identified by ‘123456’;

mysql flush privileges;

創建好同步連接帳戶後，我們可以通過在從服務器（Slave）上用replicat帳戶對主服務器（Master）數據庫進行訪問下，看下是否能連接成功。

在從服務器（Slave）上輸入如下指令：

[root@YD146 ~]# mysql -h59.151.15.36 -ureplicate -p123456

如果出現下面的結果，則表示能登錄成功，說明可以對這兩台服務器進行雙機熱備進行操作。

2.2.2 修改mysql配置文件

如果上面的準備工作做好，那邊我們就可以進行對mysql配置文件進行修改了，首先找到mysql配置所有在目錄，一般在安裝好mysql服務後，都會將配置文件複製一一份出來放到/ect目錄下面，並且配置文件命名為：my.cnf。即配置文件準確目錄為/etc/my.cnf

(Linux下用rpm包安裝的MySQL是不會安裝/etc/my.cnf文件的，

至於為什麼沒有這個文件而MySQL卻也能正常啟動和作用，在點有兩個說法，

第一種說法，my.cnf只是MySQL啟動時的一個參數文件，可以沒有它，這時MySQL會用內置的默認參數啟動，

第二種說法，MySQL在啟動時自動使用/usr/share/mysql目錄下的my-medium.cnf文件，這種說法僅限於rpm包安裝的MySQL，

解決方法，只需要複製一個/usr/share/mysql目錄下的my-medium.cnf文件到/etc目錄，並改名為my.cnf即可。)

找到配置文件my.cnf打開後，在[mysqld]下修改即可：

[mysqld]

server-id = 1

log-bin=mysql-bin //其中這兩行是本來就有的，可以不用動，添加下面兩行即可

binlog-do-db = test

binlog-ignore-db = mysql

2.2.3 重啟mysql服務

修改完配置文件後，保存後，重啟一下mysql服務，如果成功則沒問題。

2.2.4 查看主服務器狀態

進入mysql服務後，可通過指令查看Master狀態，輸入如下指令：

注意看裏面的參數，特別前面兩個File和Position，在從服務器（Slave）配置主從關係會有用到的。

註：這裡使用了鎖表，目的是為了產生環境中不讓進新的數據，好讓從服務器定位同步位置，初次同步完成後，記得解鎖。

2.3 從服務器Slave配置

2.3.1修改配置文件

因為這裏面是以主－從方式實現mysql雙機熱備的，所以在從服務器就不用在建立同步帳戶了，直接打開配置文件my.cnf進行修改即可，道理還是同修改主服務器上的一樣，只不過需要修改的參數不一樣而已。如下：

[mysqld]

server-id = 2

log-bin=mysql-bin

replicate-do-db = test

replicate-ignore-db = mysql,information_schema,performance_schema

2.3.2重啟mysql服務

修改完配置文件後，保存後，重啟一下mysql服務，如果成功則沒問題。

2.3.3用change mster 語句指定同步位置

這步是最關鍵的一步了，在進入mysql操作界面後，輸入如下指令：

mysqlstop slave; //先停步slave服務線程，這個是很重要的，如果不這樣做會造成以下操作不成功。

mysqlchange master to

master_host=’59.151.15.36′,master_user=’replicate’,master_password=’123456′,

master_log_file=’ mysql-bin.000016 ‘,master_log_pos=107;

註：master_log_file, master_log_pos由主服務器（Master）查出的狀態值中確定。也就是剛剛叫注意的。master_log_file對應File, master_log_pos對應Position。Mysql 5.x以上版本已經不支持在配置文件中指定主服務器相關選項。

遇到的問題，如果按上面步驟之後還出現如下情況：

則要重新設置slave。指令如下

mysqlstop slave;

mysqlreset slave;

之後停止slave線程重新開始。成功後，則可以開啟slave線程了。

mysqlstart slave;

2.3.4查看從服務器（Slave）狀態

用如下指令進行查看

mysql show slave status\G;

查看下面兩項值均為Yes，即表示設置從服務器成功。

Slave_IO_Running: Yes

Slave_SQL_Running: Yes

2.4 測試同步

之前開始已經說過了在數據庫test只有一個表tb_mobile沒有數據，我們可以先查看下兩服務器的數據庫是否有數據：

Master:59.151.15.36

Slave:218.206.70.146

好了，現在可以在Master服務器中插入數據看下是否能同步。

Master:59.151.15.36

Slave:218.206.70.146

可以從上面兩個截圖上看出，在Master服務器上進行插入的數據在Slave服務器可以查到，這就表示雙機熱備配置成功了。

3. Mysql 建立主－主服務器雙機熱備配置步驟

服務器還是用回現在這兩台服務器

3.1創建同步用戶

同時在主從服務器建立一個連接帳戶，該帳戶必須授予REPLIATION SLAVE權限。這裡因為服務器A和服務器B互為主從，所以都要分別建立一個同步用戶。

服務器A：

mysql grant replication slave on *.* to ‘replicate’@’218.206.70.146’ identified by ‘123456’;

mysql flush privileges;

服務器B：

mysql grant replication slave on *.* to ‘replicate’@’59.151.15.36’ identified by ‘123456’;

mysql flush privileges;

3.2修改配置文件my.cnf

服務器A

[mysqld]

server-id = 1

log-bin=mysql-bin

binlog-do-db = test

binlog-ignore-db = mysql

#主－主形式需要多添加的部分

log-slave-updates

sync_binlog = 1

auto_increment_offset = 1

auto_increment_increment = 2

replicate-do-db = test

replicate-ignore-db = mysql,information_schema

服務器B：

[mysqld]

server-id = 2

log-bin=mysql-bin

master-slave need

replicate-do-db = test

replicate-ignore-db = mysql,information_schema,performance_schema

#主－主形式需要多添加的部分

binlog-do-db = test

binlog-ignore-db = mysql

log-slave-updates

sync_binlog = 1

auto_increment_offset = 2

auto_increment_increment = 2

3.3分別重啟A服務器和B服務器上的mysql服務

重啟服務器方式和上面的一樣，這裡就不做講解了。

3.4分別查A服務器和B服務器作為主服務器的狀態

服務器A：

服務器B：

3.5分別在A服務器和B服務器上用change master to 指定同步位置

服務器A：

mysqlchange master to

master_host=’218.206.70.146′,master_user=’replicate’,master_password=’123456′,

master_log_file=’ mysql-bin.000011 ‘,master_log_pos=497;

服務器B：

mysqlchange master to

master_host=’59.151.15.36′,master_user=’replicate’,master_password=’123456′,

master_log_file=’ mysql-bin.000016 ‘,master_log_pos=107;

3.6 分別在A和B服務器上重啟從服務線程

mysqlstart slave;

3.7 分別在A和B服務器上查看從服務器狀態

mysqlshow slave status\G;

查看下面兩項值均為Yes，即表示設置從服務器成功。

Slave_IO_Running: Yes

Slave_SQL_Running: Yes

3.8 測試主－主同步例子

測試服務器A：

在服務器A上插入一條語句如下圖所示：

之後在服務器B上查看是否同步如下圖所示：

測試服務器B：

在服務器B上插入一條語句如下圖所示：

然後在從服務器A上查看是否有同步數據如下圖所示：

最後從結果可以看出主－主形式的雙機熱備是能成功實現的。

4. 配置參數說明

Server-id

ID值唯一的標識了複製群集中的主從服務器，因此它們必須各不相同。Master_id必須為1到232－1之間的一個正整數值，slave_id值必須為2到232－1之間的一個正整數值。

Log-bin

表示打開binlog，打開該選項才可以通過I/O寫到Slave的relay-log，也是可以進行replication的前提。

Binlog-do-db

表示需要記錄二進制日誌的數據庫。如果有多個數據可以用逗號分隔，或者使用多個binlog-do-dg選項。

Binglog-ingore-db

表示不需要記錄二進制日誌的數據庫，如果有多個數據庫可用逗號分隔，或者使用多binglog-ignore-db選項。

Replicate-do-db

表示需要同步的數據庫，如果有多個數據可用逗號分隔，或者使用多個replicate-do-db選項。

Replicate-ignore-db

表示不需要同步的數據庫，如果有多個數據庫可用逗號分隔，或者使用多個replicate-ignore-db選項。

Master-connect-retry

master-connect-retry=n表示從服務器與主服務器的連接沒有成功，則等待n秒（s）後再進行管理方式（默認設置是60s）。如果從服務器存在mater.info文件，它將忽略些選項。

Log-slave-updates

配置從庫上的更新操作是否寫入二進制文件，如果這台從庫，還要做其他從庫的主庫，那麼就需要打這個參數，以便從庫的從庫能夠進行日誌同步。

Slave-skip-errors

在複製過程，由於各種原因導致binglo中的sql出錯，默認情況下，從庫會停止複製，要用戶介入。可以設置slave-skip-errors來定義錯誤號，如果複製過程中遇到的錯誤是定義的錯誤號，便可以路過。如果從庫是用來做備份，設置這個參數會存在數據不一致，不要使用。如果是分擔主庫的查詢壓力，可以考慮。

Sync_binlog=1 Or N

Sync_binlog的默認值是0，這種模式下，MySQL不會同步到磁盤中去。這樣的話，Mysql依賴操作系統來刷新二進制日誌binary log，就像操作系統刷新其他文件的機制一樣。因此如果操作系統或機器（不僅僅是Mysql服務器）崩潰，有可能binlog中最後的語句丟失了。要想防止這種情況，可以使用sync_binlog全局變量，使binlog在每N次binlog寫入後與硬盤同步。當sync_binlog變量設置為1是最安全的，因為在crash崩潰的情況下，你的二進制日誌binary log只有可能丟失最多一個語句或者一個事務。但是，這也是最慢的一種方式（除非磁盤有使用帶蓄電池後備電源的緩存cache,使得同步到磁盤的操作非常快）。

即使sync_binlog設置為1，出現崩潰時，也有可能表內容和binlog內容之間存在不一致性。如果使用InnoDB表，Mysql服務器處理COMMIT語句，它將整個事務寫入binlog並將事務提交到InnoDB中。如果在兩次操作之間出現崩潰，重啟時，事務被InnoDB回滾，但仍然存在binlog中。可以用-innodb-safe-binlog選項來增加InnoDB表內容和binlog之間的一致性。（注釋：在Mysql 5.1版本中不需要-innodb-safe-binlog；由於引入了XA事務支持，該選項作廢了），該選項可以提供更大程度的安全，使每個事務的binlog(sync_binlog=1)和（默認情況為真）InnoDB日誌與硬盤同步，該選項的效果是崩潰後重啟時，在滾回事務後，Mysql服務器從binlog剪切回滾的InnoDB事務。這樣可以確保binlog反饋InnoDB表的確切數據等，並使從服務器保持與主服務器保持同步（不接收回滾的語句）。

Auto_increment_offset和Auto_increment_increment

Auto_increment_increment和auto_increment_offset用於主－主服務器（master-to-master）複製，並可以用來控制AUTO_INCREMENT列的操作。兩個變量均可以設置為全局或局部變量，並且假定每個值都可以為1到65,535之間的整數值。將其中一個變量設置為0會使該變量為1。

這兩個變量影響AUTO_INCREMENT列的方式：auto_increment_increment控制列中的值的增量值，auto_increment_offset確定AUTO_INCREMENT列值的起點。

如果auto_increment_offset的值大於auto_increment_increment的值，則auto_increment_offset的值被忽略。例如：表內已有一些數據，就會用現在已有的最大自增值做為初始值。

MySQL 熱備份之xtrabackup

問題一：我們為什麼需要備份 ？

問題二：我們該採用哪種備份方式 ？

問題三：備份時候考慮問題 ？

我們選用哪種備份 ？

下面是如何在CentOS 7 下進行備份的具體步驟：

然後進行安裝xtrabackup

備註：

我們使用幫助查看innobackupex的幫助文檔：

進行完整備份例子：

進行增量備份例子：

要我綁定微信，不想寫，改天有時間再寫

參考鏈接：

MySQL 常用備份工具流程解析

下面我們就看一下常見的備份工具，以及目前最流行的 Percona XtraBackup 的備份流程。

MySQL 常見的備份工具主要分為三種：

這裡先說一下 binlog 備份，它只是把 binlog 又複製了一份，並且需要在邏輯備份或者物理備份的基礎上才能進行數據恢復，無法單獨進行數據恢復。

mysqldump 備份出的文件就是 sql 文件，其核心就是對每個表執行 select ，然後轉化成相應的 insert 語句。mysqldump 的備份流程大致如下：

從上面可以看出在 mysqldump 備份期間，備份到某個數據庫時，該數據庫下的表都會處於只讀狀態，無法對錶進行任何變更，直到該庫下的表備份完畢，這對於線上環境一般是無法接受的。若是指定了–master-data或者 –dump-slave 則會在備份開始時加全局讀鎖（FLUSH TABLES WITH READ LOCK），直到備份結束。當然我們可以選一個從庫進行備份，這樣就不會影響線上業務。另外使用 mysqldump 備份還有一個最大的好處，因為備份出來的是 sql 語句，所以它支持跨平台和跨版本的數據遷移或者恢復，這是物理備份無法做到的。

但是也正是因為 mysqldump 備份出來的是 sql 語句，在使用時要更加註意，否則可能會釀成大禍。例如，使用 mysqldump 常見的問題有：

所以使用 mysqldump 時一定要了解各個選項的作用，以及確認備份出來的 sql 文件里會有什麼操作，會對現有數據造成什麼影響。

Mydumper 原理與 Mysqldump 原理類似，最大的區別是引入了多線程備份，每個備份線程備份一部分表，當然並發粒度可以到行級，達到多線程備份的目的。這裡不再單獨介紹。

Percona XtraBackup 是 Percona 公司開發的一個用於 MySQL 數據庫物理熱備的備份工具，是基於 InnoDB 的崩潰恢復功能來實現的。它的基本工作原理如下：

Percona XtraBackup 在進行恢復時會應用拷貝的 redo log ，應用已提交的事務，回滾未提交的事物，將數據庫恢復到一致性狀態。因為 Percona XtraBackup 備份出來的是物理文件，所以在使用備份出的文件進行恢復或者遷移時，不會像 mysqldump 那樣會存在很多問題。

使用 XtraBackup 備份時根據備份參數設置不同，對數據庫的變更會造成不同程度的影響，具體影響會在下文分析。

通過對比發現，XtraBackup 具有對數據庫影響小，且能快速恢復的優點，在日常備份中是首選；mysqldump 使用相對更加靈活，但是使用是要注意對數據庫原有數據的影響。

備份策略主要有：全量備份和增量備份，再加上 binlog 備份。

目前去哪兒網數據庫備份主要採用 XtraBackup 全量備份 +binlog 備份。數據庫的重要級別不同，全量備份的頻率不同。備份程序主要架構如下：

說明：

Percona XtraBackup 是目前備份 MySQL 使用最廣泛的工具。在備份過程中，數據庫可以進行正常的讀寫或者其他變更操作，但是偶爾也會遇見備份引起的元數據鎖，或提交事務時發現被 binlog lock 阻塞等情況。下面我們就看一下 Percona XtraBackup 的備份流程和加鎖時機。

說明：以下對 Percona XtraBackup 的分析都是基於 2.4.23 的版本，其他版本會略有差別，但是關鍵步驟基本相同。

XtraBackup 在備份開始時，會創建一個後台線程，專門用於拷貝數據庫的 redo log 。首先 XtraBackup 會掃描每組 redo log 的頭部，找出當前的 checkpoint lsn ，然後從該 lsn 後順序拷貝所有的 redo log ，包括後續新產生的 redo log 。該線程會一直持續到將非事務表完全拷貝完成，才會安全退出。備份日誌輸出中會記錄拷貝開始時的 checkpoint lsn 。日誌輸出如下：

在拷貝ibd文件之前，會先掃描數據庫的數據文件目錄，獲取ibdata1，undo tablespaces及所有的ibd文件列表，並會記錄相應的 space id，因為在恢復時需要這些 space id來找到對應 doublewrite buffer里頁面的內容，以及對應的redo log條目。然後開始循環拷貝ibdata1，undo tablespaces及所有的ibd文件。

這裡可通過設置–parallel進行多線程備份，提高物理文件的拷貝效率。不設置則默認為1。

在所有ibd文件拷貝完成後，XtraBackup開始備份非ibd文件。這一部分的邏輯比較複雜，因為備份非ibd文件前需要加鎖，具體是否會加鎖主要受到–no-lock 參數設置的影響。

若是設置了–no-lock為TRUE，則不會使用”FLUSH TABLES WITH READ LOCK”去加全局讀鎖，但是若備份過程中對non-InnoDB表執行了DDL或者DML操作， 這會導致備份的不一致，恢復出來的數據就會有問題。所以是不建議將–no-lock為TRUE，默認值是FALSE，也就是在不指定該選項的情況下會在備份非ibd文件前加全局讀鎖。

下面我們結合源碼來看看判斷是否加全局鎖這部分的具體流程邏輯：

流程圖如下：

總結來看：

1）若–no-lock為FALSE（默認值），則先施加全局讀鎖，然後再進行拷貝文件，另外若 –safe-slave-backup 設置為TRUE ，則會在加全局鎖之前關閉SQL_THREAD線程；

2）若–no-lock為TRUE，則不會施加鎖，直接進行拷貝文件。

加鎖的邏輯主要由lock_tables_maybe實現,先看一下lock_tables_maybe源代碼，如下：

lock_tables_maybe 函數簡化處理流程如下：

1）若備份實例上已經加鎖（ LOCK TABLES FOR BACKUP / FLUSH TABLES WITH READ LOCK）或者設置lock-ddl-per-table 則直接返回；

2）若支持備份鎖，則執行LOCK TABLES FOR BACKUP；

3）若不支持備份鎖，則執行 FLUSH TABLES WITH READ LOCK。根據相應選項設置，在執行該操作前會判斷是否有執行中的DDL/DML，以及等待超時時間，是否kill 對應的未結束的事務等。

從上文中我們還看到一個參數–safe-slave-backup ，該參數的主要作用是：

若是在從庫執行的備份操作時設置了該參數，可以防止因從庫同步主庫操作，而導致XtraBackup長時間請求不到鎖而造成備份失敗。

若是設置了 –safe-slave-backup 為TRUE，那麼會執行”STOP SLAVE SQL_THREAD”，並等待Slave_open_temp_tables 為零才開始拷貝非 ibd 文件，Slave_open_temp_tables 為零說明SQL thread執行的事務都已經完成，這樣就能保證備份的一致性。並且此時也不會有在執行的事務阻塞 XtraBackup 施加全局鎖。

備份完非 ibd 文件後，將會備份 slave 和 binlog 信息。

mysql-bin.000004 2004 6b7bda9f-15f0-11ec-ba14-fa163ea367a4:1-83,9841546e-15f0-11ec-9557-fa163e736db4:1

需要注意，在支持備份鎖的實例上備份，指定了 –slave-info 或–binlog-info 均會先施加 binlog 備份鎖（ LOCK BINLOG FOR BACKUP），這會阻塞任何會更改 binlog 位點的操作。

備份完數據庫的所有文件和binlog等相關信息，備份工作就基本完成了，之後主要執行的操作如下：

1）執行”FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS”,將所有的redo log刷盤；

2）停止redo log複製線程；

3）釋放全局讀鎖（備份鎖），binlog鎖；

4）開啟SQL_THREAD；

5）拷貝ib_buffer_pool和ib_lru_dump文件；

6）生成配置文件backup-my.cnf；

7）打印備份信息到xtrabackup_info文件，這些信息主要包含備份時使用的參數信息，備份起止時間，binlog位點信息，以及將會回到的lsn點。

下面是xtrabackup_info記錄的部分內容：

加鎖對應的函數是 mdl_lock_tables ，釋放鎖對應的函數是 mdl_unlock_all，主要是執行COMMIT，結束 mdl_lock_tables 中開啟的顯式事務，來釋放MDL鎖。mdl_lock_tables 流程如下：

上面參數–lock-ddl和–lock-ddl-per-table是在 Percona XtraBackup 2.4.8 之後添加的，因為 MySQL 5.7 新增了一個叫做 Sorted Index Builds 的功能，這會導致某些 DDL 操作不記錄重做日誌而導致備份失敗。使用–lock-ddl或–lock-ddl-per-table 就會在備份開始時施加鎖，阻止 DDL 操作。

另外，若備份時指定了–lock-ddl或–lock-ddl-per-table，則在備份非 ibd 文件時就不是再有加鎖操作。

注意：LOCK TABLES FOR BACKUP和LOCK BINLOG FOR BACKUP 語句只有在支持備份鎖的實例上才會執行，Percona Server for MySQL已經在 5.6.16-64.0 版本開始支持這種更加輕量的備份鎖。

Q1: 使用 XtraBackup 備份的文件進行恢復時，恢復到哪個時間點？ A1：恢復到執行 LOCK BINLOG FOR BACKUP 或 FLUSH TABLES WITH READ LOCK 的時間點，因為這時任何改變 binlog 位點的操作都會被阻塞，redo log和binlog 是一致的。

Q2: 在開啟 binlog 的情況下，MySQL 的奔潰恢復是同時依賴 binlog 和 redo log 這兩種日誌的，為什麼XtraBackup 不用備份binlog？

A2：因為在備份中有執行LOCK BINLOG FOR BACKUP/FLUSH TABLES WITH READ LOCK，阻止了任何改變binlog位點的操作，這樣只需要根據redo log將有commit log 的事務提交，沒有commit log的事務進行回滾即可。

Q3: 使用Percona XtraBackup備份完成後redo的位點是和binlog是一樣還是比binlog多一些？

A3：通過分析備份流程可以發現備份 binlog 位點信息（加binlog鎖）是發生在停止 redo 拷貝線程前，而釋放鎖是在停止 redo 拷貝線之後，所以 redo log 會多一些。鎖住了 binlog 保證了在該 binlog 位點前已經提交的事務的 redo log 都有 commit log 的信息，未提交的事物也就沒有對應的 commit log 的信息，即便在鎖住 binlog 後有 Innodb 表新的 DML 產生的 redo log ，但是事務無法提交，也就沒有 commit log 的信息的，最後在回放的過程中對沒有 commit log 的事務進行回滾就可以了。

Q4：Percona XtraBackup什麼時候會加鎖，以及影響加鎖時間長度的因素有哪些？

A4：上面進行了分析，加鎖操作只在備份非 ibd 文件時執行，加鎖時長主要和非事務表的數量和大小有關，非事務表的數量越多，體積越大，拷貝文件所用的時間越長，那麼加鎖時間也就越長。也會和 redo log 生成的速度有關，只是 redo log 刷盤受到多個因素的影響，未及時刷盤的 redo log 一般很小。

Q5：Percona XtraBackup 和mysqldump選擇哪個更好？

A5：通過上面的的解析，若是整個實例備份，首先選擇 Percona XtraBackup ，因為對數據庫的影響最小。若只是備份某個庫表，這個就要視數據量而定，若數據量不大可以使用 mysqldump 。注意，對數據庫做備份時最好選擇業務連接最少的從庫，因為備份也會消耗一定的資源，避免影響業務。