Percona Xtrabackupでは、MySQL Enterprise Backupと同様に、フルバックアップ(べースバックアップ)を基準とした増分バックアップを取得する機能があります。
今回の記事ではこの増分バックアップの一機能であるChanged Page Tracking(以下CPT)機能について振り返ってみようと思います。
増分バックアップのおさらい
まずは、Percona Xtrabackupの増分バックアップの流れについておさらいしておきます。
増分バックアップは、以下のように取得したものです。
※ 簡略化のために接続オプションは省略しています
- ある時点でベースバックアップを取得する
|
1 |
$ xtrabackup --backup --target-dir=/root/backup/base |
- ベースバックアップを保持した状態で、増分バックアップを取る
|
1 |
$ xtrabackup --backup --target-dir=/root/backup/inc --incremental-basedir=/root/backup/base |
このようにすることで、2で取得したバックアップはベースバックアップから2の時点までの更新分のみが含まれたバックアップファイルとなり、大幅にバックアップを保持するディスクのサイズを節約することが可能です。
増分バックアップの問題点
増分バックアップの利点としては、ベースバックアップから変更されたページのみをバックアップすることで、毎日のバックアップサイズを節約することができるというものです。
ここで期待したいのは、変更されたページのみをスキャンしてファイルに書き出してほしいという動作ですが、CPTを利用しない場合の動作としては、前回のベースバックアップのLSN(更新番号)よりも新しい現在のデータファイルのLSNを持つページを探すために全てのデータファイルのフルスキャンを実行します。
そのため、データの成長とともに増分バックアップの時間も伸びていってしまいます。
そこで、予め変更されたページを追跡するための情報を、何らかの形で保持しておき、真に変更されたページのみにアクセスしてバックアップを完結させたりと、応用しようという機能がCPTの趣旨になります。
Percona版 Changed Page Tracking機能について
CPTについては、Percona Server for MySQL 5.5.27-29.0(Released 2012/10/11ということで10年前!) にPercona社が実装しています。
この機能は、innodb_track_changed_pages をONにすることで有効化され、datadir 配下のib_modified_log_<SEQUENCE>_<START LSN>.xdb という名称のファイルにどのデータファイルが更新されたかという情報を含めることで、データベース全体のファイルをスキャンする事なく増分バックアップを行うことができるというものです。
早速ですが、この機能を使用した時とそうでない時の実行時間を比較してみました。
想定通り、その差はとても大きいものでした。
まずはPercona Server環境を作成し、db1、db2という2つのデータベースを作成しました。
そして最初にdb1には23GB程度のデータを投入しておきます。
|
1 2 3 4 5 |
$ dbdeployer deploy single ps8.0.26 --sandbox-directory=ps8026 --remote-access=% -c bind_address=0 -c innodb_track_changed_pages=ON $ ~/sandboxes/ps8026/use -e "create database db1;create database db2" $ ~/sandboxes/ps8026/sysbench oltp_common --mysql-db=db1 --tables=10 --threads=10 --table_size=10000000 prepare $ du -sh /root/sandboxes/ps8026/data/db1 23G /root/sandboxes/ps8026/data/db1 |
そしてベースバックアップを取得しておきます。
|
1 2 3 4 5 |
$ time ./pxb8026/bin/xtrabackup --backup --user=root --password=msandbox --port=8026 --host=127.0.0.1 --target-dir=/root/backup/ps8026_base real 5m33.130s user 0m3.902s sys 0m19.778s |
次にdb2にデータを投入します。このデータは100MB程度なので、差分のみを読み取っているのであれば高速に完了するはずです。
|
1 2 3 |
$ ~/sandboxes/ps8026/sysbench oltp_common --mysql-db=db2 --tables=10 --threads=10 --table_size=10000 prepare $ du -sh /root/sandboxes/ps8026/data/db2 101M /root/sandboxes/ps8026/data/db2 |
実行時のログより xtrabackup: using the changed page bitmap が確認できればChange page trackingが動作しています。
|
1 2 3 |
$ time ./pxb8026/bin/xtrabackup --backup --user=root --password=msandbox --port=8026 --host=127.0.0.1 --target-dir=/root/backup/ps8026_inc_cpt --incremental-basedir=/root/backup/ps8026_base : xtrabackup: using the changed page bitmap <-- |
結果としては4秒程度でバックアップは完了しました。
|
1 2 3 |
real 0m4.254s user 0m0.570s sys 0m0.243s |
では、同じ手順でinnodb_track_changed_pages を OFF に変更して実行した結果が以下になります。
|
1 2 3 |
real 3m20.085s user 0m3.881s sys 0m6.930s |
実際にファイルを書き込んでいないため、フルバックアップほどはかかりませんが非常に時間を要していることが確認できます。
なお、当然ながら取得されたバックアップのサイズは同じです。
|
1 2 3 4 |
$ du -sh backup/ps8026_inc_cpt/ 33M backup/ps8026_inc_cpt/ $ du -sh backup/ps8026_inc_nocpt/ 33M backup/ps8026_inc_nocpt/ |
この結果の通り、PXBユーザにとっては有用な機能ですが、Percona Server(及びPercona XtraDB Cluster) にのみ実装された機能であったため、知名度はそれほど高く無かったのではと推測します。
ちなみに、MariaDB Serverでも同様の機能が実装されていますが、XtraDBストレージエンジン専用の機能として実装されているため、あまり使われることが無かったようで、10.2の時点でdeprecatedになっています。
Percona ServerのInnoDB ストレージエンジンは実際にはXtraDBストレージエンジン(InnoDBにいくつかの機能追加を行ったもの)ですので、8.0.29以前のすべてのバージョンで利用する事は可能です。
Oracle版 Changed Page Tracking機能について
Oracle版 Changed Page Trackingの詳細なアルゴリズムについては、Oracle社のブログが非常に参考になりますので、興味があればご一読ください。
InnoDB Clone and page tracking
The Clone plugin (introduced in MySQL 8.0.17 to make cloning MySQL instances easier) introduced the infrastructure to track the modified pages within InnoDB. Since it was a bare minimum tracking facility, it was further extended to add the ability to track modified pages across restarts and crashes to make it into a full-fledged feature which MEB could use for its incremental backup. Additionally, an interface was introduced for MEB to interact with the feature to enable/disable tracking, and to fetch required page tracking data.
この内容によれば、Clone pluginの導入の一環として、MySQL 8.0.17ではCPTがInnoDBの機能として導入されています。
そして、MySQL Enterprise Backup 8.0.18 (2019-10-14, General Availability) の時点で、このCPTを使用した高速増分バックアップが可能となっています。
https://dev.mysql.com/doc/relnotes/mysql-enterprise-backup/8.0/en/news-8-0-18.html
MySQL Enterprise Backup now supports a faster way to create incremental backups by using the page tracking functionality on MySQL Servers. To use this new feature, set –incremental=page-track. See Incremental Backup Using Page Tracking for details.
Oracle版 CPTは、component_mysqlbackup.so コンポーネントを使用しており、このコンポーネントのライセンスはGPL 2.0であるため、Percona Xtrabackup 8.0.27で同コンポーネントの機能を使用して、同等の処理を行えるようになりました。
Take an incremental backup using page tracking
また、XtraDBの機能に依存することが無くなったため、Vanila MySQLでもPercona Xtrabackupの高速増分バックアップを利用することができるようになりました。
こういった背景から、Percona Xtrabackup 8.0.27 からPercona版CPTは非推奨となっており、8.0.30で機能が削除されています。
利用方法は、CPTをmysqldで開始してから、xtrabackupコマンドに--page-trackingオプションをつけて実行するというのみです。
では、早速コンポーネントをインストールした環境で実行時間を計測します。
対象環境はPercona Serverではなく、MySQL 8.0.30を使用しました。
|
1 2 3 |
$ dbdeployer deploy single mysql8.0.30 --sandbox-directory=mysql8030 --remote-access=% -c bind_address=0 $ ~/sandboxes/mysql8030/use -e "INSTALL COMPONENT \"file://component_mysqlbackup\";" $ ~/sandboxes/mysql8030/use -e "SELECT mysqlbackup_page_track_set(true);" # CPTの開始 |
テスト内容は同じです。
ベースバックアップを取得する時点から--page-trackingオプションを指定することでも、CPTを開始することができますが、MySQL Enterprise Backupのマニュアルにも記載のある通り、事前に mysqlbackup_page_track_set(true) を実行しておくほうがクリーンでよいでしょう。
|
1 |
$ time ./pxb8030/bin/xtrabackup --backup --page-tracking --user=root --password=msandbox --port=8030 --host=127.0.0.1 --target-dir=/root/backup/mysql8030_base_new_cpt |
増分バックアップを実行します。
|
1 2 3 4 5 |
$ time ./pxb8030/bin/xtrabackup --backup --page-tracking --user=root --password=msandbox --port=8030 --host=127.0.0.1 --target-dir=/root/backup/mysql8030_inc_new_cpt --incremental-basedir=/root/backup/mysql8030_base_new_cpt real 0m2.969s user 0m0.482s sys 0m0.185s |
若干ですが、Percona 版CPTよりも、高速に増分バックアップが完了しました。
最後にドキュメントに基づき、この機能の注意点についても触れておきます。
-
本機能を使用する場合、増分バックアップのサイズに応じてPercona XtraBackupが追加のメモリを消費します(例.200GBの増分バックアップあたりで約100MBのメモリ)。メモリが確保できない場合、エラー終了します。
-
フルバックアップ時の
--page-trackingオプション、もしくは、SELECT mysqlbackup_page_track_set(true)を実行することでCPTはページトラッキングデータをdatadir/#mebに保存します。このディレクトリ以下のファイルは、増加し続け、次回のフルバックアップを取得するまで不要になりませんので、一定量の追加のディスクを消費します。
フルバックアップの取得前に以下のようにCPT用のファイルを削除する処理を組み込むのが良いでしょう。12345$ SELECT mysqlbackup_page_track_set(false);$ SELECT mysqlbackup_page_track_purge_up_to(9223372036854775807);/* Specify the LSN up to which you want to purge page tracking data. /9223372036854775807 is the highest possible LSN which purges all page tracking files.*/$ SELECT mysqlbackup_page_track_set(true); -
CPTの有効な期間中にbug#106163のように、REDOログを発生させないインデックス作成の方法(LOCK=EXCLUSIVE, ALGORITHM=INPLACE)を行った場合、それらの操作が増分バックアップから欠損します。これは該当する操作を行わないように運用カバーする他ありませんが、すでにアップストリームにパッチも提供されていますので、近い将来のFIXを待ちましょう。
まとめ
Percona Xtrabackup の増分バックアップがより実用的になったということで、今回試してみました。
バックアップ時間が短くなるとともに、当然ながらバックアップにかかる負荷も非常に少なくなりますので、夜間バックアップが長期化してしまいサービス時間帯までに終わらなくなってきたなどといったお悩みがある方は、 --page-tracking オプションを試してみていただければと思います。
