物理バックアップとリストアの概要

バックアップとリストアは、OceanBaseデータベースの高可用性機能の中核をなすコンポーネントであり、主にストレージメディアの損傷やユーザーの誤操作などによるデータ損失を防ぐために使用されます。ストレージメディアが損傷したり、ユーザーの誤操作によってデータが失われた場合でも、リストアによってユーザーのデータを復元することができます。

概要

OceanBaseデータベースのバックアップ・リストアモジュールは、バックアップ、バックアップ検証(V4.4.2以降、V4.4.2 BP2からサポート)、リストア、クリーンアップなどの機能を提供します。

バックアップ

OceanBaseデータベースはテナントレベルでの物理バックアップをサポートしています。物理バックアップは、データバックアップとログアーカイブの2種類のデータで構成されており、データバックアップとログアーカイブの2つの機能が組み合わさっています。ここでのテナントとはユーザーのUserテナントを指し、sysテナントとMetaテナントの物理バックアップはサポートされていません。

データバックアップとはデータをバックアップする機能で、フルバックアップと増分バックアップの2種類に分けられます：

• フルバックアップとは、すべてのマクロブロックをバックアップすることです。

• 増分バックアップとは、前回のバックアップ以降に追加または変更されたマクロブロックをバックアップすることです。

データバックアップで主にバックアップされるデータは以下の通りです：

• テナント関連情報：テナント名、クラスタ名、タイムゾーン(timezone)、レプリカの分散状況(locality)、テナントの互換モード(MySQLまたはOracle)など

• すべてのユーザーテーブルデータ

  説明

  データバックアップはシステム変数とテナントパラメータをバックアップしますが、クラスタレベルのパラメータやプライベートシステムテーブルのデータはバックアップしません。

ログアーカイブとは、ログデータの自動アーカイブ機能を指します。OBServerノードは定期的にログデータを指定されたバックアップパスにアーカイブします。この動作は完全に自動的で、外部からの定期的なトリガーは不要です。ログアーカイブサービスを有効にすると、データディクショナリもアーカイブされます。

バックアップ検証

OceanBaseデータベースのバックアップ検証機能は、主にバックアップおよびアーカイブデータの完全性と正確性の問題を解決するために使用されます。ユーザーは実際のリストア操作を実行することなく、バックアップセットやアーカイブされたログにファイルの欠落、物理データの破損、論理的な不整合などの問題がないか積極的に検証できます。

バックアップ検証は検証レベルに応じて、Basic検証とPhysical検証に分けられます。その中で：

• Basic検証：ファイルリストの完全性のみをチェックします。

• Physical検証：物理データの正確性と論理的一貫性をチェックします。

バックアップ検証は検証粒度に応じて、バックアップおよびアーカイブパス全体の検証、指定されたバックアップセットまたはログアーカイブPieceの検証、およびクラスタ間で指定されたパス下の検証をサポートします。

リストア

物理リストアの全体アーキテクチャは以下の通りです：

1. 物理リストアはテナントレベルのリストアとテーブルレベルのリストアをサポートします

   • テナントレベルの復元：テナントレベルの復元とは、既存データのバックアップに基づいて新しいテナントを再構築するプロセスです。テナントレベルの復元は、テーブルやパーティションをまたがるグローバルな一貫性を保証します。

   • テーブルレベルの復元：テーブルレベルの復元とは、バックアップデータからユーザーが指定したテーブルを既存のテナントに復元することです。この既存のテナントは、元のテーブルが存在するテナントと同じものであっても、同一クラスタ内の異なるテナントであっても、異なるクラスタのテナントであってもかまいません。

2. テナントレベルの復元は、フル復元とクイック復元をサポートしています。

   注意

   クイック復元で復元されたテナントは、手動でのメジャーコンパクションの開始、データバックアップ、Switchover/Failoverによるリーダーデータベースへの切り替えをサポートしていません。スタンバイデータベースとしてのみ存在できます。

   • フル復元：マクロブロックデータと増分ログを復元することを指します。すべてのデータがバックアップメディアからローカルに復元された後、復元されたテナントはサービスを提供できる状態になります。フル復元のプロセス全体には、テナントのシステムテーブルとユーザーテーブルのRestoreおよびRecoverプロセスが含まれます。Restoreとは、復元に必要なベースラインデータを対象テナントのOBServerノードに復元することであり、Recoverとは、ベースラインに対応するログを対応するOBServerノードに復元することです。

   • クイック復元：マクロブロックデータを復元しなくてもユーザーにサービスを提供できることを指します。これにより、復元待ち時間を短縮し、ユーザーの運用コストを削減できます。

