Database > RDS for MySQL > バックアップおよび復元

バックアップ

障害状況に備えて、DBインスタンスのデータベースを復旧できるように事前に準備することができます。必要な時にWebコンソールでバックアップを実行したり、定期的にバックアップが実行されるように設定できます。バックアップが実行されている間は当該DBインスタンスのストレージのパフォーマンス低下が発生する可能性があります。サービスに影響を与えないように、サービスの負荷が少ない時間にバックアップすることを推奨します。バックアップによるパフォーマンス低下を望まない場合は、高可用性構成を使用したり、リードレプリカでバックアップを実行することもできます。

[参考] 高可用性DBインスタンスは予備マスターでバックアップが行われ、マスターのストレージパフォーマンス低下が発生しません。

RDS for MySQLでは、Percona XtraBackupを利用してデータベースをバックアップします。外部MySQLのバックアップで復元したりRDS for MySQLのバックアップで復元するにはRDS for MySQLで使用するPercona XtraBackupと同じバージョンを使用する必要があります。DBエンジンバージョン別のPercona XtraBackupバージョンは次のとおりです。

MySQLバージョン XtraBackupバージョン
5.7.15 2.4.28
5.7.19 2.4.28
5.7.26 2.4.28
5.7.33 2.4.28
5.7.37 2.4.28
8.0.18 8.0.32
8.0.23 8.0.32
8.0.28 8.0.32
8.0.32 8.0.32
8.0.33 8.0.33
8.0.34 8.0.34
8.0.35 8.0.35
8.0.36 8.0.35
  • XtraBackupのインストールに関する詳しい説明はPercona Webサイトを参照します。
  • https://www.percona.com/doc/percona-xtrabackup/2.4/index.html
  • https://www.percona.com/doc/percona-xtrabackup/8.0/index.html

[参考] 2023年8月17日XtraBackupユーティリティのバージョンがアップグレードされました。以前バックアップに使用されたXtraBackupバージョンはWebコンソールで確認できます。 高可用性DBインスタンスは予備マスターでバックアップが行われ、マスターのデータストレージの性能低下が発生しません。

バックアップ時に適用される設定項目は以下の通りで、自動バックアップと手動バックアップの両方に適用されます。

backup-config-ja

backup-config-ko

テーブルロックの使用

  • FLUSH TABLES WITH READ LOCK構文を実行するかどうかを設定します。
  • テーブルロックを使用すると、バックアップデータの一貫性を保証するために、バックアップ時に定期的にFLUSH TABLES WITH READ LOCK構文を実行します。FLUSH TABLES WITH READ LOCK`構文の実行に失敗した場合、バックアップに失敗します。
  • バックアップが実行される間、DMLクエリの負荷が多い場合、テーブルロックを無効にすることができます。テーブルロックを使用しない場合、FLUSH TABLES WITH READ LOCK構文を実行しないため、DML負荷が多くてもバックアップが失敗しません。しかし、テーブルロックを使用しないバックアップは、バックアップデータの一貫性が保証されない可能性があり、これにより、テーブルロックを使用せずに作成されたバックアップおよびテーブルロックを使用しないように設定されたDBインスタンスに対する復元および複製過程を含む一部の作業をサポートしません。

クエリ遅延待機時間(秒)

  • テーブルロックを使用する場合、FLUSH TABLES WITH READ LOCK構文の待機時間を設定します。クエリ遅延待機時間だけFLUSH TABLES WITH READ LOCK構文が待機します。0~21,600秒まで設定できます。長く設定するほど、DMLクエリの負荷によるバックアップ失敗の可能性を減らすことができますが、全体のバックアップ時間が長くなる可能性があります。

手動バックアップ

特定の時点のデータベースを永久に保存するには、Webコンソールから手動でバックアップを実行することができます。手動バックアップは自動バックアップと異なり、明示的にバックアップを削除しない限り、DBインスタンスが削除されるときと同じように削除されません。Webコンソールで手動バックアップを行うには

db-instance-backup-ja

❶バックアップするDBインスタンスを選択した後、バックアップをクリックすると、バックアップ作成 ポップアップ画面が表示されます。

db-instance-backup-popup-ja

❷必要に応じてバックアップを実行するDBインスタンスを変更します。 ❸バックアップの名前を入力します。下記のような制約事項があります。

  • バックアップ名はリージョンごとに固有の名前でなければなりません。
  • バックアップ名は1~100文字の間の英字、数字、一部の記号(-、_、.)のみ使用でき、最初の文字は英字のみ使用できます。

またはバックアップタブで

manual-backup-ja

+バックアップ作成をクリックすると、バックアップ作成ポップアップ画面が表示されます。

db-instance-backup-popup-ja

❷バックアップを実行するDBインスタンスを選択します。 ❸バックアップの名前を入力した後、作成をクリックすると、バックアップの作成をリクエストできます。

自動バックアップ

手動でバックアップを実行する場合以外にも、復元作業のために必要な場合、または自動バックアップスケジュールの設定によって自動バックアップが実行されることがあります。自動バックアップはDBインスタンスとライフサイクルが同じです。DBインスタンスが削除されると、保管された自動バックアップはすべて削除されます。自動バックアップでサポートする設定項目は下記の通りです。

自動バックアップを許可

  • 自動バックアップを許可しない場合、すべての自動バックアップの実行がブロックされ、必要に応じてバックアップが実行される可能性がある復元、複製過程を含む一部の作業をサポートしません。 また、以下の自動バックアップ関連項目については設定ができません。

自動バックアップの保管期間

  • 自動バックアップをバックアップストレージに保存する期間を設定します。最大730日まで保管することができ、自動バックアップの保管期間が変更されると、保管期間が過ぎた自動バックアップファイルはすぐに削除されます。

自動バックアップ複製リージョン

  • 自動バックアップファイルを他のリージョンのバックアップストレージに複製するように設定します。自動バックアップ複製リージョンは、災害復旧(disaster recovery)のための機能で、ソースリージョンの自動バックアップファイルをターゲットリージョンに同じように複製して管理します。複製はバックグラウンドで一定周期ごとに行われます。自動バックアップ複製リージョンを設定すると、リージョン間の複製トラフィック費用が請求され、対象リージョンにバックアップストレージ使用量に対する費用が追加で請求されます。

自動バックアップの再試行回数

  • DMLクエリの負荷または様々な理由で自動バックアップが失敗した場合、再試行するように設定できます。最大10回まで再試行できます。再試行回数が残っていても、自動バックアップの実行時間設定によって再試行しない場合があります。

**自動バックアップスケジュールの使用

  • 自動バックアップスケジュールを使用すると、設定した自動バックアップ実行時間に自動的にバックアップが実行されます。

バックアップ実行時間

  • バックアップが自動的に実行される時間を設定できます。バックアップ開始時刻とバックアップウィンドウ、バックアップ再試行有効期限で構成されます。バックアップ実行時間は重複しないように複数回設定できます。バックアップ開始時刻を基準に、バックアップウィンドウ内のある時点でバックアップを実行します。バックアップウィンドウはバックアップの総実行時間とは関係ありません。バックアップにかかる時間はデータベースのサイズに比例し、サービス負荷によって異なります。バックアップが失敗した場合、バックアップ再試行期限を超えなければ、バックアップ再試行回数に基づいてバックアップを再試行します。

自動バックアップの名前は{DBインスタンスの名前}_yyyy-MM-dd-HH-mmの形で付与されます。

[注意] 前のバックアップが終了していないなど、バックアップを実行できない状況ではバックアップが実行されない場合があります。

バックアップストレージおよび課金

すべてのバックアップファイルは、内部バックアップストレージにアップロードして保存します。手動バックアップの場合、別途削除するまで永続的に保存され、バックアップ容量に応じてバックアップストレージの料金が発生します。自動バックアップの場合、設定した保管期間だけ保存され、自動バックアップファイルの全体サイズのうち、DBインスタンスのストレージサイズを超過した容量に対して課金されます。バックアップファイルが保存されている内部バックアップストレージに直接アクセスすることはできず、バックアップファイルが必要な場合は、NHN Cloudのオブジェクトストレージにバックアップファイルをエクスポートできます。

バックアップのエクスポート

バックアップを実行しながらファイルをエクスポート

バックアップを実行すると同時に、バックアップファイルをユーザーオブジェクトストレージにエクスポートできます。

db-instance-list-export-obs-ja

db-instance-list-export-obs-modal-ja

❶バックアップするDBインスタンスを選択した後、ドロップダウンメニューからオブジェクトストレージにバックアップをエクスポートをクリックすると、設定ポップアップ画面が表示されます。 ❷バックアップが保存されるオブジェクトストレージのテナントIDを入力します。テナントIDはAPIエンドポイント設定で確認できます。 ❸バックアップが保存されるオブジェクトストレージのNHN CloudメンバーまたはIAMメンバーを入力します。 ❹バックアップが保存されるオブジェクトストレージのAPIパスワードを入力します。 ❺バックアップが保存されるオブジェクトストレージのコンテナを入力します。 ❻コンテナに保存されるバックアップのパスを入力します。フォルダ名は最大255バイトで、全体のパスは最大1024バイトです。特定の形(. または ..)は使用できず、特殊文字(' " < > ;)とスペースは入力できません。

バックアップファイルのエクスポート

内部バックアップストレージに保存されたバックアップファイルをNHN Cloudのユーザーオブジェクトストレージにエクスポートできます。

db-instance-detail-backup-export-ja

❶バックアップを実行した原本DBインスタンスの詳細タブでエクスポートするバックアップファイルを選択した後、オブジェクトストレージにバックアップをエクスポートをクリックすると、バックアップをエクスポートするためのポップアップ画面が表示されます。

backup-export-ja

❷またはバックアップタブでエクスポートするバックアップファイルを選択した後、オブジェクトストレージにバックアップをエクスポートをクリックします。

[参考] 手動バックアップの場合、バックアップを実行した元DBインスタンスが削除されると、バックアップをエクスポートできません。

復元

バックアップを利用して希望の時点にデータを復元できます。復元時には常に新しいDBインスタンスが作成され、既存のDBインスタンスに復元することはできません。バックアップを実行した元のDBインスタンスと同じDBエンジンのバージョンにのみ復元できます。バックアップが作成された時点に復元するスナップショット復元、希望する特定の時点に復元する時点復元をサポートします。RDS for MySQLで作成したバックアップだけでなく、外部MySQLのバックアップにも復元できます。

[注意] 復元するDBインスタンスのデータストレージサイズがバックアップを実行した元のDBインスタンスのストレージサイズより小さい場合や、元のDBインスタンスのパラメータグループと異なるパラメータグループを使用する場合、復元に失敗することがあります。

スナップショット復元

バックアップファイルだけで復元を行うため、バックアップを実行した原本DBインスタンスが必要ありません。 Webコンソールでスナップショットを復元するには

db-instance-snapshot-restoration-ja

❶ DBインスタンスの詳細タブで復元するバックアップファイルを選択した後、スナップショット復元をクリックすると、DBインスタンスの復元画面に移動します。

または

snapshot-restoration-ja

❶バックアップタブで復元するバックアップファイルを選択した後、スナップショット復元をクリックします。

時点復元

時点復元を利用して、希望する特定の時点またはバイナリログ(binary log)の特定の位置に復元できます。時点復元をするためには、バックアップファイルとバックアップを実行した時点から復元を希望する時点までのバイナリログ(binary log)が必要です。バイナリログ(binary log)は、バックアップが行われる元DBインスタンスのストレージに保存されます。バイナリログ(binary log)の保管期間が短い場合、ストレージ容量をより多く使うことがありますが、希望する時点への復元が難しい場合があります。下記の場合、時点復元に必要なバイナリログ(binary log)がないため、希望の時点に復元できない場合があります。

  • 容量確保のために元DBインスタンスのバイナリログ(binary log)を削除した場合。
  • バイナリログ(binary log)保管期間に基づいてMySQLによって自動的にバイナリログ(binary log)が削除された場合
  • 高可用性DBインスタンスのフェイルオーバーによりバイナリログ(binary log)が削除された場合。
  • その他様々な理由でバイナリログ(binary log)が破損したり、削除されている場合。

Webコンソールで時点復元を行うには

point-in-time-restoration-list-ja

❶時点復元するDBインスタンスを選択した後、+時点復元をクリックすると、時点復元を設定できるページに移動します。

Timestampを利用した復元

Timestampを使用した復元の場合は、選択した時点と最も近いバックアップファイルを基準に復元を行い、希望する時点までのバイナリログ(binary log)を適用します。

point-in-time-restoration-01-ja

❶復元方法を選択します。

point-in-time-restoration-02-ja

❷復元時刻を選択します。直近の時点に復元するか、希望する特定の時点を直接入力できます。

point-in-time-restoration-03-ja

復元される最後のクエリを確認をクリックすると、最後に復元されるクエリを確認できるポップアップ画面が表示されます。

バイナリログ(binary log)を利用した復元

バイナリログ(binary log)を活用した復元過程では、選択したバックアップファイルで先に復元を行った後、希望する位置までのバイナリログ(binary log)を適用します。

point-in-time-restoration-04-ja

❹バイナリログ(binary log)で復元するためには、まず、バックアップファイルを選択する必要があります。 ❺バイナリログ(binary log)ファイルを選択します。 ❻バイナリログ(binary log)の特定位置を入力します。

外部MySQLバックアップを利用した復元

外部MySQLバックアップファイルを利用してDBインスタンスを作成できます。外部MySQLバックアップファイルを作成する時、バックアップ項目を参照してRDS for MySQLで使用するPercona XtraBackupと同じバージョンを使用する必要があります。

[注意] innodb_data_file_pathの設定値がibdata1:12M:autoextendでない場合、RDS for MySQLのDBインスタンスに復元できません。

(1) MySQLがインストールされたサーバーで下記のコマンドを利用してバックアップを実行します。

XtraBackup 2.4.xx例

innobackupex --defaults-file={my.cnfパス} --user {ユーザー} --password '{パスワード}' --socket {MySQLソケットファイルのパス} --compress --compress-threads=1 --stream=xbstream {バックアップファイルが作成されるディレクトリ} 2>>{バックアップログファイルのパス} > {バックアップファイルのパス}

XtraBackup 8.0.xx例

xtrabackup --defaults-file={my.cnfパス} --user={ユーザー} --password='{パスワード}' --socket={MySQLソケットファイルのパス} --compress --compress-threads=1 --stream=xbstream --backup {バックアップファイルが作成されるディレクトリ} 2>>{バックアップログファイルのパス} > {バックアップファイルのパス}

(2)バックアップログファイルの最後の行にcompleted OK!があるか確認します。completed OK!`がない場合は、バックアップが正常に終了していないため、ログファイルにあるエラーメッセージを参照してバックアップを再度行います。

(3)完了したバックアップファイルをオブジェクトストレージにアップロードします。

  • 一度にアップロードできる最大ファイルサイズは5GBです。
  • バックアップファイルのサイズが5GBより大きい場合、splitのようなユーティリティを利用してバックアップファイルを5GB以下に分割した後、マルチパートでアップロードする必要があります。
  • 詳細については、 マルチパートアップロードを参照してください。

(4)復元するプロジェクトのWebコンソールに接続した後、DBインスタンスタブでオブジェクトストレージにあるバックアップで復元ボタンをクリックします。

[注意] 現在5.7.33バージョンでは、オブジェクトストレージのバックアップファイルを利用したDBインスタンスの復元は制限されます。 推奨するXtraBackup以外のバージョンを使用すると、正常に動作しない場合があります。 オブジェクトストレージのバックアップファイルと復元しようとするMySQLのバージョンは同じでなければなりません。

RDS for MySQLのバックアップを利用した復元

RDS for MySQLのバックアップファイルを利用して直接MySQLのデータベースを復元することができます。RDS for MySQLのバックアップファイルを復元する時、バックアップ項目を参照してRDS for MySQLで使用するPercona XtraBackupと同じバージョンを使用する必要があります。

(1) バックアップのエクスポートの項目を参照して、RDS for MySQLのバックアップをオブジェクトストレージにエクスポートします。

(2)オブジェクトストレージのバックアップを復元したいサーバーにダウンロードします。

(3) MySQLサービスを停止します。

(4) MySQLデータ保存パスのすべてのファイルを削除します。

rm -rf {MySQLデータ保存パス}/*

(5)ダウンロードしたバックアップファイルを解凍して復元します。

XtraBackup 2.4.xxの例

cat {バックアップファイル保存パス} | xbstream -x -C {MySQLデータ保存パス}
innobackupex --decompress {MySQLデータ保存パス}
innobackupex --defaults-file={my.cnfパス} --apply-log {MySQLデータ保存パス}

XtraBackup 8.0.xxの例

cat {バックアップファイルの保存パス} | xbstream -x -C {MySQLデータ保存パス}
xtrabackup --decompress --target-dir={MySQLデータの保存パス}
xtrabackup --prepare --target-dir={MySQLデータ保存パス}
xtrabackup --defaults-file={my.cnfパス} --copy-back --target-dir={MySQLデータ保存パス}

(6)解凍後、不要なファイルを削除します。

find {MySQLデータ保存パス} -name "*.qp" -print0 | xargs -0 rm

(7) MySQLサービスを起動します。

TOP