【編者按：上期我們分析和了解了鼎甲對MySQL的邏輯備份。本期我們重點解析鼎甲對MySQL的物理備份。】

上期回顧：

MySQL全方位災備保護 Ⅰ 應用趨勢

MySQL全方位災備保護 Ⅱ 邏輯備份

在實現MySQL的邏輯備份后，鼎甲即刻投入對MySQL數據庫物理備份的研究和實現，通過對數據庫文件的備份來提高備份效率和解決鎖表問題。

物理備份包括了完全備份、增量備份、日志備份。

主要是通過定制作業策略來備份MySQL的數據文件和日志文件，由于是基于數據文件的復制，所以物理備份比邏輯備份的速度快很多，而且采用的是熱備份，在備份過程中也減少影響業務系統對數據庫的使用。

DBackup在進行物理備份時，支持自適應MyISAM、InnoDB等多種存儲引擎，根據不同的引擎來提取對應的文件進行備份。

在MyISAM存儲引擎中，每張數據表都有3個文件，分別為表結構定義文件（frm）,表索引文件（MYI）,表數據文件（MYD）。

對于InnoDB存儲引擎，增加了事務處理、回滾、崩潰修復能力和多版本并發控制的事務安全，數據文件更為復雜，每個InnoDB都會存在表結構定義文件（frm），而表索引和表數據存放在表空間文件【共享表空間文件（ibdata1），獨享表空間（ibd）】中，另外還有相關的日志文件（binary log、redo log、undo log、errorlog等）。

在MySQL的物理備份中包括兩部分的備份數據：對數據文件的完全備份和增量備份，對二進制日志文件的復制。

這兩部分備份數據的備份處理流程不一樣，需要配置在不同的備份任務中完成。

數據文件備份

DBackup同時支持對InnoDB和MyISAM引擎的數據文件和表數據進行備份，對InnoDB引擎中的數據文件，采用文件復制方式一頁一頁地復制InnoDB的數據，而且不鎖定表，在文件復制的過程中，需要時刻監控著redo log的變化，一旦log發生變化，就即刻同步添加到事務日志文件中，直至復制完所有數據文件，才停止對redo log的監控和同步。

完成對ibd文件的備份后，將開始對非InnoDB表數據進行備份，包括MyISAM表和InnoDB表結構等信息，需要采用flush tables with lock來獲得一個讀鎖，保障復制數據的一致性位點，復制完成后將進行解鎖。

DBackup對數據文件的備份處理，通過同步事務日志信息，并整合到備份集中，在進行數據恢復時將保障數據文件和日志文件的一致性。

而對備份中的加鎖處理，也進行了優化，實現定向備份鎖技術，只有在備份非InnoDB表數據的時候才啟動加鎖處理，這有效地縮短了備份中的鎖表時間，大大降低了因為數據庫備份對業務服務的中斷影響。

日志備份

日志備份是對二進制日志（binary log）文件的定制備份，二進制日志文件用來記錄所有用戶對數據庫操作，即記錄用戶對數據庫操作的sql語句。

binary log的文件有兩種類型：index文件有.index的后綴；log文件用.NNNNNN后綴命名，如mysql-bin.000001等。

對二進制日志文件的備份，首先需要啟動開啟 MySQL 的二進制日志記錄，常規的啟動方式是需要在MySQL的服務器上，通過后臺指令輸入來進行配置啟動。

DBackup為了簡化配置流程，提升用戶使用感知，把二進制日志的啟動設置，整合到前臺的配置頁面中，用戶只需做簡單配置后即可啟動。

物理備份的實現，雖然提升了MySQL的備份效率，且降低了備份過程中對業務訪問數據的影響。

但由于備份是定時策略，無法做到密集型的備份，也就是在災難恢復時，會丟失上次備份到故障點發生之間的數據。

為了提升數據恢復的RPO，鼎甲開始MySQL連續日志實時保護的研究和實現。

下期預告：MySQL全方位災備保護 Ⅳ 連續日志備份