ログ同期の問題

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

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は、ログモジュールの状態を表示します。主な利用シナリオは以下の通りです：

• ログストリームにリーダーが存在するかどうか、およびリーダーが配置されているレプリカを照会する。
• ログストリームのメンバーリストやパクソスレプリカ数を照会する。
• レプリカ同期状態を照会する。
• ログストリームのログから回収可能なポイントを照会する。
• ログストリームで許可されるログ消費サービスの範囲（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サービスの復旧操作を実行することを推奨します。

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

  • リソースボトルネックがある場合は、少数派ノードを隔離してからリソースボトルネックを解消します。
  • リソースボトルネックがない場合は、異常ノードで以下のclogサービスの復旧操作を実行します。

復旧操作：

1. clogディスクが上限になると自動的に書き込みが停止します。これは構成パラメータlog_disk_utilization_limit_thresholdによって制御され、一時的に98に引き上げることができます（ディスクが上限になったノードのみを指定することも可能です）。変更後、遅延しているレプリカは直ちにログ追従をトリガーし、遅延が大きい場合は再構築（rebuild）アクションがトリガーされます（rebuildとは、clogの取得だけでなく、Leaderレプリカから直接データと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テクニカルサポートに連絡し、診断を依頼してください。