3. 物理復元のための復元時刻の選択

   • 完全復元：復元するタイムスタンプを指定しません。

   • SCNまたはタイムスタンプを指定した不完全復元：ここで、SCNはOceanBaseデータベース内部の正確なバージョン番号です。タイムスタンプはOracleモードではナノ秒単位で正確であり、精度の損失はありません。MySQLモードではマイクロ秒単位で正確ですが、マイクロ秒以降の精度は失われます。

物理復元のプロセスについては、復元プロセスを参照してください。

クリーンアップ

OceanBaseデータベースは、バックアップデータの自動および手動クリーンアップ機能を提供しており、ユーザーはビジネスシナリオに応じて柔軟に処理できます。

• 自動クリーンアップ：復元ウィンドウ（recovery_window）に基づく自動クリーンアップメカニズムです。ユーザーがバックアップデータの有効期限を設定すると、システムは定期的にクリーンアップタスクをトリガーし、期限切れのバックアップセットとデータアーカイブピースをクリーンアップします。

• 手動クリーンアップ：手動クリーンアップは、大きく分けて2種類あります。1つ目は、指定したバックアップセットまたはログアーカイブピースを手動でクリーンアップすることです。2つ目は、パス全体（データバックアップパスまたはログアーカイブパス）下のすべてのバックアップセットまたはデータアーカイブピースを手動で削除することです。

バックアップメディア要件

OceanBaseデータベースの現在のバージョンは、Alibaba Cloud OSS、NFS、Azure Blob、AWS S3、およびS3プロトコル互換のオブジェクトストレージ（例：Huawei OBS、Google GCS、Tencent Cloud COS）などのバックアップメディアをサポートしています。一部のバックアップメディアは使用するためにいくつかの基本要件を満たす必要があります。

SDKバージョン要件

オブジェクトストレージSDKバージョンとobserverバージョンの対応関係は以下のとおりです：

インターフェース要件

• Alibaba Cloud OSS：

  • Alibaba Cloud公式のOSSをサポートしており、依存するインターフェースは以下の表のとおりです。

    インターフェース名	説明
    PutObject	単一オブジェクトのアップロード
    DeleteObject	単一オブジェクトの削除
    DeleteObjects	オブジェクトの一括削除
    GetObject	特定のオブジェクトの取得
    ListObjects	ストレージ容量内の全オブジェクトの一覧表示（強整合性に依存）
    HeadObject	特定のオブジェクトのメタデータの取得
    AppendObject	追加書き込みでオブジェクトをアップロード
    PutObjectTagging（オプション）	オブジェクトのタグの設定または更新
    GetObjectTagging（オプション）	オブジェクトタグの取得
    InitiateMultipartUpload	マルチパートアップロードの初期化
    UploadPart	パートのアップロード
    CompleteMultipartUpload	アップロード済みのパーツを単一のオブジェクトに統合
    AbortMultipartUpload	マルチパートアップロードの中止、アップロード済みのパーツの削除
    ListMultipartUploads	初期化済みで完了または終了していないマルチパートアップロードの情報を一覧表示
    ListParts	アップロードタスクでアップロードが完了したパーツの情報を一覧表示

  • V1署名アルゴリズムのみをサポートします。

• NFS：NFS 3以降のバージョンが必要です。

• S3プロトコル互換のオブジェクトストレージ（例：Huawei OBS、Google GCS、Tencent Cloud COS）：

  1. 以下の表に示すS3 API動作との互換性が必要です。

     インターフェース名	説明
     PutObject	単一オブジェクトのアップロード
     DeleteObject	単一オブジェクトの削除
     DeleteObjects	オブジェクトの一括削除
     GetObject	単一オブジェクトのダウンロード
     ListObjects	パス配下のすべてのオブジェクトを一覧表示
     HeadObject	特定のオブジェクトのメタデータを取得
     PutObjectTagging（オプション）	オブジェクトにタグを設定
     GetObjectTagging（オプション）	オブジェクトのタグを取得
     CreateMultipartUpload	マルチパートアップロードを初期化
     UploadPart	単一のパートをアップロード
     CompleteMultipartUpload	アップロード済みのパートを単一のオブジェクトに統合
     AbortMultipartUpload	マルチパートアップロードを中止し、アップロード済みのパートを削除
     ListMultipartUploads	アップロード中のマルチパートを一覧表示
     ListParts	アップロードタスクでアップロードが完了したパート情報を一覧表示

  2. Virtual-hosted–styleのオブジェクトアクセスURLをサポートする必要があります。Virtual-hosted–styleリクエストの詳細については、AWS S3公式Webサイトを参照してください。

