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

寧都網(wǎng)站建設(shè)公司創(chuàng)新互聯(lián)建站,寧都網(wǎng)站設(shè)計(jì)制作，有大型網(wǎng)站制作公司豐富經(jīng)驗(yàn)。已為寧都上千家提供企業(yè)網(wǎng)站建設(shè)服務(wù)。企業(yè)網(wǎng)站搭建\外貿(mào)網(wǎng)站制作要多少錢，請(qǐng)找那個(gè)售后服務(wù)好的寧都做網(wǎng)站的公司定做！

xtrabackup的官方下載地址為

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

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

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

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

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

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

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

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

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

作用：獲取一致性數(shù)據(jù)

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

b)禁止所有表的DDL。

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

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

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

2.2、LOCK BINLOG FOR BACKUP:

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

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

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

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

三：具體innobackupex備份的過程：

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

1.get Redo LSN

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

3.FLUSH TABLES WITH READ LOCK

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

5.Get the binary log coordinates(坐標(biāo)/位點(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 系統(tǒng)表空間+事務(wù)引擎表的數(shù)據(jù)文件+后臺(tái)子進(jìn)程(IBACKUP)拷貝Redo

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

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

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

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

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

8.UNLOCK BINLOG ;

9.UNLOCK TABLES;

注意：

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

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

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

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

具體試驗(yàn)過程：

session 1執(zhí)行l(wèi)ock table t write!

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

Query OK, 0 rows affected (0.04 sec)

然后另一個(gè)窗口執(zhí)行備份：發(fā)現(xiàn)卡在Executing LOCK TABLES FOR BACKUP.，并且一直讀取的都是同一個(gè)lsn號(hào)(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ā)現(xiàn)是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操作沒提交也不會(huì)阻塞的，其實(shí)是因?yàn)闆]commit的事務(wù)產(chǎn)生的redo不需要備份，因?yàn)榛謴?fù)的時(shí)候不需要這些redo!

具體試驗(yàn)過程：

session1：執(zhí)行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)

然后開始執(zhí)行備份，發(fā)現(xiàn)是可以執(zhí)行的!說明個(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!

結(jié)論：LOCK table tablename WRITE 會(huì)阻塞LOCK TABLES FOR BACKUP的執(zhí)行,但是

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

四：執(zhí)行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

注釋：

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

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

說白了就是在所有的事務(wù)表和非事務(wù)表備份完成，獲取全局讀鎖，且使用了show master status語句獲取了binlog的pos之后，執(zhí)行刷新redo log buffer中的日志到磁盤中，然后redo log copy線程拷貝這最后的redo log日志數(shù)據(jù)。因?yàn)楫?dāng)執(zhí)行LOCK BINLOG FOR BACKUP獲取到binlog備份鎖到unlock BINLOG釋放鎖之前，不會(huì)再有請(qǐng)求進(jìn)來(所有寫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

那到地是誰先誰后呢?

首先他們各自的目的：

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

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

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

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

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

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

到此，相信大家對(duì)“mysql innobackupex的備份原理總結(jié)”有了更深的了解，不妨來實(shí)際操作一番吧！這里是創(chuàng)新互聯(lián)網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！

當(dāng)前題目：mysqlinnobackupex的備份原理總結(jié)
網(wǎng)站鏈接：http://chinadenli.net/article42/ppigec.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供全網(wǎng)營(yíng)銷推廣、標(biāo)簽優(yōu)化、網(wǎng)站收錄、ChatGPT、網(wǎng)站制作、關(guān)鍵詞優(yōu)化

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)