ログ同期の問題

本記事では、ログ同期の基本原理とよくある質問について説明します。

OceanBase clogの正式名称はOceanBase Commit Logであり、OceanBaseログサービスの中核です。ログサービスはOceanBaseデータベースの基盤コンポーネントであり、トランザクションの原子性、永続性、隔離性およびデータベースの高可用性などのコア機能を支える役割を担っています。データベースのコミットプロセスでは、Paxosプロトコルにより過半数のclogがディスクに書き込まれることが保証され、少数派のclogログ内容も最終的にはハードディスクに永続化されます。OceanBaseデータベースには、ログディスクの継続的な書き込み可能性を保証するための自動ログ回収メカニズムが備わっています。

一般的なclogの問題には、clogディスク満杯、clog再生の停止、clog同期の遅延、clogスライディングウィンドウの満杯、clog再確認失敗などがあります。本記事では、clogディスク満杯のトラブルシューティングと原因特定方法について紹介します。

トラブルシューティング手法

ビュー GV$OB_LOG_STAT/V$OB_LOG_STAT はログモジュールの状態を表示します。代表的な利用シナリオは以下のとおりです。

• ログストリームにリーダーが存在するかどうか、およびリーダーが配置されているレプリカを確認する場合。
• ログストリームのメンバーリストや Paxos レプリカ数を確認する場合。
• レプリカの同期状態を確認する場合。
• ログストリームのログで回収可能なポイントを確認する場合。
• ログストリームがログ消費サービスを提供可能な範囲（LSN/SCN を含む）を確認する場合。
• ログモジュールのアクセスパターンを確認する場合。
• その他の問題特定ニーズなど。

重要な構成パラメータ

clogディスクが満杯になる

通常、clogディスクの使用率は一定のしきい値を維持しており、設定されたしきい値を超えると、回収可能なログファイルが回収されます。一度設定されたしきい値を超えると、ログファイルの回収が遅延しているか、または停止していることを示します。

clogファイルが回収される条件：そのファイル内のすべてのパーティションログに対応するデータがすでにSSTableにダンプされていることです。したがって、通常clogディスクが満杯になる原因は、一部のパーティションのダンプが停止していることです。

トラブルシューティングの手順

clogディスク容量がアラートを開始した後、以下の手順でトラブルシューティングを実施します：

1. ログディスクが満杯かどうかを判断する方法。

   GV$OB_UNITSビューを参照して、ログストリームのログディスク使用量がディスク回収ウォーターマーク（デフォルトは80%で、パラメータlog_disk_utilization_thresholdで調整可能）を超えていないか確認します。具体的なSQL文は以下のとおりです：

   select tenant_id, svr_ip, svr_port,
   LOG_DISK_IN_USE/1024/1024/1024 LOG_DISK_IN_USE_G,
   LOG_DISK_SIZE/1024/1024/1024 LOG_DISK_SIZE_G,
   LOG_DISK_IN_USE*100/LOG_DISK_SIZE LOG_DISK_USED_PERCENTAGE
   from gv$ob_units;
   

2. テナント内で異常が発生しているログストリームを特定する。

   テナントのログディスク使用量がテナントのログディスク仕様の80%を超えている場合、そのテナント内で異常が発生しているログストリームをさらに特定する必要があります。(END_LSN - BASE_LSN)は、対応するログストリームでまだ回収できないログ量（バイト）を表します。使用量が128MBを超え、かつログディスクが満杯の状態が同時に存在する場合、そのログストリームがログ回収をブロックしています。具体的なSQL文は以下のとおりです：

   select TENANT_ID, LS_ID, SVR_IP, ROLE ,
   (end_lsn-base_lsn)/1024/1024
   from gv$ob_log_stat;
   

   関連ビューにアクセスできない場合は、システムログからも検索できます。例：

   grep 'ERROR.*Txxxx_PalfGC' observer.log.*
   [2022-07-19 21:34:37.191950] ERROR [PALF] try_recycle_blocks (palf_env_impl.cpp:637) [147234][T1010_PalfGC][T1010][Y0-0000000000000000-0-0] [lt=21] clog disk space is almost full(total_size(MB)=165888, used_size(MB)=132710, used_percent(%)=80, warn_size(MB)=132710, warn_percent(%)=80, limit_size(MB)=157593, limit_percent(%)=95, maximum_used_size(MB)=74026, maximum_log_stream=1006, oldest_log_stream=1004, oldest_timestamp=1658223124759857784) BACKTRACE:0x434d92e 0xc1a323a 0xc194b93 0x44726d4 0x447239f 0x44721cb 0x4471ffd 0x45b102c 0x45b0339 0x43671aa 0x4365b6d 0x521ebf9 0xc396ec6 0xc391b19 0x7f337d6bfe24 0x7f337cf68f1c
   

   ここで：

   • maximum_log_stream：ログディスク容量を最も多く使用しているログストリームを表します。
   • oldest_log_stream：ログが最も古いログストリームを表します。

