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

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

概要

OceanBaseデータベースのバックアップ・リストアモジュールは、バックアップ、リストア、クリーンアップの3つの機能を提供します。

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

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

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

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

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

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

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

  説明

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

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

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

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

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

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

2. テナントレベルリストアは、フルリストアとクイックリストアをサポートします

   注意

   クイックリストアで復元されたテナントは、手動でメジャーコンパクションを開始したり、データバックアップを行ったり、Switchover/Failoverでプライマリデータベースになったりすることはできません。スタンバイデータベースとしてのみ存在できます。

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

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

3. 物理リストアのリストアポイントの選択

   • 完全リストア：リストアのタイムスタンプを指定しません。

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

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

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

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

SDKバージョン要件

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

インターフェース要件

• アリババクラウドOSS：

  • アリババクラウド公式のOSSをサポートしており、依存するインターフェースは下表のとおりです。

    インターフェース名	説明
    PutObject	単一オブジェクトをアップロード
    DeleteObject	単一オブジェクトを削除
    DeleteObjects	複数のオブジェクトを一括削除
    GetObject	特定のオブジェクトを取得
    ListObjects	ストレージ内のすべてのオブジェクトを一覧表示（強い整合性が必要）
    HeadObject	特定のオブジェクトのメタデータを取得
    AppendObject	追加書き込みでオブジェクトをアップロード
    PutObjectTagging（オプション）	オブジェクトのタグを設定または更新
    GetObjectTagging（オプション）	オブジェクトのタグを取得
    InitiateMultipartUpload	マルチパートアップロードを初期化
    UploadPart	パートをアップロード
    CompleteMultipartUpload	アップロード済みのパーツを1つのオブジェクトに統合
    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の場合は増分バックアップを表します
    ├── 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：このディレクトリはデータバックアップセットを表します。ディレクトリ名の末尾がfullの場合はフルバックアップ、incの場合は増分バックアップを表します。データバックアップごとに対応するバックアップセットが生成され、データバックアップ終了後はそのバックアップセットは変更されません。

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

  • 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
        ├── 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 の ID でもあり、単調増加する整数です。

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

  • piece_d1002r1p1_20230111T193049_20230111T193249.obarc：このファイルは、現在の Piece の ID、開始時刻、終了時刻を示しており、情報表示のみに使用されます。

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

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

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

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

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

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

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

ログアーカイブ

データバックアップ

物理復元

関連ドキュメント

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