mysql innobackupex的備份原理總結

139次閱讀

共計 8321 個字符，預計需要花費 21 分鐘才能閱讀完成。

本篇內容主要講解“mysql innobackupex 的備份原理總結”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓丸趣 TV 小編來帶大家學習“mysql innobackupex 的備份原理總結”吧!

xtrabackup 的官方下載地址為

http://www.percona.com/software/percona-xtrabackup。

xtrabackup 包含兩個主要的工具，即 xtrabackup 和 innobackupex，二者區別如下：

1 xtrabackup 只能備份 innodb 和 xtradb 兩種引擎的表，而不能備份 myisam 引擎的表;2 innobackupex 是一個封裝了 xtrabackup 的 Perl 腳本，支持同時備份 innodb 和 myisam，但在對 myisam 備份時需要加一個全局的讀鎖。還有就是 myisam 不支持增量備份。

innobackupex 工具的備份過程原理：!!!

一：早期版本的 innobackupex 備份過程如下圖所示：

這里的 FTWRL(flush tables with read lock)把鎖持有的時間主要與非 innodb 表的數據量有關，如果非 innodb 表數據量很大，備份很慢，那么持有鎖的時間就會很長。即使全部是 innodb 表，也會因為有 mysql 庫系統表存在，導致會鎖一定的時間。為了解決這個問題，Percona 公司對 Mysql 的 Server 層做了改進，引入了 BACKUP LOCK(備份鎖)，具體而言，通過 LOCK TABLES FOR BACKUP 命令來獲取一致性數據(包括非 innodb 表); 通過 LOCK BINLOG FOR BACKUP 來獲取一致性位點，盡量減少因為數據庫備份帶來的服務受阻!

https://www.percona.com/doc/percona-server/5.6/management/backup_locks.html#interaction-with-other-global-locks — 官方文檔的位置

二：引入備份鎖的優勢

2.1、LOCK TABLES FOR BACKUP: 只阻塞非事務表的操作! 不阻塞 innodb 表的 dml

作用：獲取一致性數據

a)禁止非事務引擎 (非 InnoDB) 表寫入(也即 DML)。

b)禁止所有表的 DDL。

優點：

a)不會被大查詢阻塞。

b)不會堵塞 innodb 表的讀取和更新，這點非常重要，對于業務表全部是并 innodb 的情況，則備份過程中 DML 完全不受損。

2.2、LOCK BINLOG FOR BACKUP:

作用：獲取一致性位點。

a)禁止對 binlog 的位點操作(不允許 DML、DDL)

優點：

a)時間短，對 db 的影響很小。

三：具體 innobackupex 備份的過程：

3.1、低版本的 innobackupex，(2.2.0)的流程：

1.get Redo LSN

2.copy 系統表空間 + 事務引擎表的數據文件 + 后臺子進程 (IBACKUP) 拷貝 Redo

3.FLUSH TABLES WITH READ LOCK

4.copy 所有 *.frm 文件，非事務引擎表 (MyISAM、ARCHIVE 等) 數據 + 索引文件

5.Get the binary log coordinates(坐標 / 位點)

6.finalize the background copy of REDO log

7.unlock tables;

3.2、高版本的 innobackupex，(也就是 =2.2.0 版本)的流程：(增加了備份鎖，不再使用 FLUSH TABLES WITH READ LOCK)

1.get Redo LSN

2.copy 系統表空間 + 事務引擎表的數據文件 + 后臺子進程 (IBACKUP) 拷貝 Redo

3.LOCK TABLES FOR BACKUP(這時候一直在拷貝 redo)

4.copy 所有 *.frm 文件，非事務引擎表 (MyISAM、ARCHIVE 等) 數據 + 索引文件(這時候一直在拷貝 redo)

5.LOCK BINLOG FOR BACKUP (為了得到一致性的 binlog 點位，所有需要寫 binlog 的操作不能執行)

6.finalize the background copy of REDO log (包括 flush redo bufer 到磁盤)

7.get the binary log coordinates(坐標 / 位點)

8.UNLOCK BINLOG ;

9.UNLOCK TABLES;

注意：

一)：避免在業務高峰期執行備份任務：

如果第四步驟完成之后，開始執行 LOCK BINLOG FOR BACKUP，獲取到 binlog 鎖之后，然后 SHOW MASTER STATUS 來獲取一致性的 binlog, 然后開始 flush redo buffer 里的 redo 到磁盤(具體命令：FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS)，以便于復制所有的 redo, 這里會有個問題，

如果當你的 redo buffer 比較大，并且在第四步復制非事務表的期間產生的 redo 非常多，這就會造成第 6 步驟時間比較長，進而導致持有 binlog backup 鎖的時間就會變長，最后造成數據庫的阻塞時間變長，影響業務時間變長，所以需要在業務少的時候來執行備份任務!

二)：mysql RR 和 RC 隔離級別下，LOCK table tablename WRITE 會阻塞 LOCK TABLES FOR BACKUP 的執行, 但是 lock table tablename read 以及 LOCK TABLES FOR BACKUP 都不會阻塞 LOCK TABLES FOR BACKUP 的執行!

