mysql innobackupex的備份原理總結

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

xtrabackup的官方下載地址為

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

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

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

innobackupex工具的備份過(guò)程原理：!!!

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

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

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

二：引入備份鎖的優(yōu)勢

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

作用：獲取一致性數據

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

b)禁止所有表的DDL。

優(yōu)點(diǎn)：

a)不會(huì )被大查詢(xún)阻塞。

b)不會(huì )堵塞innodb表的讀取和更新，這點(diǎn)非常重要，對于業(yè)務(wù)表全部是并innodb的情況，則備份過(guò)程中DML完全不受損。

2.2、LOCK BINLOG FOR BACKUP:

作用：獲取一致性位點(diǎn)。

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

優(yōu)點(diǎn)：

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

三：具體innobackupex備份的過(guò)程：

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

1.get Redo LSN

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

3.FLUSH TABLES WITH READ LOCK

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

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

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 系統表空間+事務(wù)引擎表的數據文件+后臺子進(jìn)程(IBACKUP)拷貝Redo

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

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

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

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

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

8.UNLOCK BINLOG ;

9.UNLOCK TABLES;

注意：

一)：避免在業(yè)務(wù)高峰期執行備份任務(wù)：

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

如果當你的redo buffer比較大，并且在第四步復制非事務(wù)表的期間產(chǎn)生的redo非常多，這就會(huì )造成第6步驟時(shí)間比較長(cháng)，進(jìn)而導致持有binlog backup鎖的時(shí)間就會(huì )變長(cháng)，最后造成數據庫的阻塞時(shí)間變長(cháng)，影響業(yè)務(wù)時(shí)間變長(cháng)，所以需要在業(yè)務(wù)少的時(shí)候來(lái)執行備份任務(wù)!

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

具體試驗過(guò)程：

session 1執行lock table t write!

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

Query OK, 0 rows affected (0.04 sec)

然后另一個(gè)窗口執行備份：發(fā)現卡在Executing LOCK TABLES FOR BACKUP.，并且一直讀取的都是同一個(gè)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)

此時(shí)查看進(jìn)程，發(fā)現是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操作沒(méi)提交也不會(huì )阻塞的，其實(shí)是因為沒(méi)commit的事務(wù)產(chǎn)生的redo不需要備份，因為恢復的時(shí)候不需要這些redo!

具體試驗過(guò)程：

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)

然后開(kāi)始執行備份，發(fā)現是可以執行的!說(shuō)明個(gè)別的dml操作不提交也不會(huì )阻塞

[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 會(huì )阻塞LOCK TABLES FOR BACKUP的執行,但是

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

四：執行innobackupex備份之前打開(kāi)genary log

看到如下具體的過(guò)程：

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

注釋?zhuān)?/strong>

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

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

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

三)：關(guān)于是先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

那到地是誰(shuí)先誰(shuí)后呢?

首先他們各自的目的：

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

innodb表的修改，通過(guò)備份innodb表修改產(chǎn)生的redo日志來(lái)實(shí)現一致性!

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

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

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

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