フィジカルバックアップとリカバリの概要

バックアップとリカバリは、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（V4.3.5バージョンでは、V4.3.5 BP3以降のバージョンからサポートされています）、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	アップロード済みのパートを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公式サイトを参照してください。

バックアップメディアを選択する際には、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_set_infos.obbak                       // 現在のテナントのフルバックアップセット情報
    ├── infos
    │   ├── table_list                                      //フルテーブル名ファイル
    │   │   ├── table_list.1702352553000000000.1.obbak      //テーブル名ファイル1
    │   │   ├── table_list.1702352553000000000.2.obbak     //テーブル名ファイル2
    │   │   └── table_list_meta_info.1702352553000000000.obbak  //テーブル名メタ情報ファイル
    │   ├── major_data_info_turn_1                           // major turn 1のテナントレベルのバックアップファイル
    │   │   ├── tablet_log_stream_info.obbak                 // tabletとログストリームのマッピングファイル
    │   │   ├── tenant_major_data_macro_range_index.0.obbak  // majorマクロブロックインデックス
    │   │   ├── tenant_major_data_meta_index.0.obbak         // major metaインデックス
    │   │   └── tenant_major_data_sec_meta_index.0.obbak     // major論理idと物理idのマッピングファイル
    │   ├── minor_data_info_turn_1                           // minor turn 1のテナントレベルのバックアップファイル
    │   │   ├── tablet_log_stream_info.obbak                 // tabletとログストリームのマッピングファイル
    │   │   ├── tenant_minor_data_macro_range_index.0.obbak  // minorマクロブロックインデックス
    │   │   ├── tenant_minor_data_meta_index.0.obbak         // minor metaインデックス
    │   │   └── tenant_minor_data_sec_meta_index.0.obbak     // minor論理idと物理idのマッピング
    │   ├── diagnose_info.obbak                              // バックアップセット診断情報ファイル
    |   ├── tenant_parameter.obbak                           // 現在のテナントのデフォルト以外の設定のテナントレベルの構成パラメータ情報
    │   ├── locality_info.obbak                              // 現在のバックアップセットに属するテナントのlocality情報で、テナントのリソース構成情報とレプリカの分散情報が含まれます
    │   └── meta_info                                        // テナントレベルのログストリームメタ情報ファイルで、すべてのログストリームのメタ情報が含まれます
    │       ├── ls_attr_info.1.obbak                         // バックアップ時のログストリームリストのスナップショット
    │       └── ls_meta_infos.obbak                          // すべてのログストリームのmeta集合
    ├── logstream_1                                          // 1番目のログストリーム
    │   ├── major_data_turn_1_retry_0                        // turn 1,retry 0のベースラインデータ
    │   │   ├── macro_block_data.0.obbak                     // 512MB～4GBのサイズのデータファイル
    │   │   ├── macro_range_index.obbak                      // macroインデックス
    │   │   ├── meta_index.obbak                             // metaインデックス
    │   │   └── sec_meta_index.obbak                         // 論理idと物理idのマッピングファイル
    │   ├── meta_info_turn_1_retry_0                         // turn 1,retry 0のログストリームメタ情報ファイル
    │   │   ├── ls_meta_info.obbak                           // ログストリームメタ情報
    │   │   └── tablet_info.1.obbak                          // ログストリームtablet metaリスト
    │   ├── minor_data_turn_1_retry_0                        // turn 1,retry 0のダンプデータ
    │   │   ├── macro_block_data.0.obbak
    │   │   ├── macro_range_index.obbak
    │   │   ├── meta_index.obbak
    │   │   └── sec_meta_index.obbak
    │   └── sys_data_turn_1_retry_0                          //turn 1, retry 0のシステムtabletデータ
    │       ├── macro_block_data.0.obbak
    │       ├── macro_range_index.obbak
    │       ├── meta_index.obbak
    │       └── sec_meta_index.obbak
    └── logstream_1001                                       // 1001番目のログストリーム
        ├── major_data_turn_1_retry_0
        │   ├── macro_block_data.0.obbak
        │   ├── macro_range_index.obbak
        │   ├── meta_index.obbak
        │   └── sec_meta_index.obbak
        ├── meta_info_turn_1_retry_0
        │   ├── ls_meta_info.obbak
        │   └── tablet_info.1.obbak
        ├── minor_data_turn_1_retry_0
        │   ├── macro_block_data.0.obbak
        │   ├── macro_range_index.obbak
        │   ├── meta_index.obbak
        │   └── sec_meta_index.obbak
        └── sys_data_turn_1_retry_0
            ├── macro_block_data.0.obbak
            ├── macro_range_index.obbak
            ├── meta_index.obbak
            └── sec_meta_index.obbak