具體試驗過程：

session 1 執行 lock table t write!

root@localhost : liuwenhe 20:48:15 LOCK table t WRITE;

Query OK, 0 rows affected (0.04 sec)

然后另一個窗口執行備份：發現卡在 Executing LOCK TABLES FOR BACKUP.，并且一直讀取的都是同一個 lsn 號 (56989476423) 的 redo!

[root@beijing-fuli-hadoop-04 ~]# innobackupex -uroot -p V@1qaz /data/backup/

200310 21:00:17 [01] Copying ./sys/sys_config.ibd to /data/backup/2020-03-10_21-00-09/sys/sys_config.ibd

200310 21:00:17 [01] …done

200310 21:00:17 Executing LOCK TABLES FOR BACKUP…

200310 21:00:17 log scanned up to (56989476423)

200310 21:00:18 log scanned up to (56989476423)

200310 21:00:19 log scanned up to (56989476423)

200310 21:00:20 log scanned up to (56989476423)

此時查看進程，發現是 LOCK TABLES FOR BACKUP 在等待 Waiting for backup lock

root@localhost : (none) 17:33:17 show processlist;

+—-+————-+———–+———-+———+——–+——————————————————–+————————+———–+—————+

+—-+————-+———–+———-+———+——–+——————————————————–+————————+———–+—————+

| 3 | system user | | NULL | Connect | 100359 | Waiting for master to send event | NULL | 0 | 0 |

| 4 | system user | | NULL | Connect | 75664 | Slave has read all relay log; waiting for more updates | NULL | 0 | 0 |

| 17 | root | localhost | liuwenhe | Sleep | 0 | | NULL | 0 | 0 |

+—-+————-+———–+———-+———+——–+——————————————————–+————————+———–+—————+

5 rows in set (0.00 sec)

dml 操作沒提交也不會阻塞的，其實是因為沒 commit 的事務產生的 redo 不需要備份，因為恢復的時候不需要這些 redo!

具體試驗過程：

session1：執行 dml 操作不 commit

root@localhost : liuwenhe 17:34:44 start transaction;

Query OK, 0 rows affected (0.00 sec)

root@localhost : liuwenhe 17:35:59 delete from liu where id=100;

Query OK, 1 row affected (0.07 sec)

然后開始執行備份，發現是可以執行的! 說明個別的 dml 操作不提交也不會阻塞

[root@beijing-fuli-hadoop-04 ~]# innobackupex -uroot -p V@1qaz /data/backup/

xtrabackup: Transaction log of lsn (53883827670) to (53883827695) was copied.

200310 17:40:24 completed OK!

結論：LOCK table tablename WRITE 會阻塞 LOCK TABLES FOR BACKUP 的執行, 但是

lock table tablename read 以及 LOCK TABLES FOR BACKUP 都不會阻塞 LOCK TABLES FOR BACKUP 的執行! 一定要注意當你 mysqldump 備份的數據文件里面是帶 lock table name write 的，注意不要和物理備份沖突了，導致物理備份被阻塞而執行時間過長

四：執行 innobackupex 備份之前打開 genary log

看到如下具體的過程：

2020-03-05T12:20:40.187735Z 221 Connect root@localhost on using Socket

2020-03-05T12:20:40.188456Z 221 Query set autocommit=1

2020-03-05T12:20:40.194768Z 221 Query SET SESSION wait_timeout=2147483

2020-03-05T12:20:40.224959Z 221 Query SELECT CONCAT(@@hostname, @@port)

2020-03-05T12:20:40.245466Z 221 Quit

2020-03-05T12:20:40.257504Z 222 Connect root@localhost on using Socket

2020-03-05T12:20:40.257854Z 222 Query SET SESSION wait_timeout=2147483

2020-03-05T12:20:40.258527Z 222 Query SET SESSION autocommit=1

2020-03-05T12:20:40.258759Z 222 Query SET NAMES utf8

2020-03-05T12:20:40.258983Z 222 Query SHOW VARIABLES

2020-03-05T12:20:40.280937Z 222 Query SHOW ENGINE INNODB STATUS

2020-03-05T12:20:40.465253Z 222 Query SELECT PLUGIN_NAME, PLUGIN_LIBRARY FROM information_schema.plugins WHERE PLUGIN_STATUS = ACTIVE AND PLUGIN_TYPE = KEYRING

2020-03-05T12:20:40.467169Z 222 Query SELECT

CONCAT(table_schema, / , table_name), engine

FROM information_schema.tables

WHERE engine NOT IN (

MyISAM , InnoDB , CSV , MRG_MYISAM

)

AND table_schema NOT IN (

performance_schema , information_schema , mysql

)

2020-03-05T12:20:51.604076Z 222 Query SET SESSION lock_wait_timeout=31536000

2020-03-05T12:20:51.604317Z 222 Query LOCK TABLES FOR BACKUP

2020-03-05T12:20:54.525210Z 222 Query LOCK BINLOG FOR BACKUP

2020-03-05T12:20:54.525306Z 222 Query SHOW MASTER STATUS

