MySQL8.0のバックアップはどれがいいのか

技術本部 サービスリライアビリティグループ(SRG)の鬼海(@fat47)です。
#SRG(Service Reliability Group)は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。
本記事は、SRG 内にある DBWG(DBワーキンググループ)が全社内向けに提供しているデータベースに関する資料を公開します。
なにかの役に立てば幸いです。
 

はじめに


MySQL8.0には様々なバックアップ手法がありますが、結局どれを使うのがいいのか問題を考えます。

結論


💡
論理バックアップ・リストアはMySQL Shell Dump Utilityが最速 物理バックアップ・リストアはXtraBackup , CLONE PLUGINで速度の差はほぼ無い XtraBackupはMySQL8.0.29以降では大きな制約ができたので注意
 

バックアップの手法


フルバックアップだけでも以下の方法があります。
  • mysqldump
  • mysqlpump
  • Percona XtraBackup
  • MySQL Shell Instance Dump Utility and Dump Loading Utility
  • CLONE PLUGIN

mysqldump

mysqldumpクライアントは、論理バックアップ を実行するユーティリティーです。
元のスキーマオブジェクト、テーブルデータ、または両方を再現するために実行できる SQL ステートメントのセットを生成します。その他の形式としてCSV、その他の区切り文字で区切られたテキストでも出力が可能です。

mysqlpump

mysqldumpの後継として2015年のMySQL5.7.8以降のパッケージに同梱されています。
mysqldumpとの違いとしては、進捗表示の機能や並列処理が可能などの進化があります。
 

MySQL Shell Instance Dump Utility and Dump Loading Utility

2020年のMySQL shell8.0.21に追加された機能です。
バックアップをパラレルで実行することにくわえ、リストアもパラレルで実行可能です。
MySQL Shellは5.7環境に対しても利用することができます。
MySQL :: MySQL Shell 8.0 :: 8.6 ダンプロードユーティリティ
MySQL Shell ダンプロードユーティリティ util.loadDump() は、MySQL Shell 8.0.21 で導入され、MySQL Database Service DB システム (MySQL DB システム、短縮形) または MySQL Shell セクション8.5「インスタンスダンプユーティリティ、スキーマダンプユーティリティおよびテーブルダンプユーティリティ」 を使用してダンプされたスキーマまたはテーブルの MySQL Server インスタンスへのインポートをサポートしています。 ダンプロードユーティリティでは、リモート記憶域からのデータストリーミング、テーブルまたはテーブルチャンクのパラレルロード、進行状況トラッキング、再開およびリセット機能、およびダンプの実行中の同時ロードのオプションが提供されます。 MySQL DB システムにインポートするには、ダンプロードユーティリティを実行する MySQL Shell インスタンスが、MySQL DB システムにアクセスできる Oracle Cloud Infrastructure Compute インスタンスにインストールされている必要があります。 ダンプファイルが Oracle Cloud Infrastructure Object Storage バケットにある場合は、コンピュートインスタンスからオブジェクトストレージバケットにアクセスできます。 ダンプファイルがローカルシステムにある場合は、コンピュートインスタンスに選択したオペレーティングシステムに応じて、選択したコピーユーティリティを使用して Oracle Cloud Infrastructure Compute インスタンスに転送する必要があります。

Percona XtraBackup

Percona社がリリースしているオープンソースのバックアップツールです。
いままで上げてきたバックアップツールは論理バックアップですが、
XtraBackupはDBのファイル自体をコピーする物理バックアップになります。
 

CLONE PLUGIN

2019年のMySQL 8.0.17で追加された物理バックアップ機能です。
ローカルにファイルとしてバックアップしたり、リモートで対象サーバのコピーを作成することができます。注意点としてはバックアップ対象はInnoDBストレージエンジンのテーブルに限られます。
 

バックアップ&リストアの速度比較


検証用のデータベース

MySQL Ver8.0.28
データサイズ約42GB

結果のグラフ

実行結果の比較
実行結果の比較
先に結果のグラフを掲載しておきます。縦軸は秒数です。
論理バックアップではMySQL Shell Dump Utilityがバックアップ・リストアともに最速で、
物理バックアップではXtraBackup、CLONE PLUGINで大きな速度の違いはありませんでした。
それぞれのツールのバックアップ・リストアのコマンドと実行時間は下記の通りです。

mysqldump

バックアップ実行結果
実行時間:4分22秒
 
リストア実行結果
実行時間:38分45秒

mysqlpump

バックアップ実行結果
実行時間:2分22秒
 
リストア実行結果
実行時間:41分51秒

MySQL Shell Instance Dump Utility and Dump Loading Utility

バックアップ実行結果
実行結果:1分51秒
 
リストア実行結果
実行時間:15分35秒
 

Percona XtraBackup

バックアップ実行結果
実行時間:3分22秒
 
リストア実行結果
実行時間:3分41秒

CLONE PLUGIN

バックアップ実行結果
実行時間:3分56秒
 
リストア実行結果
実行時間:3分52秒

どのバックアップツールを利用するのがよいか


論理バックアップはが早いです。特にリストアも並列で処理できることが効いていて、mysqldumpなどと比較すると3分の1ほどの時間で完了できています。
オンプレ環境からAuroraに移行する際などの論理バックアップデータが必要なときは、このMySQL Shell dump utilityを用いるのがよいと思います。
 
物理バックアップではでもCLONEでも大きな速度の差はないので、引き続きXtraBackupを利用する方針でよいと思います。
XtraBackupは歴史が長い分さまざまな便利機能が備わっており、柔軟なバックアッププランを構築することができます。
例えば取得したバックアップデータをStreamでクラウドサービスのオブジェクトストレージにそのままアップロードすることも可能です。
ただしXtraBackupをMySQL8.0.29以降で使う場合は注意が必要です。
 
MySQL8.0.29からALTER TABLE … ALGORITHM=INSTANTの仕様が変わり、InnoDB REDOログ形式も仕様変更されました。
DDL実行時のデフォルトの動作がINSTANTに変更されているので、この機能を完全に回避するにはすべてのDDLにALGORITHM=INPLACE/COPY; を指定する必要があり、現実的ではありません。
このINSTANT機能を利用がされたテーブルが存在すると、そのままではXtraBackupを利用したバックアップができません。
これを回避するにはエラー文に書いてある通り、対象テーブルに対してOPTIMIZE TABLEかALTER TABLE ALGORITHM=COPYを実行する必要があります。
XtraBackupを利用したバックアップはMySQL8.0.28までにするか、
CLONE PLUGINが使える8.0.17以降の環境であればCLONE PLUGINの利用を検討してもよいかもしれません。

終わりに


SRG では一緒に働く仲間を募集しています。 ご興味ありましたらぜひこちらからご連絡ください。
このエントリーをはてなブックマークに追加