Redoログ

このセクションでは、Redoログによるデータ永続化の仕組みとRedoログのアーカイブ方法について説明します。

概要

Redoログは、OceanBaseデータベースにおけるダウンタイムからの復旧および複数レプリカ間のデータ一貫性の維持に不可欠なコンポーネントです。Redoログは物理ログであり、データに対するすべての変更履歴を記録しており、具体的には1回の書き込み操作後の結果を記録します。特定の永続化されたデータバージョンからRedoログを1件ずつ再生することで、データの最新バージョンを復元できます。

OceanBaseデータベースのRedoログには、主に2つの役割があります：

• ダウンタイムからの復旧

  ほとんどの主流データベースと同様に、OceanBaseデータベースもWAL（write-ahead logging）の原則に従い、トランザクションのコミット前にRedoログを永続化することで、トランザクションの原子性と永続性（ACIDの「A」と「D」）を保証します。observerプロセスが終了したり、所属するサーバーがダウンした場合、OBServerノードを再起動すると、ローカルのRedoログをスキャンして再生し、データを復旧します。ダウン時に永続化されなかったデータは、Redoログの再生に伴って再生成されます。

• 複数レプリカ間のデータ一貫性

  OceanBaseデータベースはMulti-Paxosプロトコルを採用し、複数のレプリカ間でRedoログを同期します。トランザクション層にとって、1回の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データベースの1つのパーティションには3～5個のレプリカが存在する可能性があり、そのうち1つのレプリカのみがLeaderとして書き込みサービスを提供し、Redoログを生成できます。他のレプリカはすべて受動的にログを受信するしかありません。

ログの圧縮

OceanBaseデータベースはログ転送圧縮機能を提供しており、テナントレベルの構成パラメータlog_transport_compress_allを設定することで、Redoログがネットワーク転送中に圧縮されるかどうかを制御できます。ログ転送圧縮を有効にすると、Redoログの同期プロセスにおけるネットワーク帯域幅の使用量を削減できます。さらに、OceanBaseデータベースはログストレージ圧縮機能も提供しており、テナントレベルの構成パラメータlog_storage_compress_allを設定することで、Redoログがストレージされる前に圧縮されるかどうかを制御できます。ログストレージ圧縮を有効にすると、ログディスクI/O帯域幅の使用量とログディスク容量の占有率を低減できます。

ログの再生

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による対処を促します。