この記事では、Redoログによるデータ永続化の仕組みとRedoログのアーカイブ方法について説明します。
概要
Redoログは、OceanBaseデータベースにおいてダウンタイムからの復旧や複数レプリカ間のデータ一貫性を維持するための重要なコンポーネントです。Redoログは物理ログであり、データに対するすべての変更履歴を記録しており、具体的には一度の書き込み操作後の結果を記録します。ある永続化されたデータバージョンからRedoログを順次再生することで、データの最新バージョンを復元することが可能です。
OceanBaseデータベースのRedoログには、主に2つの役割があります：
ダウンタイムからの復旧
ほとんどの主流データベースと同様に、OceanBaseデータベースもWAL（Write-Ahead Logging）原則に従い、トランザクションのコミット前にRedoログを永続化することで、トランザクションの原子性と永続性（ACIDの「A」と「D」）を保証します。もしobserverプロセスが終了したり、所属するサーバーがダウンした場合、OBServerノードを再起動すると、ローカルのRedoログをスキャンして再生し、データを復旧します。ダウン時に永続化されなかったデータは、Redoログの再生に伴って再生成されます。
複数レプリカ間のデータ一貫性
OceanBaseデータベースはMulti-Paxosプロトコルを採用し、複数のレプリカ間でRedoログを同期します。トランザクション層においては、一度のRedoログの書き込みが過半数のレプリカに同期された時点で成功と見なされます。また、トランザクションのコミットにはすべてのRedoログの正常な書き込みが必要です。最終的に、すべてのレプリカが同一のRedoログを受信し、データを再生します。これにより、正常にコミットされたトランザクションの変更はすべてのレプリカで有効になり、一貫性が保たれます。複数レプリカへのRedoログの永続化により、OceanBaseデータベースはより強力な災害復旧機能を提供できます。
ログファイルの種類
OceanBaseデータベースではテナント単位のログストリームを採用しており、各パーティションのすべてのログは論理的に連続的かつ順序付けられている必要があります。マシン上の同一テナントのすべてのTabletが生成するログは、同一のログストリームに書き込まれ、ログストリーム内のログには全順序関係が存在します。
OceanBaseデータベースのRedoログファイルはClogと呼ばれ、Clogの正式名称はCommit logであり、Redoログの内容を記録するために使用されます。Clogファイルはstore/clog/tenant_xxxxディレクトリに配置されます（ここで、xxxxはテナントIDを表します）。ファイル番号は0から連続的に増加し、ファイルIDは再利用されません。個々のログファイルのサイズは64MBです。これらのログファイルは、データベース内のデータに対する変更操作を記録し、データの永続性を保証します。
ログの生成
OceanBaseデータベースの各Redoログは最大2MBです。トランザクションの実行中、トランザクションコンテキスト内でデータの書き込みやロックなどの履歴操作が維持されます。V3.x以前のバージョンでは、OceanBaseデータベースはトランザクションのコミット時にのみ、トランザクションコンテキスト内に保存された履歴操作をRedoログに変換し、2MB単位でClogモジュールにコミットしています。Clogモジュールはログをすべてのレプリカに同期し、永続化する役割を担います。V3.x以降のバージョンでは、OceanBaseデータベースに即時ログ書き込み機能が追加されました。トランザクション内のデータが2MBを超えると、Redoログが生成され、Clogモジュールにコミットされます。2MB単位でコミットするのは主にパフォーマンスを考慮したものであり、各ログがClogモジュールにコミットされた後、Multi-Paxosによって過半数のレプリカに同期される必要があります。このプロセスでは多くのネットワーク通信が発生し、時間もかかります。そのため、従来のデータベースと比較して、OceanBaseデータベースの単一のRedoログには複数回の書き込み操作の内容が集約されています。
OceanBaseデータベースの一つのパーティションには3～5個のレプリカが存在する可能性があり、そのうちの1つのレプリカのみがリーダーとして書き込みサービスを提供し、Redoログを生成することができます。他のレプリカは受動的にログを受信するだけです。
ログの圧縮
OceanBaseデータベースはログ転送圧縮機能を提供しており、テナントレベルの構成パラメータlog_transport_compress_allを設定することで、ネットワーク転送時のRedoログの圧縮を制御できます。ログ転送圧縮を有効にすると、Redoログの同期プロセスにおけるネットワーク帯域幅の使用量を削減できます。さらに、OceanBaseデータベースはログストレージ圧縮機能も提供しており、テナントレベルの構成パラメータlog_storage_compress_allを設定することで、ストレージ前のRedoログの圧縮を制御できます。ログストレージ圧縮を有効にすると、ログディスクI/O帯域幅の使用量とログディスク容量の占有を低減できます。
ログの再生
説明
OceanBaseデータベースは、トランザクション層でREDOログの並列再生と並列コミットをサポートしています。
Redoログの再生は、OceanBaseデータベースが高可用性を提供するための基盤です。ログがフォロワーレプリカに同期されると、レプリカは**transaction_id + コールバック操作チェーンリストのインデックス値**に基づいてハッシュし、現在のテナントのログ再生スレッドプール内の異なるタスクキューで再生します。OceanBaseデータベースでは、異なるトランザクションのRedoログを並列再生できるほか、同一トランザクション内の異なるRedoログも並列再生可能であり、再生速度の向上と同時に再生の正確性も保証されます。ログがレプリカ上で再生される際には、まずトランザクションコンテキストが作成され、その後トランザクションコンテキスト内で操作履歴が復元されます。そして、コミットログが再生される際にトランザクションがコミットされ、これはレプリカのイメージ上でトランザクションが再度実行されたことに相当します。
ログの災害復旧
Redoログを再生することで、レプリカは最終的にリーダー上で実行されたトランザクションを再実行し、リーダーと一致したデータ状態を取得します。あるパーティションのリーダーが存在するマシンに障害が発生した場合、または負荷が高すぎてサービスを提供できない場合、別のマシン上のレプリカを新しいリーダーとして再選択できます。両者は同じログとデータを持っているため、新しいリーダーはサービスを継続できます。障害が発生したレプリカが半数を超えない限り、OceanBaseデータベースはサービスを継続できます。障害が発生したレプリカは再起動後にログを再再生し、永続化されていないデータを復元し、最終的にリーダーと一致した状態になります。
従来のデータベースでは、障害によるダウンまたは新しいリーダーの再選択に関わらず、実行中のトランザクションはメモリ情報の損失に伴い状態が失われます。その後、再生によって復元されたアクティブなトランザクションは状態が不明であるため、ロールバックするしかありません。Redoログの観点から見ると、すべてのログが再生された後もコミットログが存在しないことになります。OceanBaseデータベースでは、新しいリーダーの再選択時に一定時間、実行中のトランザクションが自身のデータとトランザクション状態をログに書き込み、過半数のレプリカにコミットすることを許可します。これにより、新しいリーダー上でトランザクションを継続実行できます。
ログの追加記録
データベーストランザクションを実行する際、UPDATE型のSQL文については、データベースシステムが操作の永続性と復旧可能性を保証するためにRedoログを生成します。デフォルトのFULLモードでは、Redoログには更新された行の完全な情報が記録され、変更されていない列の値も含まれます。一方、Minimalモードでは、Redoログはこれらの情報を簡略化し、変更された列と必要なコンテキスト情報のみを含むことで、ログサイズを削減し、ストレージ効率を最適化します。
ログの制御と回収
ログファイルにはデータベースのすべての変更が記録されているため、回収の前提条件として、ログ関連データがすべてディスクに永続化されている必要があります。データが永続化される前にログを回収すると、障害発生時にデータを復旧できません。
現在のOceanBaseデータベースのログ回収ポリシーでは、ユーザーが確認できる構成パラメータは2つあります：
clogディスク容量の使用上限は、グローバル構成パラメータ
log_disk_utilization_limit_thresholdによって制御され、デフォルト値は95で、Clogが使用できるディスク容量が全体のディスク容量に占める割合を表します。これは厳密な制限であり、この値を超えると、そのOBServerノードは新しいトランザクションの書き込みを許可せず、他のOBServerノードからの同期ログの受信も許可されません。外部から見ると、このOBServerノードへの読み書きトランザクションはすべてエラーとして報告され、"transaction needs rollback"となります。Clogディスクの再利用下限は、構成パラメータ
log_disk_utilization_thresholdによって制御されます。システムが正常に動作している場合、Clogはこの水準から最も古いログファイルの再利用を開始します。デフォルト値はClog専用ディスク容量の80%であり、通常は変更を推奨しません。したがって、正常に稼働している場合、Clogディスク容量の使用率は80%を超えることはありません。超えるとエラー"clog disk is almost full"が報告され、DBAによる対処を促します。