バックアップメディアを選択する際、ob_adminツール内のtest_io_deviceコマンドを使用して、該当バックアップメディアが提供するI/Oインターフェースおよび現在のI/O権限がバックアップ・リストアの要件を満たしているかどうかを検証できます。また、ob_adminツール内のio_adapter_benchmarkコマンドを使用して、OBServerノードからバックアップメディアへの読み書き性能を確認し、バックアップ性能の参考とすることもできます。test_io_deviceおよびio_adapter_benchmarkコマンドの詳細な説明と使用方法については、test_io_deviceおよびio_adapter_benchmarkを参照してください。

ディレクトリ構造

データバックアップディレクトリ

データバックアップ機能がバックアップ先に作成するディレクトリおよび各ディレクトリ内に保存されるファイルの種類は以下のとおりです。

data_backup_dest
├── format.obbak                                            // バックアップパスのフォーマット情報
├── check_file
│   └── 1002_connect_file_20230111T193020.obbak             // 接続性チェックファイル
├── backup_sets                                             // データバックアップリストの集約ディレクトリで、すべてのデータバックアップセットリストを記録
│   ├── backup_set_1_full_end_success_20230111T193420.obbak // フルバックアップ終了のプレースホルダー
│   ├── backup_set_1_full_start.obbak                       // フルバックアップ開始のプレースホルダー
│   ├── backup_set_2_inc_start.obbak                        // 増分バックアップ開始のプレースホルダー
│   └── backup_set_2_inc_end_success_20230111T194420.obbak  // 増分バックアップ終了のプレースホルダー
└── backup_set_1_full                                        // フルバックアップセット。ファイル名の末尾が full はフルバックアップ、inc は増分バックアップを表す
    ├── file_list.0.obbak
    ├── backup_set_1_full_20230111T193330_20230111T193420.obbak //プレースホルダーで、フルバックアップの開始時刻と終了時刻を表示する
    ├── single_backup_set_info.obbak                        // 現在のバックアップセットのメタ情報
    ├── tenant_backup_setInfos.obbak                       // 現在のテナントのフルバックアップセット情報
    ├── infos
    ├── logstream_1                                          // 1号ログストリーム
    └── logstream_1001                                       // 1001号ログストリーム

データバックアップディレクトリでは、最上位ディレクトリには以下の3種類のデータが含まれます：

• format.obbak：バックアップパスのメタ情報を記録します。

• check_file：ユーザーデータバックアップディレクトリの接続性チェックに使用されます。

• backup_sets：データバックアップリストの集約ディレクトリで、すべてのデータバックアップセットリストを記録します。

• backup_set_1_full：このディレクトリはデータバックアップセットを表します。backup_set_1 はそのバックアップセットの backup_set_id が 1 であることを示します。ディレクトリ名の末尾が full はフルバックアップ、inc は増分バックアップを表します。データバックアップごとに対応するバックアップセットが生成され、データバックアップ終了後はそのバックアップセットは変更されません。

  一つのデータバックアップセットには、主に以下のデータが含まれます：

  • file_list.0.obbak：このファイルは、現在のディレクトリに含まれるファイルおよびディレクトリを記録します。

  • backup_set_1_full_20230111T193330_20230111T193420.obbak：このファイルは、現在のバックアップセットのID、開始時刻、終了時刻を表示します。このファイルは情報表示のみに使用されます。

  • single_backup_set_info.obbak：このファイルは、現在のバックアップセットのメタ情報を記録します。バックアップのポイント、依存するログなどの情報が含まれます。

  • tenant_backup_setInfos.obbak：このファイルは、現在のテナントが持つすべてのバックアップセットのメタ情報を記録します。

  • infos：このディレクトリは、データバックアップセットのメタ情報を記録します。

  • logstream_1：このディレクトリは、1号ログストリームのすべてのデータを記録します。1号ログストリームはOceanBaseデータベーステナントのシステムログストリームです。

  • logstream_1001：このディレクトリは、ログストリーム1001のすべてのデータを記録しています。1000より大きいログストリーム番号は、OceanBaseデータベーステナントのユーザーログストリームです。

クラスタレベル構成パラメータのバックアップディレクトリ

クラスタレベル構成パラメータのバックアップが実行されるたびに、システムは指定されたディレクトリにクラスタレベル構成パラメータのバックアップファイルを生成します。具体的なディレクトリ構造は以下のとおりです。

cluster_parameters_backup_dest
├── cluster_parameter.20240710T103610.obbak # デフォルト設定以外のクラスタレベル構成パラメータ情報、ファイル名形式：`cluster_parameter.[timestamp]`
└── cluster_parameter.20241018T140609.obbak

