MySQLのバックアップツールの比較
はじめに
SHIFTの開発エンジニア、さとうです。
現在プロジェクトでは、MySQL8.0を利用しています。
このバージョンにおいて、どのバックアップツールを採用するのが良いか気になったため、データ量を踏まえながら考えていきます。
最初にバックアップ手法について説明した後、検証を行っていきます。
論理バックアップと物理バックアップ
バックアップの形式には論理バックアップと物理バックアップがあります。
論理バックアップは、MySQLサーバー内のデータをテキスト形式でエクスポートしてバックアップを取得します。そのため、少量のデータのバックアップや一部のテーブルのみリストアするなどの場合に適しています。
一方、物理バックアップは、MySQLサーバーの実際のデータファイルをコピーすることでバックアップを取得します。そのため、大量のデータのバックアップや全てのテーブルをリストアするなどの場合に適しています。
オンラインバックアップとオフラインバックアップ
バックアップの手法にはオンラインバックアップとオフラインバックアップがあります。
オンラインバックアップは、データベースを稼働したままバックアップを取得する手法です。 データの整合性に気を付ける必要がありますが、例えばmysqldumpでは、ストレージエンジンがInnoDBのみであれば、「--single-transaction」オプションを利用することで整合性のとれたバックアップを取得することが可能です。また、MySQL Enterprise Backup 製品でも適切にロックを適用した上でバックアップを取得することが可能です。
一方、オフラインバックアップは、データベースを一度停止してからバックアップを取得する手法です。 バックアップ中にサーバーを利用することができないため、クライアントは影響を受ける可能性があります。そのため、レプリカに対してはオフラインバックアップを利用することがあります。
フルバックアップ、差分バックアップと増分バックアップ
バックアップの種類にはフルバックアップ、差分バックアップと増分バックアップがあります。
フルバックアップは、システムに保持されている全てのデータをバックアップします。1番シンプルですが、その分バックアップには時間がかかります。
差分バックアップは、最初のフルバックアップから変更のあった差分を累積的にバックアップします。バックアップデータ量を減らすことができますが、リカバリにはフルバックアップと最新の差分バックアップを適用する必要があります。
増分バックアップは、前回のバックアップで取得したバックアップ以降に変更のあった更新のみをバックアップします。そのため、常に必要なログしかバックアップしませんが、リカバリ手順が最も複雑になります。
MySQLのバックアップツール
今回比較しやすいようフルバックアップのみを対象にします。MySQLでは主に以下のバックアップツールが利用されています。
※ドキュメント
mysqldump: https://dev.mysql.com/doc/refman/8.0/ja/mysqldump.html
mysqlpump: https://dev.mysql.com/doc/refman/8.0/ja/mysqlpump.html
MySQLShell ダンプロードユーティリティ: https://dev.mysql.com/doc/mysql-shell/8.0/ja/mysql-shell-utilities-load-dump.html
Percona XtraBackup: https://docs.percona.com/percona-xtrabackup/8.0/index.html
※オフラインバックアップとしては、MySQLサーバーの物理ファイルをコピーする方法がありますが、今回は割愛します。気になる方はドキュメント をご確認ください。
バックアップとリストアの速度の比較
今回データ量を3パターン用意して、バックアップとリストアにかかる時間を比較してみます。
また、mysqldump、MySQLShell ダンプロードユーティリティ、Percona XtraBackupの3つのツールを比較します。
環境
以下の環境で検証を行いました。
AWS EC2
OS: Ubuntu 24.04
インスタンスタイプ: r5d.xlarge
vcpu: 4
メモリ: 32
MySQL
バージョン: 8.0.40
Percona XtraBackup
バージョン: 8.0.35-31 based on MySQL server 8.0.35
設定は基本的にデフォルトのままですが、MySQLShell ダンプロードユーティリティのリストアでは以下の設定を追加で行う必要があるため、以下の設定のみ反映しています。
SET GLOBAL local_infile=ON;SQL
今回実行するSQLは以下の通りです。
mysqldump
バックアップ
mysqldump \
-uroot \
-pxxxx \
--single-transaction \
--triggers --routines --events \
> dump_data.sqlリストア
cat dump_data.sql | mysql -uroot -pxxxxMySQLShell ダンプロードユーティリティ
バックアップ
util.dumpInstance( "./mysqlsh")リストア
util.loadDump("./mysqlsh")Percona XtraBackup
バックアップ
xtrabackup \
--backup \
--target-dir=/backup \
--user=root \
--password=xxxx \
--socket=/var/lib/mysql/mysql.sockリストア
-- リストア準備ステップ
xtrabackup --prepare --target-dir=/backup
-- リストアストップ
xtrabackup --copy-back --target-dir=/backup --datadir=/var/lib/mysql比較①(1GB)
Percona XtraBackupはリストア準備ステップとリストアストップを行う必要があり、それぞれにかかった時間を合算しています。
結果は秒数で表示します。
比較②(10GB)
比較③(30GB)
※全データサイズでの比較
検証結果より
論理バックアップツールとして、mysqldumpとMySQLShell ダンプロードユーティリティがありますが、MySQLShell ダンプロードユーティリティの方が速い結果となりました。 両方ともバックアップとリストアの時間は、データ量が増えるにつれて増加しますが、特にmysqldumpはリストアの時間が急激に増加していることがわかると思います。
MySQLShell ダンプロードユーティリティはmysqldumpと比べて速度が優れていることに加えて、個人的には進行状況の表示や一時的にストップしても続きから再開できることがとても便利だと感じました。 というのも1回ディスクスペースが足りなくなり、リストアが失敗したのですが、続きから再開することができました。mysqldumpであれば途中で失敗した場合には、バックアップした論理ファイルの中身を修正してからリストアする必要があります。
また、Percona XtraBackupはmysqldumpとMySQLShell ダンプロードユーティリティといった論理バックアップよりもバックアップは遅くなりますが、リストアは断然速くなります。リストアの時間は、データ量が増えても論理バックアップツールに比べて影響がありませんでした。
そのため、データ量が膨大な場合はPercona XtraBackupを利用するのが良いと思います。 ただし、Percona XtraBackupはMySQLサーバー上で実行する必要があるなどの制約があります。
なので、制約が満たせない場合は他の物理バックアップかMySQLShell ダンプロードユーティリティを利用するのが良いと思います。
データ量が少ない場合は、実行環境を整える手間を考慮すると、mysqldumpかMySQLShell ダンプロードユーティリティで問題ないと思います。
まとめると以下のようになります。
私も今まではmysqldumpしか利用していませんでしたが、MySQLShell ダンプロードユーティリティを利用して開発作業を行ってみようと思います。
参考資料
・MySQLドキュメント
・Percona XtraBackupドキュメント
・MySQL運用・管理［実践］入門
執筆者プロフィール：さとう
SHIFTのアプリケーション開発テクノロジーグループ所属の開発エンジニア
✅SHIFTへのお問合せはお気軽に
SHIFTについて（コーポレートサイト）
https://www.shiftinc.jp/
SHIFTのサービスについて（サービスサイト）
https://service.shiftinc.jp/
SHIFTの導入事例
https://service.shiftinc.jp/case/
お役立ち資料はこちら
https://service.shiftinc.jp/resources/
SHIFTの採用情報はこちら
https://recruit.shiftinc.jp/career/