Percona xtrabackup備份細節是怎樣的

今天就跟大家聊聊有關Percona xtrabackup備份細節是怎樣的，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。

xtrabackup為了完成備份會做兩個主要的工作：
任務一：
xtrabackup會在后臺開啟一個log-copying的線程，該線程會對redo log file進行監視，并把從lsn1(lsn1是Xtrabackup在啟動時會從redo log file中獲取最近一次的checkpoint對應的log sequence number lsn1 )開始增加的數據塊（日志記錄）不斷的復制到備份集中一個叫xtrabackup_logfile的文件里面。日志copy操作，會在整個備份過程中一直進行，因為備份集做恢復的時候需要從lsn1開始到備份結束時所有日志記錄，恢復原理就是 crash recover 的過程。
注：
log-copying 線程每一秒都會去 check 事務日志，看是否有新寫入的需要copy走的日志項.但是有種可能性：
log-copying 線程的copy的速度比寫入redofile 的速度慢，有可能事務日志循環一周，造成會有一部分日志
還沒有被讀取就被覆蓋了,此時 log—copying 線程會報錯，備份失敗。
…
任務二：
xtrabackup在進行copy redo 日志的同時會copy innodb的data file ， 當然這不是簡單的復制，它使用了跟innodb類似的方式訪問數據文件,訪問數據字典，并以數據頁為單位來進行copy。具體的細節如下：
  xtrabackup是以讀寫的方式打開數據文件的，盡管它不會修改數據。這是因為它使用內置的innodb的lib庫
來訪問數據文件的，也隱含了你要用對數據文件有讀寫權限的用戶來進行備份。innodb的lib庫使用讀寫方式打
開是因為正常情況下代開文件就預示著寫數據。


  在copy數據到備份目標目錄的過程中，xtrabackup 每次讀取1M數據（不可配置），copy日志文件的時候，
每次讀寫512字節，同樣不可以配置。數據讀取之后，xtrabackup會對這1M的緩存數據塊進行掃描，并對每一個
數據頁使用buf_page_is_corrupted()函數進行驗證，看起是否損壞，如果page損壞了，對其重新讀取并重新
驗證。如果重讀10次都失敗了，本次備份失敗，那么備份失敗。
注 ： (It skips this check on the doublewrite buffer)
xtraback備份結尾
當數據文件復制完成，xtrabackup 會停掉log-copying線程，并在備份目錄下創建一個
xtrabackup_checkpoints 的文件，該文件包含備份的類型，還有備份開始時的log sequence number，還有結束時的log sequence number 。備份過程中，我們會看到數據文件copy信息，也會看到日志復制線程重復的掃描日志文件，并進程copy的信息，信息如下：
>> log scanned up to (3646475465483)
>> log scanned up to (3646475517369)
>> log scanned up to (3646475581716)
>> log scanned up to (3646475636841)
>> log scanned up to (3646475718082)
>> log scanned up to (3646475988095)
>> log scanned up to (3646476048286)
>> log scanned up to (3646476102877)
>> log scanned up to (3646476140854)
[01] Copying /usr/local/mysql/var/ibdata1
    to /usr/local/mysql/Backups/2011-04-18_21-11-15/ibdata1
[01]        ...done
the log file thread repeatedly scanning the log files and copying from it

看完上述內容，你們對Percona xtrabackup備份細節是怎樣的有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注億速云行業資訊頻道，感謝大家的支持。