通過Xtrabackup日誌來恢復檢查點檔案
最近積壓了很多朋友的問題,我想起來的時候就回復一下,別見怪,不是我有勢利眼。
前幾天有個朋友問我的問題,是在xtrabackup的時候,沒有特別保留checkpoints檔案,想問問能否通過日誌來推理得到裡面的LSN資訊呢,背景條件是做全備。
一個參考的日誌如下:
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!
可以看到日誌裡面出現了很多的LSN的資訊,首先是能夠根據日誌得到LSN的資訊,然後是如果可以的話,這些LSN是如何做選擇的。
我們必然要引入xtrabackup的原理和過程圖
總體來說xtrabackup會通過物理拷貝的方式,然後來補充增量的資料變化。整個過程和Oracle的熱備有些類似。日誌中的資訊相對來說還是很全的,作為參考是足夠的。
然後如何恢復呢,我們需要知道有哪些LSN是需要的。
一般來說,一個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應該是0,如果資料庫沒有負載,或者在這個備份的過程中沒有什麼寫入,那麼to_lsn和last_lsn是一致的。
可是上面的日誌很明顯,是在資料庫比較繁忙的情況下做的備份,所以產生了很多的臨界點的 LSN,所以通過這些細節就需要我們知道整個xtrabackup的過程中LSN的變化
我就不兜圈子了,通過模擬,得到的一個初步結論如下:
[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
這個過程是怎麼模擬的呢,是在前端通過sysbench做壓力測試,然後使用xtrabackup來備份。整個過程還是比較快的,大概半個小時內能夠驗證完成。來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/23718752/viewspace-2148801/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 如何通過trn日誌檔案恢復SQL ServerSQLServer
- 【恢復】Redo日誌檔案丟失的恢復
- 恢復歸檔日誌檔案的常用方法
- 恢復案例:無歸檔,丟失全部控制檔案、日誌檔案恢復案例
- 【備份恢復】恢復 丟失已歸檔重做日誌檔案
- 聯機重做日誌檔案的恢復
- RMAN恢復案例:無恢復目錄,丟失全部資料檔案、控制檔案、日誌檔案恢復
- 丟失所有重做日誌檔案的恢復例子丟失所有重做日誌檔案的恢復例子如下:
- 第15 章 物理日誌記錄、檢查點和快速恢復; 第16 章 管理物理日誌
- 非歸檔丟失日誌檔案的恢復
- 【備份恢復】恢復inactive狀態的日誌檔案
- oracle丟失inactive日誌檔案的恢復操作過程Oracle
- oracle丟失日誌檔案的恢復( 轉)Oracle
- 跳過歸檔日誌的非常規恢復(一)
- Oracle使用備份檔案集恢復歸檔日誌Oracle
- 通過JVM日誌來進行安全點分析JVM
- oracle丟失active或current日誌檔案的恢復操作過程Oracle
- DG歸檔日誌缺失恢復
- 丟失聯機重做日誌檔案的恢復
- 在歸檔模式下丟失日誌檔案的恢復模式
- 非歸檔模式下,丟失日誌檔案的一次恢復過程模式
- 一次日誌檔案損壞的恢復
- 丟失已歸檔日誌檔案下恢復資料庫資料庫
- REDO日誌損壞,非歸檔模式資料檔案恢復模式
- 通過事務日誌恢復SqlServer資料庫到一個特定的時間點SQLServer資料庫
- mysql通過frm、idb檔案恢復資料MySql
- 【備份與恢復】恢復受損的複用聯機重做日誌檔案
- 恢復重做日誌
- 恢復控制檔案後,沒有最後一個歸檔日誌的備份,也沒新增歸檔日誌資訊,怎麼恢復?
- inactive狀態日誌組檔案損壞的恢復
- oracle dg 歸檔日誌恢復情況Oracle
- 無歸檔日誌恢復rman資料
- 冷備份+歸檔日誌的恢復
- 資料恢復新姿勢——通過ibd和frm檔案恢復資料資料恢復
- 通過Snapshot Control File 恢復控制檔案
- 日誌檔案過大清理
- 通過檔案控制程式碼恢復刪除的資料檔案
- Oracle控制檔案在缺失歸檔日誌的情況下的恢復Oracle