這篇文章將為大家詳細(xì)講解有關(guān)如何通過Xtrabackup日志來恢復(fù)檢查點(diǎn)文件，小編覺得挺實(shí)用的，因此分享給大家做個(gè)參考，希望大家閱讀完這篇文章后可以有所收獲。

站在用戶的角度思考問題，與客戶深入溝通，找到青川網(wǎng)站設(shè)計(jì)與青川網(wǎng)站推廣的解決方案，憑借多年的經(jīng)驗(yàn)，讓設(shè)計(jì)與互聯(lián)網(wǎng)技術(shù)結(jié)合，創(chuàng)造個(gè)性化、用戶體驗(yàn)好的作品，建站類型包括：成都網(wǎng)站設(shè)計(jì)、成都做網(wǎng)站、企業(yè)官網(wǎng)、英文網(wǎng)站、手機(jī)端網(wǎng)站、網(wǎng)站推廣、域名注冊、網(wǎng)站空間、企業(yè)郵箱。業(yè)務(wù)覆蓋青川地區(qū)。

前幾天有個(gè)朋友問我的問題，是在xtrabackup的時(shí)候，沒有特別保留checkpoints文件，想問問能否通過日志來推理得到里面的LSN信息呢，背景條件是做全備。

一個(gè)參考的日志如下：

171208 11:21:54 [01] Copying ./sbtest/dba_xtrabackupresult.frm to /data/backup/sbtest/dba_xtrabackupresult.frm

171208 11:21:54 [01] ...done

171208 11:21:54 Finished backing up non-InnoDB tables and files

171208 11:21:54 [00] Writing /data/backup/xtrabackup_binlog_info

171208 11:21:54 [00] ...done

171208 11:21:54 Executing FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS...

xtrabackup: The latest check point (for incremental): ' 3985406424'

xtrabackup: Stopping log copying thread.

....171208 11:21:55 >> log scanned up to ( 4060591382)

171208 11:21:55 >> log scanned up to ( 4060591382) 171208 11:21:55 Backup created in directory '/data/backup/'

MySQL binlog position: filename 'mysqlbin.000017', position ' 96607849'

171208 11:21:55 [00] Writing /data/backup/backup-my.cnf

171208 11:21:55 [00] ...done

171208 11:21:55 [00] Writing /data/backup/xtrabackup_info

171208 11:21:55 [00] ...done

xtrabackup: Transaction log of lsn ( 3597739074) to ( 4060591382) was copied.

171208 11:21:57 completed OK!

可以看到日志里面出現(xiàn)了很多的LSN的信息，首先是能夠根據(jù)日志得到LSN的信息，然后是如果可以的話，這些LSN是如何做選擇的。

我們必然要引入xtrabackup的原理和過程圖

總體來說xtrabackup會(huì)通過物理拷貝的方式，然后來補(bǔ)充增量的數(shù)據(jù)變化。整個(gè)過程和Oracle的熱備有些類似。日志中的信息相對來說還是很全的，作為參考是足夠的。

然后如何恢復(fù)呢，我們需要知道有哪些LSN是需要的。

一般來說，一個(gè)checkpoints文件需要如下的LSN信息

[root@tk-dba-mysql10-202 backup]# cat *checkpoints

backup_type = full-backuped

from_lsn = xx

to_lsn = xx

last_lsn = xx

compact = 0

recover_binlog_info = 0

為了避免干擾，我做了一些過濾，可以看到基本是由FROM_LSN,TO_LSN,LAST_LSN組成的，如果是全備，from_lsn應(yīng)該是0，如果數(shù)據(jù)庫沒有負(fù)載，或者在這個(gè)備份的過程中沒有什么寫入，那么to_lsn和last_lsn是一致的。

可是上面的日志很明顯，是在數(shù)據(jù)庫比較繁忙的情況下做的備份，所以產(chǎn)生了很多的臨界點(diǎn)的 LSN,所以通過這些細(xì)節(jié)就需要我們知道整個(gè)xtrabackup的過程中LSN的變化

我就不兜圈子了，通過模擬，得到的一個(gè)初步結(jié)論如下：

[root@tk-dba-mysql10-202 backup]# cat *checkpoints

backup_type = full-backuped

from_lsn = 0

to_lsn = 3985406424

last_lsn = 4060591382

compact = 0

recover_binlog_info = 0

這個(gè)過程是怎么模擬的呢，是在前端通過sysbench做壓力測試，然后使用xtrabackup來備份。整個(gè)過程還是比較快的，大概半個(gè)小時(shí)內(nèi)能夠驗(yàn)證完成。

關(guān)于“如何通過Xtrabackup日志來恢復(fù)檢查點(diǎn)文件”這篇文章就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，使各位可以學(xué)到更多知識(shí)，如果覺得文章不錯(cuò)，請把它分享出去讓更多的人看到。

本文標(biāo)題：如何通過Xtrabackup日志來恢復(fù)檢查點(diǎn)文件-創(chuàng)新互聯(lián)
文章起源：http://weahome.cn/article/gjsed.html