データベースのバックアップおよびリカバリ操作の信頼性とパフォーマンスを確保することは、どの企業にとっても重要な課題です。MySQL HeatWaveは、手動バックアップ、自動バックアップおよびオペレータ・バックアップの堅牢なサポートをすでに提供しています。バックアップ操作の整合性と効率性をさらに高めるために、「バックアップの検証」と「バックアップの準備」の2つの新機能が導入されました。

なぜバックアップの検証と準備が重要なのか

多くのお客様にとって、定期的なバックアップを維持し、その整合性を検証することは単なるベストプラクティスではありません。多くの場合、規制の要件です。データ保護標準とコンプライアンス・フレームワーク(GDPR、HIPAA、SOCなど)では、ビジネス継続性と監査性を確保するために、企業は検証済みの復元可能なバックアップを保持することが頻繁に必要になります。

一般的にバックアップ検証のプロセスは時間がかかり、複雑になることがあります。:

  • バックアップを別の環境にリストアする必要があります。

  • その後、様々な問合せおよびチェックを実行して、データの整合性と一貫性を確保します。

  • 検証後、この目的のために作成した一時データベース・リソースを手動で削除する必要があります。

MySQL HeatWave Serviceの新しい「バックアップの検証」および「バックアップの準備」機能は、このワークフローを簡素化および自動化します。

  • ユーザビリティ: 「Validate(検証)」ボタンをクリックするだけで、顧客は完全な整合性チェックを手動リストアやデータ問合せなしで開始できます。

  • 複雑さの軽減: 検証および準備プロセス全体がサービスによって管理されます。検証リソースを手動でプロビジョニング、監視または分解する必要がなくなりました。

  • 自動クリーンアップ: 検証に使用されるすべてのリソースは、プロセス後に自動的に削除され、孤立したインスタンスまたは忘れたインスタンスがなくなり、コストが節約されます

  • 将来に対応したバックアップ: 準備されたバックアップは、リストアを高速化するために最適化されています。保留中のREDOログおよびUNDOログの変更が事前に適用されるため、リカバリ時間が短縮され、必要なときにバックアップの準備が整います。

全体として、自動化されたバックアップの検証と準備は、コンプライアンスに対応した、簡単に復元できるバックアップを維持することから推測、手作業、およびリスクを取り除き、データベース操作をよりシンプルかつ安全にします。

機能の概要

バックアップの検証

「バックアップの検証」機能は、バックアップの整合性とリストア準備状況をプロアクティブに確認するように設計されています。要点は次のとおりです:

  • 信頼性確認: バックアップを確実にリストアできるようにします。

  • 破損検出: バックアップ・ファイルが完全であり、破損がないことを検証します。

  • 構成エラー検出: 定期的な検証は、構成または環境の問題を早期に検出するのに役立ちます。

仕組み:

  • 一時的な検証環境にバックアップをリストアします。

  • 内部整合性チェックおよび整合性チェックを実行します。

  • 検証環境を切り離します。

  • 検証結果でバックアップ・レコードを更新します。

Backups that are detected as invalid are marked as FAILED, halting further size metering and triggering appropriate flags for remediation.

バックアップの準備

「バックアップの準備」機能は、特にトランザクションの多いDBシステムのリカバリ時間を短縮します。要点は次のとおりです:

  • リカバリの高速化: 保留中のすべてのREDOおよびUNDOログの変更を事前に適用します。これにより、リストア時のInnoDBクラッシュ・リカバリが短縮されます。

  • ダウンタイムの最小化: リストア後のリカバリ操作を減らすことで、データ損失イベントの全体的な影響が最小限に抑えられます。

いつ「バックアップの準備」機能を使うのか

「バックアップの準備」機能は、トランザクション量が多いデータベース(頻繁なデータ変更があるデータベース)でにおいて、nnoDBクラッシュ・リカバリによってリストア時間が大幅に短縮されることがメリットで宇。「バックアップの準備」の処理中に、保留中のすべてのREDOおよびUNDOログの変更を事前に適用することで、リストア時のクラッシュ・リカバリに必要な時間が最小限に抑えられます。つまり、データ損失または移行イベントが発生した場合に、データベースをはるかに高速にオンライン化できます。

