mysql innobackupex的備份原理總結

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

+----+-------------+-----------+----------+---------+--------+--------------------------------------------------------+------------------------+-----------+---------------+

| Id | User | Host | db | Command | Time | State | Info | Rows_sent | Rows_examined |

+----+-------------+-----------+----------+---------+--------+--------------------------------------------------------+------------------------+-----------+---------------+

| 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 |

| 21 | root | localhost | NULL | Query | 164 | Waiting for backup lock | LOCK TABLES FOR BACKUP | 0 | 0 |

| 23 | root | localhost | NULL | Query | 0 | starting | show processlist | 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的備份原理總結”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！