ログアーカイブのディレクトリ構造
ログアーカイブは、ユーザーが PIECE_SWITCH_INTERVAL パラメータで指定することにより、分割ディレクトリの時間間隔を決定できます。デフォルトでは1日ごとにディレクトリが分割されます。つまり、毎日のログデータディレクトリはそれぞれ1つの backup_piece に対応します。
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：このディレクトリはアクティブな 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 Piece のメタ情報を記録します。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、Azure Blob などとは異なります。個々のアーカイブファイルは複数の小さなファイルとそれに対応するメタ情報ファイルで構成されており、具体的なディレクトリ構造は以下のとおりです。
説明
AWS S3とNFS、OSS、Azure Blobなどのバックアップメディアのログアーカイブディレクトリ構造は異なりますが、AWS S3上のバックアップファイルを他のバックアップメディアへクロスクラウドコピーした後でも、復元は引き続きサポートされます。例えば、AWS S3からアーカイブされたデータをOSSにコピーし、そのOSSパスを使用しても、正常に復元できます。
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ファイルが生成され、アーカイブファイル内のメタ情報を記録するために使用されます。
データバックアップのディレクトリ構造
単一のデータバックアップは1つのbackup_setに対応します。ユーザーがALTER SYSTEM BACKUP DATABASEを実行するたびに、新しいbackup_setのディレクトリが作成され、このディレクトリには今回のバックアップのすべてのデータが含まれます。
データバックアップのディレクトリ構造は以下のとおりです：
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メタインデックス
│ │ └── 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メタインデックス
│ │ └── tenant_minor_data_sec_meta_index.0.obbak // minor論理idと物理idのマッピング
│ ├── diagnose_info.obbak // バックアップセット診断情報ファイル
| ├── tenant_parameter.obbak // 現在のテナントのデフォルト以外の設定のテナントレベルの構成パラメータ情報
│ ├── locality_info.obbak // 現在のバックアップセットに属するテナントのローカリティ情報で、テナントのリソース構成情報とレプリカの分散情報を含みます
│ └── meta_info // テナントレベルのログストリームメタ情報ファイルで、すべてのログストリームのメタ情報を含みます
│ ├── ls_attr_info.1.obbak // バックアップ時のログストリームリストのスナップショット
│ └── ls_meta_infos.obbak // すべてのログストリームのメタ集合
├── logstream_1 // 1番目のログストリーム
│ ├── major_data_turn_1_retry_0 // turn 1,retry 0のベースラインデータ
│ │ ├── macro_block_data.0.obbak // 1つのデータファイルで、サイズは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メタリスト
│ ├── 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