データバックアップディレクトリでは、トップレベルのディレクトリには以下の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_set_infos.obbak：このファイルは現在のテナントが既に持っているすべてのバックアップセットのメタ情報を記録しています。

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

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

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

  同時に、各ログストリームバックアップには4種類のディレクトリがあり、retryを含むディレクトリはログストリームレベルのリトライを表し、turnを含むディレクトリはテナントレベルのリトライを表します：

  • meta_info_xx：このディレクトリはLSメタ情報とTabletメタ情報を記録しています。
  • sys_data_xx：このディレクトリはLS内部システムTabletのデータを記録しています。
  • minor_data_xx：このディレクトリは通常のTabletのダンプデータを記録しています。
  • major_data_xx：このディレクトリは通常のTabletのベースラインデータを記録しています。

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

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

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
        │   └── checkpoint.1673436649723677822.obarc   // checkpoint_scn情報を記録、ファイル名のコマンド形式はcheckpoint.checkpoint_scn
        │   └── checkpoint_info.0.obarc             // checkpointのメタ情報を記録
        ├── single_piece_info.obarc                 // そのPieceのメタ情報を記録
        ├── tenant_archive_pieceinfos.obarc        // そのPieceより前のすべてのFrozen Pieceのメタ情報を記録
        ├── file_info.obarc                         // すべてのログストリームファイルリスト
        ├── logstream_1                             // 1号ログストリーム
        │   ├── file_info.obarc                    // ログストリーム1のファイルリスト
        │   ├── log
        │   │   └── 1.obarc                         // 1号ログストリームのアーカイブファイル
        │   └── schema_meta                         // データ辞書のメタ情報を記録、このファイルは1号ログストリームでのみ生成されます
        │       └── 1677588501408765915.obarc
        └── logstream_1001                          // 1001号ログストリーム
            ├── file_info.obarc                      // 1001号ログストリームのファイルリスト
            └── log
                └── 1.obarc                          // 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モジュールが定期的にこのディレクトリのポイント情報を更新します。その中で：

    • checkpoint.1673436649723677822.obarc：このファイル名にはPieceのcheckpoint_scn情報が記録されており、1673436649723677822が対応するcheckpoint_scnです。

    • checkpoint_info.0.obarc：このファイルはアクティブなPieceのcheckpointのメタ情報を記録しており、これらのメタ情報にはtenant_id、dest_id、round_id、piece_idなどが含まれます。メタ情報は1つのPiece内で変更されません。

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

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

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

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

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

  同時に、各ログストリームバックアップには3種類のデータがあります：

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

  • log：このディレクトリには現在のログストリームのすべてのアーカイブファイルが保存されており、ファイル名とソースクラスタ内部のログファイルは一致しています。

  • schema_meta：このディレクトリはデータ辞書のメタ情報を記録しており、システムログストリームにのみ存在し、ユーザーログストリームにはこのディレクトリはありません。

AWS S3およびS3プロトコルに互換性のあるバックアップメディアについては、ログアーカイブのディレクトリ構造はOSS、NFS、COSなどとは異なります。個々のアーカイブファイルは複数の小さなファイルとそれに対応するメタ情報ファイルで構成されており、具体的なディレクトリ構造は以下のとおりです。

log_archive_dest
    ├── ......
    └── piece_d1002r1p1                             // Pieceディレクトリ、ディレクトリ名の形式はpiece_destID_roundID_PIECEID
        ├── ......                         					// すべてのログストリームファイルリスト
        ├── logstream_1                             // 1号ログストリーム
        │   ├── file_info.obarc                    // 1号ログストリームのファイルリスト
        │   ├── log
        │   │   └── 1.obarc                         // 1号ログストリームのアーカイブファイル、プレフィックスで識別
        |		|       └── @APD_PART@0-32472973.obarc  // アーカイブファイル内の実際のデータ、ログファイルの0～32472973バイトのデータを記録
        |		|		    └── ......
        |		|		    └── @APD_PART@FORMAT_META.obarc // アーカイブファイルのフォーマット
        |		|		    └── @APD_PART@SEAL_META.obarc   // アーカイブファイルのメタ情報
        │   └── schema_meta                         // データ辞書のメタ情報を記録、このファイルは1号ログストリームでのみ生成されます
        │       └── 1677588501408765915.obarc
        └── logstream_1001                          // 1001号ログストリーム
            ├── file_info.obarc                      // 1001号ログストリームのファイルリスト
            └── log
                └── 1.obarc                          // 1001号ログストリームのアーカイブファイル

上記のログアーカイブディレクトリでは、1.obarcは個々のアーカイブファイルを表し、個々のアーカイブファイルはプレフィックスで識別され、プレフィックス名とアーカイブファイル名は完全に同一です。個々のアーカイブファイルには主に以下の3種類のデータが含まれます：

• @APD_PART@FORMAT_META.obarc：アーカイブファイルへの最初の書き込み時に、このディレクトリにformat_metaファイルが書き込まれ、アーカイブファイルのフォーマットを記録するために使用されます。

• @APD_PART@0-32472973.obarc：アーカイブファイル内の実際のデータは、このプレフィックス名で命名されたファイルに書き込まれ、毎回の書き込みの開始オフセットと終了オフセットがファイル名に記録されます。

• @APD_PART@SEAL_META.obarc：アーカイブファイルへの最後のデータ書き込み後、このディレクトリにseal_metaファイルが生成され、アーカイブファイル内のメタ情報を記録するために使用されます。

V3.x/V2.x系との機能差異の比較

ログアーカイブ

データバックアップ

物理復旧

関連ドキュメント

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