2020-03-05T12:20:54.525417Z 222 Query SHOW VARIABLES

2020-03-05T12:20:54.759369Z 222 Query FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS

2020-03-05T12:20:54.968260Z 222 Query UNLOCK BINLOG

2020-03-05T12:20:54.968348Z 222 Query UNLOCK TABLES

2020-03-05T12:20:55.003416Z 222 Query SELECT UUID()

2020-03-05T12:20:55.017367Z 222 Query SELECT VERSION()

2020-03-05T12:20:55.245540Z 222 Quit

注釋：

一)：首先會話級別修改 lock_wait_timeout 參數(默認就是 31536000 秒)，保證當執行 lock binlog for backup 之后事務不會由于等待元數據鎖時間過長而 timeout! 獲取元數據鎖的超時時間，例如 alter table。這個適合用于除了系統表之外的所有表(mysql 庫之外)

二)：FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS 的作用是：將 innodb 層的重做日志持久化到磁盤，但是不觸發 binlog buffer 涮新到磁盤; 然后會有相關進程來進行拷貝 redo。

說白了就是在所有的事務表和非事務表備份完成，獲取全局讀鎖，且使用了 show master status 語句獲取了 binlog 的 pos 之后，執行刷新 redo log buffer 中的日志到磁盤中，然后 redo log copy 線程拷貝這最后的 redo log 日志數據。因為當執行 LOCK BINLOG FOR BACKUP 獲取到 binlog 備份鎖到 unlock BINLOG 釋放鎖之前，不會再有請求進來(所有寫 binlog 的操作都不能進行)，保證 binlog 是不能變化的，進而保證了一致性的 binlog 點位!

三)：關于是先 UNLOCK BINLOG 還是先 UNLOCK TABLES?

官方文檔看到的是：先 unlock binlog 后 unlock tables

但是在 genary log 里看到的是：先 unlock binlog 后 unlock tables：

2020-03-05T12:20:51.604076Z 222 Query SET SESSION lock_wait_timeout=31536000

2020-03-05T12:20:51.604317Z 222 Query LOCK TABLES FOR BACKUP

2020-03-05T12:20:54.525210Z 222 Query LOCK BINLOG FOR BACKUP

2020-03-05T12:20:54.525306Z 222 Query SHOW MASTER STATUS

2020-03-05T12:20:54.525417Z 222 Query SHOW VARIABLES

2020-03-05T12:20:54.759369Z 222 Query FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS

2020-03-05T12:20:54.968260Z 222 Query UNLOCK BINLOG

2020-03-05T12:20:54.968348Z 222 Query UNLOCK TABLES

2020-03-05T12:20:55.003416Z 222 Query SELECT UUID()

2020-03-05T12:20:55.017367Z 222 Query SELECT VERSION()

2020-03-05T12:20:55.245540Z 222 Quit

那到地是誰先誰后呢?

首先他們各自的目的：

LOCK TABLES FOR BACKUP：是為了得到一致性的數據，阻塞非 innodb 表的修改，它不阻塞

innodb 表的修改，通過備份 innodb 表修改產生的 redo 日志來實現一致性!

LOCK BINLOG FOR BACKUP：是為了得到一個一致性的 gtid 點，期間所有表 (包括 innodb 表) 的修改操作都被阻塞，也就是所有寫 binlog 的操作都被阻塞，這樣 binlog 就不變化了，進而可以得到一致性的 binlog 點位!

可以看出來，binlog backup 鎖 (阻塞所有表的修改) 比 lock tables for backup(只阻塞非 innodb 表修改)的范圍廣，所以我認為當 LOCK BINLOG FOR BACKUP 執行后，原則上 LOCK TABLES FOR BACKUP 這個鎖就可以被釋放了(因為 lock binlog 能起到 lock tables for backup 的作用)，如果沒有 unlock binlog，即便是你 unlock tables 了，那么依舊是整個實例無法進行任何寫 binlog 的操作，所以這個順序如果 mysql 設計的時候，沒有考慮的話，那么這個順序就沒有確定的順序，也就是都可以先執行，

如果是這樣的話，那么 unlock binlog 是要等待 show master status 完成，并且 flush redo log 完成并且完成拷貝 redo 的操作，而 unlock tables 需要等待拷貝所有 *.frm 文件，非事務引擎表 (MyISAM、ARCHIVE 等) 數據 + 索引文件的操作完成，并且 LOCK BINLOG FOR BACKUP 之后，才能 unlock tables, 如果備份的時候數據庫操作特別少，那么 show master status 和 flush redo log 完成并且完成拷貝 redo 的操作就特別快，那么 unlock binlog 就可能比 unlock tables 先完成，如果數據庫比較繁忙的話，那么就是先 unlock tables 然后 unlock binlog!

比較遺憾的是，我模擬大量的 insert 操作的時候，同時備份，結果 general log 里面還是先 unlock binlog 后 unlock tables，所以我很迷惑到底官方文檔寫的準確性！

到此，相信大家對“mysql innobackupex 的備份原理總結”有了更深的了解，不妨來實際操作一番吧！這里是丸趣 TV 網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！

正文完