ログ同期の問題

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

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サービス復旧手順を実行することを推奨します。

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

  • リソースボトルネックがある場合、少数派ノードを隔離した後、リソースボトルネックを解消します。
  • リソースボトルネックがない場合、異常なノードで以下の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テクニカルサポートに連絡し、診断と対応を依頼してください。