更新が少ないデータベースやほとんどがアイドル状態のデータベースの場合、保留中の変更が少なくなり、クラッシュ・リカバリがすでに迅速であるため、利点はあまり顕著になりません。

補足:

「バックアップの準備」は瞬時で終わる処理ではなく、必要な時間は主にコミットされていない変更の量とデータベースのサイズによって決まります。処理時間は基本的に、リストア時点から検証/準備時点まで時間とコンピュート・リソースによって変化します。つまり、「バックアップの準備」処理をするために事前に時間を費やすことで、将来のリストアを迅速かつ予測可能にしています。特に、ビジネス継続性が最小限のダウンタイムを必要とする場合に重要です。

これにより、追加の準備ワークロードが発生するタイミングを計画および制御でき、重要なリストア・イベント中の予期しない事態を回避できます。

 

手順: MySQL HeatWaveでの「バックアップの検証」と「バックアップの準備」の概要

1. ナビゲーション・メニューを開く

OCIコンソールにてナビゲーションメニューをクリック
「データベース」を選択
MySQL HeatWaveの「バックアップ」をクリック

2. 対象のバックアップを選択する

バックアップのリストのページで、検証を行うバックアップを選択する
該当のバックアップをクリックする

 

Fig-1 backup-validation
図 1.バックアップのリストのページ

3. 検証のプロセスを進める

選択したバックアップの「検証情報」のタブを開き、検証のリンクをクリックする

backup-validation-2.png
Fig 2. Backup details page with validate option 

4. 「バックアップの準備」を有効にする (任意)

バックアップの「検証情報」のパネルに「バックアップの準備」のオプションが表示される
「バックアップの準備」を行っておらず、検証時に「バックアップの準備」を行う場合はチェックを入れる
備考: データに反映されていないREDOログとUNDOログの反映を行うため、将来的なリストア時間の短縮が見込める

backup-validation-3.png
Fig 3. Validate and Prepare backup

5. 検証を開始する

パネル下部の「検証」ボタンを押すと検証が(オプション選択時は準備も含めて)実行される
検証の実行中はステータスの確認が可能

backup-validation-4.png
Fig 4. Backup details page with validated backups 

課金情報

  • 検証と準備のために利用されたコンピュートとストレージは課金対象です。

  • コンピュートのシェイプはDBシステムと同じものになります

  • 検証と準備の際、お客様がアクセス可能なDBシステムは作成されず、バックグラウンドで行われます

  • 課金には DbSystemBackup OCID が使用され、 MysqlInstance OCID は使用されません

  • バックアップのの準備の際、2つの検証環境が順番に作成されます

    • オリジナルのバックアップを検証する環境

    • 続けて、バックアップの準備を行う環境
      これらの環境が同時にアクティブになることはありません。順番に作成され、課金対象となります。結果として、お客様には1つの検証環境のみの課金が発生し、同時に複数の環境の課金が発生することはありません。

  • 課金はリソースのプロビジョン時に開始し、検証環境が削除されると停止します。

バックアップのサイズの計測

  • バックアップが無効と判定され FAILED のステータスになった場合は、即座に課金が停止されます。

  • 「バックアップの準備」では、増分バックアップであってもログが適用されたデータの全体がストレージに置かれます。課金は「準備」が完了したサイズが対象となります。 

まとめ

「バックアップの検証」と「バックアップの準備」の概要によって、お客様は確実かつ迅速で信頼できるリカバリを実現できます。これらの機能はビジネスの継続性、ダウンタイムの最小化、そしてお客様のビジネス環境に極めて重要な資産であるデータを保護します。

追加情報 

https://blogs.oracle.com/mysql/post/leveraging-cost-tags-to-enhance-cost-governance-for-heatwave-mysql 

リファレンス・マニュアル