PerconaといえばXtraBackup!! といっても過言ではないこの機能。

バックアップ手法はいくつかあれど、少なくともmysqldumpを使うくらいならXtraBackupを使っとけばいいと思います。手始めに、簡単な使い方から紹介していきます。

はじめに

インストールについては前にまとめてあり、単にパッケージインストールするだけになっています。

バージョンは必ず最新を使ってください。だいぶ安定してきたとはいえ、バグフィックスは常にされており、特に v2.0.0 では8GBを超えるデータの際にエラーが起こるため、修正されています（参照：Announcing Percona XtraBackup 2.0.1）。

XtraBackupはmysqldumpと比べると、バックアップ作成速度が遅くなったり、データ容量が大きくなったりする場合がありますが、その代わりに以下のようなメリットがあります。

データロックを必要としない（XtraDBのみの場合に限る）

リストア速度が速い

様々な機能：差分、並列、ストリーミング など

有償であるMySQL Enterprise Backupと比べても優秀であるとも謳っています。

実際の運用では xtrabackup コマンドではなく、より多様な機能を持たせたラッパースクリプトである innobackupex を使用することになると思いますが、まずは xtrabackup単体で理解してからの方がよいです。

xtrabackupの設定

xtrabackupはログファイルを作成したりするので、MySQLの設定を必要とします。設定は稼働中のMySQLからではなく、全て my.cnf ファイルから読み込むので、変わった書き方をしているとxtrabackupがパースできないかもしれません。

xtrabackup –help

これはヘルプだけでなく使用しようとする設定値なども表示されます。

my.cnf の読み込み順序

公式の Using Option Files と少し違っていて、こんな感じです。

/etc/my.cnf

/etc/mysql/my.cnf

/usr/local/etc/my.cnf

~/.my.cnf

実際のVariables

下部には実行時に利用する値が見れますので、一度確認しておくとよいです。

xtrabackup –print-defaults

これで、コマンドライン形式で、実行時の設定値を確認できます。

xtrabackup –print-param

中でも、これで表示される設定が、xtrabackupにおいて重要な項目になります。

–print-param 以外の設定

innodb_file_per_table が設定されていなければ、データファイルが1ファイルになり、設定されていればテーブル毎のファイルになります。バックアップで抽出したファイル構成も元の構成のままになります。

xtrabackupには Partial Backups というテーブル単位の部分的なバックアップ機能がありますが、innodb_file_per_table がONのデータでないと利用できません。

xtrabackup特有のオプションをmy.cnfに記述する

Configuring xtrabackup に記載されていますが、–target-dir といったxtrabackupのオプションは my.cnf に書いておくことができます。

my.cnfで設定しない方がよい項目

通常の運用とも関係しますが、

innodb_data_home_dir

innodb_log_group_home_dir

は設定せずにデフォルトのデータディレクトリ直下にした方がよいです。変更すると、xtrabackup 実行時にパス関係でエラーが出てめんどくさいことになる場合があります。もしデータディレクトリ以外にしてしまっている場合は、まず値を絶対パスにしてみて、それでもダメなら一度止めてデフォの配置に戻した方が良いかもしれません。

バックアップを取得する

シンプルに取得してみます。
log scanned up to の数値が増加している部分は、更新クエリが発行されたタイミングです。

出来上がったファイルは

元のデータファイルとほぼ同じファイル群（InnoDBテーブルのみ）

取得中の差分トランザクションログ xtrabackup_logfile

LSN情報が記載されたチェックポイントファイル xtrabackup_checkpoints

チェックポイントファイルの中身は

この出来上がったファイルがバックアップファイルになります。

圧縮アーカイブでバックアップする

上記の方法だと、容量がそのままだし、1ファイルじゃないから他サーバに転送して管理するのが汚らしかったりするので、ちゃんと圧縮アーカイブするとこうなります。

できたファイルがこれ。ついでに mysqldump –all-databases でもとってみた。この例だとmysqldumpの方がかなり小さいですが、圧縮率はどちらも十分です。

中身の確認・解凍は -i オプションが必要です。

解凍したら通常バックアップと同じファイル群が出てきます。

バックアップエラー例

一息入れて簡単なエラー例。

一般ユーザで実行する

mysqlユーザのデータファイルが読めないのでエラーになります。

バックアップ済みのディレクトリに再実行する

上書きはできないようになっています。

リストアの準備

取得したバックアップファイルはそのままでは利用できないので、ログファイルを適用して完全なデータファイルにしてあげます。

ログファイルの適用

prepareを実行します。この作業は、データファイルを編集するだけなので、バックアップファイルとxtrabackupが存在するサーバであればどこでも実行することができます。

これでデータファイルをリストアする準備ができました。

新規ログファイルの作成

MySQLを起動した時に、InnoDBログファイルが存在しない場合は勝手に作成してくれますが、その時間を省くために予め作成しておくことができます。なので実行は必須ではないですが、完全な準備とすることができます。

コマンドは1度目のprepareと全く一緒です。

my.cnf に書いてあるサイズと数でログファイルが作成されました。

リストアを実行する

別途復旧するファイル

見ての通り、ここまでの方法でできたファイルは ibdata, .ibd, ib_logfile だけであり、以下のファイルが不足しています。

MySQLシステムデータベース(mysql, performance_schema)

MyISAMデータファイル

InnoDBテーブル定義ファイル(.frm)

これらは、手動でコピーしてくる必要があるのですが、実際には innobackupex を利用することで全て自動で取得してくれます。xtrabackupはあくまでもXtraDBのバックアップ機能という位置付けなのでこのようになっています。

めんどうですが今回は手動でコピーしてきます。

次に権限を変更します。

最後に元データと入れ替えて起動して完了です。

起動しない場合はエラーログを確認して修正します。




この基本手順でわかりやすいメリットはリストアです。

mysqldumpもxtrabackupでも、実際にはバックアップサーバから転送して～解凍して～は同じですが、リストア処理は、mysqldumpのようなクエリ実行型では遅くて所要時間も予測しづらかったのが、xtrabackupになるとちょいとprepareして丸ごと入れ替えるだけなので圧倒的にわかりやすく速いです。

ただ、ロックは必要ないといっても、可能な限りSLAVEサーバ、しかもできれば参照すらしないバックアップ用サーバで実行することが理想であることは変わりません。また、小さい容量で少アクセスなデータベースの場合はmysqldumpの方が圧倒的に使いやすいですので、環境に応じて適切な箇所で利用するのが肝心です。

次回は、もう少し踏み込んだ機能について紹介します。