ログアーカイブディレクトリ

NFS、OSS、Azure Blobなどのバックアップ媒体について、ログアーカイブ機能がアーカイブ先に作成するディレクトリおよび各ディレクトリ内に保存されるファイルの種類は以下のとおりです。

log_archive_dest
    ├── check_file
    │   └── 1002_connect_file_20230111T193049.obbak // 接続性チェックファイル
    ├── format.obbak                                // バックアップパスのフォーマット情報
    ├── rounds                                      // Roundsプレースホルダーディレクトリ
    │   └── round_d1002r1_start.obarc               // Round開始プレースホルダー
    ├── pieces                                      // Pieceプレースホルダーディレクトリ
    │   ├── piece_d1002r1p1_start_20230111T193049.obarc // Piece開始プレースホルダー、piece_destID_roundID_PIECEID_start_DATE
    │   └── piece_d1002r1p1_end_20230111T193249.obarc   // Piece終了プレースホルダー、piece_destID_roundID_PIECEID_end_DATE
    └── piece_d1002r1p1                             // Pieceディレクトリ、ディレクトリ名形式は piece_destID_roundID_PIECEID
        ├── file_list.0.obarc
        ├── piece_d1002r1p1_20230111T193049_20230111T193249.obarc // Pieceの連続区間を記録
        ├── checkpoint
        ├── single_piece_info.obarc                 // そのPieceのメタ情報を記録
        ├── tenant_archive_piece_infos.obarc        // そのPieceの前のすべてのfrozen Pieceのメタ情報を記録
        ├── file_info.obarc                         // すべてのログストリームファイルリスト
        ├── logstream_1                             // 1号ログストリーム
        └── logstream_1001                          // 1001号ログストリーム

上記のログアーカイブディレクトリでは、最上位ディレクトリには以下の3種類のデータが含まれます：

• format.obbak：アーカイブパスのメタ情報を記録するために使用されます。これには、パスを使用するテナントなどの情報が含まれます。

• check_file：ユーザーログアーカイブディレクトリの接続性チェックに使用されます。

• rounds：ログアーカイブのRoundの集計リストで、すべてのRoundのリストが記録されています。

• pieces：ログアーカイブのPieceの集計リストで、すべてのPieceのリストが記録されています。

• piece_d1002r1p1：ログアーカイブのPieceディレクトリで、ディレクトリ名の形式はpiece_destID_roundID_PIECEIDです。ここで、DESTIDはlog_archive_destに対応するidを指し、ROUNDIDはログアーカイブのRoundのidで、単調増加する整数です。PIECEIDはログアーカイブのPieceのpiece_idであり、同様に単調増加する整数です。

  一つのログアーカイブのPieceディレクトリには、さらに以下のデータが含まれます：

  • file_list.0.obarc：このファイルは、現在のディレクトリに含まれるファイルとディレクトリを記録します。

  • piece_d1002r1p1_20230111T193049_20230111T193249.obarc：このファイルは、現在のPieceのID、開始時刻、終了時刻を表示するためのものであり、情報表示のみを目的としています。

  • checkpoint：このディレクトリは、ActiveなPieceのアーカイブポイントを記録するディレクトリであり、ObArchiveSchedulerモジュールが定期的にこのディレクトリのポイント情報を更新します。

  • single_piece_info.obarc：このファイルは、現在のPieceのメタ情報を記録します。

  • tenant_archive_pieceinfos.obarc：このファイルは、現在のテナント内のすべてのFrozen Pieceのメタ情報を記録します。

  • file_info.obarc：このファイルは、Piece内のログストリームリストを記録します。

  • logstream_1：このディレクトリは、1号ログストリームのログファイルを記録します。1号ログストリームはOceanBaseデータベーステナントのシステムログストリームです。

  • logstream_1001：このディレクトリは、1001号ログストリームのログファイルを記録します。1000より大きい番号のログストリームはOceanBaseデータベーステナントのユーザーログストリームです。

V3.x/V2.xバージョンとの機能差異の比較

ログアーカイブ

データバックアップ

物理復元

エコシステムパートナー認証状況

OceanBaseデータベースと認証を完了したバックアップ・リストアのエコシステムパートナーについては、産業エコシステムパートナーを参照してください。

産業エコシステムパートナーページのソリューションタイプの選択で、データ統合とバックアップ > **バックアップと復元**を選択すると、現在OceanBaseデータベースと認証を完了したバックアップ・リストアのエコシステムパートナーリスト、認証されたバージョン情報、および証明書の有効期限を確認できます。

関連ドキュメント

物理バックアップとリストアの詳細については、バックアップとリストアの章を参照してください。