MySQL/MariaDBの整合性を保ったバックアップ方法、Pre-freeze/Post-thawスクリプト比較[Veeam]


SQL ServerなどであればMicrosoft VSSと連携し、VeeamのApplication-aware processing設定を有効にするだけで、簡単にオンラインで整合性を保ったバックアップが可能ですが、MySQL/MariaDBではVSSは使用できないため、この方法は選択できません。このような場合には、VMwareスナップショットでの静止前後に、スクリプトを実行し、アプリケーション一貫性を保った状態を保持するように構成する必要があります。

このスクリプトの実行を行う場合、他のバックアップソフトでは、各LinuxゲストOS上に手動でスクリプトを配置する必要がある場合がありますが、Veeamでは、Veeam Backupサーバ上にあるスクリプトを指定できます。

これにより、ジョブが開始されると、ゲストOSに対して指定したPre-Freezeスクリプトが自動的にアップロードされ、実行され、整合性を保ったオンラインバックアップが可能になります。

今回は、このPre-Freeze/Post-Thawスクリプトでの静止方法に関して、それぞれのメリット、デメリットをご紹介します。

※各スクリプトのサンプルに関しては、こちら

ホットバックアップ:データベースオンラインダンプ

Pre-freezeスクリプトはゲストOS上で実行される全てのデータベースのダンプを単一ファイルで/tmpディレクトリに作成します。サービスは利用可能な状態でVMのスナップショット作成前にmysqldumpコマンドでデータベースのコピーをダンプします。VMのスナップショット作成が成功するとPost-thawコマンドでダンプは削除されます。

メリット:

データベースがオンラインで読み書き可能な状態で、独立したファイルが生成されます。

デメリット:

データベースのシャットダウンに比べて、少々複雑であり、データベースのダンプ処理に時間がかかる場合、バックアップウィンドウに影響する場合があります。また、追加のスペースもゲストOS上に必要になります。

また、rootファイルシステムの飽和や一貫性のないバックアップなどの問題を避けるため、ダンプファイルは専用の監視されているファイルシステムに保存することを強く推奨します。

この方法では、復旧時にデータベースをダンプファイルから再作成する必要があるため、最短のRTOは提供できません。

ホットバックアップ:データベースのフリーズ

MySQLテーブルをVMのスナップショット作成時にディスクへフラッシュし、読み取り専用にします。VMのスナップショット作成が完了すると、書き込み可能な状態に戻ります。

メリット:

データベースはオンラインですが、読み取り専用の状態となります。また追加の容量は不要です。

この方法では復旧時にゲストOSを起動する以外の追加のプロセスが不要なため、短いRTOを提供できます。

デメリット:

データベースは、VMのスナップショットの作成中、部分的に使用できません。 また、タイムアウトにより、指定した時間でスナップショットが完了していなくても、読み取り専用状態を強制的に解放するように設定する必要があります。このタイムアウトはデータベースのサイズとアクティビティによって調整する必要があります。

コールドバックアップ:データベースのシャットダウン

VMのスナップショット作成中にアプリケーションサービスは停止され、VMのスナップショット作成が完了すると、リスタートします。

このようなスクリプトではMySQLサービスのシャットダウンとリスタートにinit.dやsystemctlを使用し、どちらを使用するかはデータベースのパッケージによって異なります。このスクリプトを実行する際のアカウントはMySQLプロセスを開始、停止するための権限を持っている必要があります。

メリット:

追加の容量が不要でもっとも簡単な方法です。

この方法では復旧時にゲストOSを起動する以外の追加のプロセスが不要なため、短いRTOを提供できます。

デメリット:

VMのスナップショット作成中にデータベースは完全に利用不可能な状態となります。

このように各スクリプトにはそれぞれメリット、デメリットがありますので、データベースの要件やポリシーに合わせて使い分けることが重要です。

関連トピックス

コメントを残す

メールアドレスが公開されることはありません。

 

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください