Last Updated on 2021年7月4日 by かんりにん
PerconaのMySQL用バックアップツール。今回は2.3の最新版2.3.3を入れて検証してみる。リリースは2015年12月。
バックアップ対象のMySQLは、Percona謹製のMySQLだけでなく、公式版のMySQLにも使えるので、すでに稼働中のMySQL DBサーバーにXtraBackupを追加してもOK。
検証に使った環境はAWS EC2、CentOS6.7+MySQL5.6。
■参考:お世話になっております!
Percona xtrabackup公式サイト
GitHub<ソースコード>
ダウンロードページ
インストールガイド
バージョン対応情報
■導入検証
▼事前準備
非同期処理ライブラリlibev、Perlの時間計測モジュール”Time::HiRes”が必要となるので、先にインストール。
“Time::HiRes”はRPMパッケージでは”perl-Time-HiRes”と置き換えてインストール。
# yum install libev perl-Time-HiRes
そのほか、必要なライブラリがあれば追加する。
このあたりは前回試した2.0.8と変わらない様子。
▼インストール
公式サイトからRPMをダウンロード。ソースだけでなく、RPM、aptも提供されていて導入はしやすく、助かる。
– 公式サイトからダウンロード
# wget https://www.percona.com/downloads/XtraBackup/Percona-XtraBackup-2.3.3/binary/redhat/6/x86_64/percona-xtrabackup-2.3.3-1.el6.x86_64.rpm # wget https://www.percona.com/downloads/XtraBackup/Percona-XtraBackup-2.3.3/binary/redhat/6/x86_64/percona-xtrabackup-debuginfo-2.3.3-1.el6.x86_64.rpm # wget https://www.percona.com/downloads/XtraBackup/Percona-XtraBackup-2.3.3/binary/redhat/6/x86_64/percona-xtrabackup-test-2.3.3-1.el6.x86_64.rpm
参考:同じページからダウンロードできる”Percona-XtraBackup-2.3.3-r525ca7d-el6-x86_64-bundle.tar“は上記3つのパッケージを集約したもの。こちらをダウンロードし、ローカルで展開してもOK。
– Percona GPG Keyのインストール
GPG KeyのURLはこちらを参照のこと。
# rpm --import http://www.percona.com/downloads/RPM-GPG-KEY-percona
– インストールテスト
# rpm -ivh --test percona-xtrabackup-2.3.3-1.el6.x86_64.rpm Preparing... ########################################### [100%]
– インストール
# rpm -ivh percona-xtrabackup-2.3.3-1.el6.x86_64.rpm Preparing... ########################################### [100%] 1:percona-xtrabackup ########################################### [100%]
– インストールされたファイルを確認
/usr/bin/innobackupex /usr/bin/xbcloud /usr/bin/xbcloud_osenv /usr/bin/xbcrypt /usr/bin/xbstream /usr/bin/xtrabackup /usr/share/doc/percona-xtrabackup-2.3.3 /usr/share/doc/percona-xtrabackup-2.3.3/COPYING /usr/share/man/man1/innobackupex.1.gz /usr/share/man/man1/xbcrypt.1.gz /usr/share/man/man1/xbstream.1.gz /usr/share/man/man1/xtrabackup.1.gz
▼環境設定
xtrabackup独自のコンフィギュレーションファイルは無く、my.cnfに”[xtrabackup]”セクションを追記して、パラメータと設定値を追加するかたち。
“man xtrabackup”すると簡単な設定の案内が出てくるので、そちらを参考のこと。
– 超カンタンな設定例
manすると以下の設定が例として出てくるので、抜粋。
[xtrabackup] target_dir = /data/backups/mysql/
▼バックアップのテスト
コマンド”xtrabackup”を使ったテスト。テストマシンなのでDBマスターで。
前回と同じくデータディレクトリは/var/lib/mysql、バックアップ先はテスト用として/tmp/xtrabackupをmkdirして、出力先に指定。
# xtrabackup --backup --user root --password <パスワード> --datadir=/var/lib/mysql/ --target-dir=/tmp/xtrabackup/ 160210 17:38:40 version_check Connecting to MySQL server with DSN 'dbi:mysql:;mysql_read_default_group=xtrabackup;port=3306;mysql_socket=/var/lib/mysql/mysql.sock' as 'root' (using password: YES). 160210 17:38:40 version_check Connected to MySQL server 160210 17:38:40 version_check Executing a version check against the server... 160210 17:38:40 version_check Done. 160210 17:38:40 Connecting to MySQL server host: localhost, user: root, password: set, port: 3306, socket: /var/lib/mysql/mysql.sock Using server version 5.5.30-log xtrabackup version 2.3.3 based on MySQL server 5.6.24 Linux (x86_64) (revision id: 525ca7d) xtrabackup: uses posix_fadvise(). xtrabackup: cd to /var/lib/mysql/ xtrabackup: open files limit requested 0, set to 1024 xtrabackup: using the following InnoDB configuration: xtrabackup: innodb_data_home_dir = ./ xtrabackup: innodb_data_file_path = ibdata1:10M:autoextend xtrabackup: innodb_log_group_home_dir = ./ xtrabackup: innodb_log_files_in_group = 2 xtrabackup: innodb_log_file_size = 5242880 160210 17:38:40 &gt;&gt; log scanned up to (3377004) xtrabackup: Generating a list of tablespaces 160210 17:38:40 [01] Copying ./ibdata1 to /tmp/xtrabackup/ibdata1 160210 17:38:41 [01] ...done 160210 17:38:41 &gt;&gt; log scanned up to (3377004) 160210 17:38:41 Executing FLUSH NO_WRITE_TO_BINLOG TABLES... 160210 17:38:41 Executing FLUSH TABLES WITH READ LOCK... 160210 17:38:41 Starting to backup non-InnoDB tables and files 160210 17:38:41 [01] Copying ./wordpress23test/db.opt to /tmp/xtrabackup/wordpress23test/db.opt 160210 17:38:41 [01] ...done <!-- ここらあたりでMyISAMのデータのバックアップをしてるのだけど、すごく長いのでsnip --> 160210 17:38:42 Finished backing up non-InnoDB tables and files 160210 17:38:42 [00] Writing xtrabackup_binlog_info 160210 17:38:42 [00] ...done 160210 17:38:42 Executing FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS... xtrabackup: The latest check point (for incremental): '3377004' xtrabackup: Stopping log copying thread. 160210 17:38:42 &gt;&gt; log scanned up to (3377004) 160210 17:38:42 Executing UNLOCK TABLES 160210 17:38:42 All tables unlocked 160210 17:38:42 Backup created in directory '/tmp/xtrabackup/' MySQL binlog position: filename 'mysql-bin.000012', position '47779' 160210 17:38:42 [00] Writing backup-my.cnf 160210 17:38:42 [00] ...done 160210 17:38:42 [00] Writing xtrabackup_info 160210 17:38:42 [00] ...done xtrabackup: Transaction log of lsn (3377004) to (3377004) was copied. 160210 17:38:42 completed OK!
実行結果はこんな感じ。
# ls -al /tmp/xtrabackup4/2016-02-10_18-18-12/ total 18504 drwx------ 7 root root 4096 Feb 10 18:18 . drwxr-xr-x 3 root root 4096 Feb 10 18:18 .. -rw-r----- 1 root root 385 Feb 10 18:18 backup-my.cnf -rw-r----- 1 root root 18874368 Feb 10 18:18 ibdata1 drwx------ 2 root root 4096 Feb 10 18:18 mysql drwx------ 2 root root 4096 Feb 10 18:18 performance_schema drwx------ 2 root root 4096 Feb 10 18:18 wordpress drwx------ 2 root root 4096 Feb 10 18:18 wordpress23test drwx------ 2 root root 4096 Feb 10 18:18 wordpress_inno -rw-r----- 1 root root 23 Feb 10 18:18 xtrabackup_binlog_info -rw-r----- 1 root root 113 Feb 10 18:18 xtrabackup_checkpoints -rw-r----- 1 root root 486 Feb 10 18:18 xtrabackup_info -rw-r----- 1 root root 2560 Feb 10 18:18 xtrabackup_logfile
参考:バックアップ時に追加で作成されるファイル
まだ深く掘り下げてないので、おいおい時間があるときにでも。
- xtrabackup_binlog_info
実行時のバイナリログのポジションを出力 - xtrabackup_checkpoints
InnoDBのログシーケンス番号を出力 - xtrabackup_info
実行時の対象DB全般のオプション - xtrabackup_logfile
xtrabackup実行中のバイナリログの差分
そのほかメモ:
- スレーブDBでバックアップを取るときはオプションに“–slave-info”を追加
- 以前試した2.0では、xtrabackupコマンドとは別にinnobackupex”コマンドがあったが、2.3ではinnobackupexはtrabackupコマンドのシンボリックリンクになっていた。統合された、ということかな?
(バージョンアップに対応させるためにinnobackupexコマンドをシンボリックリンクとして残した?) - バックアップ実行時に使用するユーザーにはRELOAD権限をつける。
標準出力のログを見てみると、ファイルコピーが終わった後で”Executing FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS…”となっており、実行にあたってRELOAD権限が必要になる。
前回も今回もrootで試してしまったものの、バックアップ用のユーザーを作成している場合はRELOAD権限の有無をチェックし、なければ追加する(手抜きはよくないですね…)。
参考:エラーメッセージ:
Error: failed to execute query FLUSH NO_WRITE_TO_BINLOG TABLES: Access denied; you need (at least one of) the RELOAD privilege(s) for this operation