このトピックでは、コールドデータのバックアップおよび復元機能の動作メカニズムと課金ルールについて説明します。 このトピックでは、機能の設定方法についても説明します。
データは企業の中核資産です。 企業のビジネスが成長するにつれて、データは指数関数的に増加します。 これには、ビジネスアプリケーションがオンラインでリアルタイムにデータを処理できる必要があります。 データベースO&M担当者は、偶発的なデータ削除、システムの脆弱性とランサムウェア、ハードウェア障害、自然災害などの問題がデータ損失を引き起こす可能性があるため、企業のコアデータを保護する上で大きな課題に直面しています。 したがって、データのバックアップおよび復元機能は、データベースの重要な機能です。
PolarDB-Xを使用すると、InnoDBストレージエンジンを使用するデータベースのデータとログをバックアップできます。 詳細については、「概要」をご参照ください。 データまたはログをバックアップするときは、バックアップモードとして [自動バックアップ] または [手動バックアップ] を選択し、復元モードとして [時間単位] または [バックアップ設定] を選択します。 OSS (Object Storage Service) にアーカイブされるコールドデータとInnoDBに保存されるホットデータはインスタンスデータです。 したがって、データのバックアップと復元はデータベースインスタンスに基づいて実行する必要があります。 さまざまなバックアップと復元の要件を満たすために、PolarDB-Xは、OSSにアーカイブされるコールドデータをバックアップおよび復元する一連のソリューションを提供します。
働くメカニズム
コールドデータを含むインスタンスの場合、PolarDB-Xは、インスタンスの一貫したバックアップと復元機能、テーブルのごみ箱機能、SQLステートメントのSQLフラッシュバック機能など、さまざまな粒度でデータ復元機能を提供します。
コールドデータのフラッシュバッククエリ
ストレージエンジンとしてOSSを持つテーブルは、メタデータとデータファイルで構成されています。 メタデータは、PolarDB-Xのグローバルメタサービス (GMS) メタデータノードに格納されます。 データファイルはOSSに保存されます。 これらのデータファイルは、オープンソースのOptimized Row Columnar (ORC) 形式です。 OSSの各データファイルの対応するGMSメタデータレコードには、commit_tsおよびremove_tsタイムスタンプフィールドが含まれています。 これらのフィールドはバージョン管理に使用され、マルチバージョン同時実行制御 (MVCC) メソッドと同じ効果が得られます。
Flashbackクエリを使用すると、SQL文の各テーブルのデータのスナップショットをクエリする時点を指定できます。
上の図では、現在の時刻がクエリ時刻として指定されています。 ファイル1とファイル2では、読み取りタイムスタンプは削除タイムスタンプよりも大きい。 したがって、ファイル1とファイル2のデータは見えません。 ファイル3では、コミットタイムスタンプのみが存在し、読み取りタイムスタンプはコミットタイムスタンプよりも大きい。 したがって、ファイル3のデータは表示されます。 この機能に基づいて、PolarDB-Xは、AS OF TIMESTAMP 'Specified time'
SQL文を提供して、スナップショットクエリの時点を指定します。 例:
SELECT XX userId = 100のoss_ordersから
タイムスタンプの時点 '2022-07-05 11:11:11 '
PolarDB-Xには、OSS内のコールドデータファイルをトリミングして特定の時点にデータを復元するためのAlter FileStorage OSS As Of Timestamp 'Specified time for data restoration'
ステートメントも用意されています。
バックアップセットによるバックアップと復元
PolarDB-Xインスタンスのデータを復元すると、InnoDBに保存されているホットデータとOSSにアーカイブされているコールドデータが一緒に復元されます。 元のインスタンスのデータを宛先インスタンスに復元する時点を指定する必要があります。 OSSのコールドデータの量が多い場合があります。 オンラインデータベースと同じバックアップおよび復元ポリシーを使用すると、バックアップおよびストレージのコストが高くなる可能性があります。 インスタンスデータのバックアップと復元のコストを節約するために、PolarDB-XはInnoDBのホットデータとOSSのコールドデータを分離し、それらに異なるバックアップと復元ロジックを使用します。 これにより、ホットデータとコールドデータを同時にバックアップしたり、ホットデータとコールドデータを別々にバックアップしたりできます。 データをバックアップまたは復元するときは、次の点に注意してください。
スケジュールされたタスクを設定するか、手動で操作を実行して、完全バックアップのAPI操作をトリガーできます。 インスタンスデータのバックアッププロセスは、グローバルにトリガーできます。 InnoDBストレージエンジンのホットデータは、フルデータと増分データに分割され、異なるバックアップおよび復元ロジックが使用されます。
PolarDB-Xは、指定された時点にデータを復元するためのAPI操作をサポートしています。 インスタンスデータ復元のプロセスでは、InnoDB内のホットデータの時点復元メカニズムが呼び出され、対応するGMSおよびデータノードが復元されるようにします。 その後、OSSのコールドデータはGMSメタデータに基づいて復元されます。
次の図は、OSSでのデータのバックアップと復元のプロセスを示しています。
バックアッププロセス
一定期間のOSSデータファイルの完全バックアップ。
データベース管理プラットフォームは、コンピュートノードに対して
Alter FileStorage OSS Backup
ステートメントを実行して、GMSが保持するOSSデータファイルメタデータをfiles_meta.txtという名前のOSSファイルに保持します。 メタデータは、データファイル名および対応するタイムスタンプバージョンを含む。データベース管理プラットフォームは、OSS内のfiles_meta.txtファイルを読み取り、すべてのファイルメタデータを取得します。
データベース管理プラットフォームは、バックアップに使用されるOSSバケットにデータファイルを1つずつコピーします。
OSSスキーマメタデータはGMSに保存されます。 MySQLデータベースのバイナリログのバックアップおよび復元プロセスに従って、メタデータをバックアップできます。
Alter FileStorage OSS Purge Before Timestampステートメントを実行して、古いバージョンの期限切れデータを一定の間隔でパージします。 これにより、バックアップセットのサイズが増加しないようになります。 パージ間隔はバックアップ間隔より長くする必要があることに注意してください。
修復プロセス
InnoDBのコールドデータを新しいPolarDB-Xインスタンスに復元します。 このプロセスでは、GMSおよびデータノードは、完全バックアップおよび増分バイナリログに基づいて、指定された時点に復元されます。 次に、対応するOSSメタデータを、GMSに基づいて指定された時点に復元できます。
OSSデータバックアップセットを選択します。 システムは、バックアップ時刻が復元時刻より早い最新のバックアップセットが履歴バックアップセットの中に存在するかどうかを判定する。 バックアップセットが存在する場合、バックアップセットが選択されます。 バックアップセットが存在しない場合、復元時間は現在の時間に近くなります。 この場合、OSSに保存されているすべてのデータファイルが選択され、
Alter FileStorage OSS Backup
ステートメントが実行されて、GMSに保持されているメタデータファイルがOSSにプッシュされます。前の手順で選択したOSSバックアップセットを新しいPolarDB-Xインスタンスにコピーし、インスタンスをOSSバケットに接続するために使用される方法を更新します。
インスタンスのコンピュートノードで
FileStorage OSS As Of Timestamp 'Specified time for data restoration'
ステートメントを実行して、OSSのコールドデータファイルをトリミングし、特定の時点にデータを復元します。
ホットデータとは異なり、コールドデータメタデータを維持できる最小の粒度は、行ではなくファイルです。 したがって、ホットデータとコールドデータには違いがあります。 下表に違いを示します。
データ型 | InnoDBでのホットデータの | OSSでのCodデータの |
データバックアップ | 完全バックアップ + 増分バイナリログ | メタデータ + データファイルの完全コピーのためのInnoDBバックアップ機能の再利用 |
データの復元 | フルデータ + 増分データ再生 | メタデータのInnoDBバックアップ機能の再利用 + タイムスタンプによるデータファイルの切り取り |
バックアップサイクル | 毎日または毎週 | 毎週または毎月 |
上の図は、InnoDBとOSSのデータのバックアップと復元の違いを示しています。 InnoDBでのデータのバックアップおよび復元中に、バックアップ時刻が復元時刻より前の最新の完全バックアップセットが見つかり、増分データが読み取られて、指定された時点にデータが復元されます。 OSSでのデータのバックアップおよび復元中に、バックアップ時刻が復元時刻よりも遅い最新のバックアップセットが見つかり、データセット内の組み込みの増分データがトリミングされて、指定された時点にデータが復元されます。
課金
OSSのデータのバックアップは無料です。
バックアップポリシーの設定
にログインします。PolarDB for Xscaleコンソール.
上部のナビゲーションバーで、ターゲットインスタンスが配置されているリージョンを選択します。
[インスタンス] ページで、[PolarDB-X 2.0] タブをクリックします。 管理するPolarDB-Xインスタンスを見つけ、インスタンスIDをクリックします。
左側のナビゲーションウィンドウで、 .
アーカイブデータの詳細ページの [バックアップとアーカイブデータ] セクションで、[設定] をクリックします。
[バックアップとアーカイブの設定] ダイアログボックスで、次のパラメーターを設定します。
データのバックアップとアーカイブ: スイッチが自動的にオンになります。
バックアップ間隔: バックアップが実行された日数。 有効な値: 1 ~ 59。 単位:日
バックアップ保持ポリシー: 指定した期間、または永続的にバックアップデータを保持するかどうかを選択できます。
バックアップ保持期間: バックアップファイルの保持期間。 有効な値: 30 ~ 730 単位:日
[OK] をクリックします。