3. ログディスク満杯の根本原因を特定する。

   1. ログ再生/コールバックに問題がないか確認し、前のステップで取得したテナント、ログストリーム、およびディスク満杯のマシンに基づいてさらに調査します。

      • レプリカロールがLeaderの場合、ログ同期異常の原因をさらに確認する必要があります。
        • Leaderレプリカのローカル書き込みポイントが最新に反映されていない場合、書き込みが遅いか、または停止している可能性があります。
        • Leaderレプリカのローカル書き込みポイントが最新に反映されている場合、ローカル書き込みは完了していることを意味し、Followerレプリカに異常が発生していないか調査する必要があります。
          • よくある異常は、Follower上のログディスクが満杯になり、新しいログを受け付けられないことです。遅延しているFollower上で、ディスク満杯に関連するログがないか検索できます。
          • LeaderとFollower間のRPC通信に異常が発生している可能性があります。例えば、Follower上のRPCリクエストキューに積み上がりが発生している場合です。遅延しているFollower上で、RPCキューの積み上がりに関連するログがないか検索できます。
          • RPCがリクエストを処理する際にメモリ割り当てに失敗している可能性もあります。遅延しているFollower上で、メモリ割り当て失敗に関連するログがないか検索できます。
      • レプリカロールがFollowerの場合、ログ再生異常の原因をさらに確認する必要があります。
        • 再生サービスはFollowerレプリカのログ再生を担当しており、OBServerで予期しないエラーが発生した場合、後続のログ再生を阻止し、より深刻な整合性の問題を防ぎます。ログ再生異常は必ずしも再生サービス自体の問題を意味するわけではなく、エラーログから具体的なモジュールを特定する必要があります。

   2. 凍結に問題がないか確認します。

      凍結プロセスに関連するシステムログは以下のとおりです：

      # システムの小規模凍結開始
      receive minor freeze reques
      
      # システムの小規模凍結終了
      finish minor freeze request
      
      # テナントレベルの凍結開始
      [TenantFreezer] tenant_freeze start
      
      # テナントレベルの凍結成功
      [TenantFreezer] succeed to freeze tenant
      
      # テナント内の特定のログの凍結失敗
      [TenantFreezer] fail to freeze logstream
      
      # パーティションレベルの凍結開始
      [TenantFreezer] tablet_freeze start
      
      # パーティションの凍結成功
      [TenantFreezer] succeed to freeze tablet
      
      # パーティションの凍結失敗
      [TenantFreezer] fail to freeze tablet
      

   3. ダンプに問題がないか確認します。

緊急時の対応策

• 多数派ノードに影響が及び、トランザクションのコミットが妨げられている場合、つまりシステム全体でハングや応答停止が発生している場合。このとき、上位アプリケーションから依然として大量のトランザクション書き込みがある場合は、アプリケーション負荷を一時停止し、その後以下のclogサービス復旧手順を実行することを推奨します。

• 少数派ノードのみに影響が及んでいる場合、該当ノードにおけるI/O層またはネットワーク層（インフラ層）のリソースボトルネックがないか迅速に分析する必要があります。

  • リソースボトルネックがある場合、少数派ノードを隔離した上でリソースボトルネック問題を解消します。
  • リソースボトルネックがない場合、異常なノードで以下のclogサービス復旧手順を実行します。

復旧手順：

1. clogディスクが満杯になると自動的に書き込みを停止します。これはパラメータlog_disk_utilization_limit_thresholdによって制御されます。一時的にこの値を98に引き上げることも可能です（ディスク満杯のノードのみを指定すればよい）。変更後、遅延しているレプリカは直ちにログ追従をトリガーし、遅延が大きい場合は再構築（rebuild）が実行されます（rebuildとは、Leaderレプリカからデータとclogを直接コピーすることを指し、単にclogを取得するだけではありません）。

2. 内部テーブルをクエリして、再構築操作およびclog同期の進捗状況を確認します。

3. log_disk_utilization_limit_thresholdを引き上げてもclogディスクが継続的に満杯になる問題が解消されない場合、OBServerを停止した上で、clogファイルを別のストレージ容量の大きいディレクトリにコピーし、ソフトリンクで接続します。操作完了後、OBServerを再起動します。clogディスクの使用率が95%以下に下がった場合、OBServerの復旧は順調であることを意味します。その後、すべてのレプリカがsync状態に達するのを待機するだけです。

   注意

   この手順には一定の操作リスクが伴います。クラスタが回復不能な場合の緊急時の最終手段です。ログファイルをコピーする際は、誤操作を避けてください。

4. すべての操作およびパラメータをロールバックします。

clogディスク満杯の一般的な原因

• 運用保守上の問題

  clogディスクが配置されている領域が他ユーザーのファイルによって占有され、利用可能な空き容量が不足している。

• ダンプが継続的に失敗する場合

  clogに含まれるパーティションデータがすべてSSTableにダンプされ、メタ情報も永続化されたダウン/再起動時の開始ポイントまで反映された場合、clogファイルは回収可能となります。したがって、ダンプが失敗したり、ダウン/再起動時のclog再生開始ポイントが進まなかったりすると、clogファイルは回収できません。ダンプが継続的に失敗するロジックは複雑なため、このような状況に遭遇した場合は、OceanBaseのテクニカルサポートに連絡し、診断と対応を依頼してください。