マージ異常のトラブルシューティング

マージ異常は、テスト環境においてよく見られる問題の一つです。マージ異常により、クエリの遅延、ディスク容量の異常な使用、DDLの無効化、チェックサムエラーなどの問題が発生する可能性があります。

皆様が迅速に問題の根本原因を特定し、効率的に解決できるよう支援するため、本記事では明確かつ実用的なマージ異常のトラブルシューティングプロセスをまとめました。このプロセスは、明確な操作手順を提供し、問題処理の効率を向上させ、業務への影響を最小限に抑えることを目的としています。また、日常的な運用保守作業を強力にサポートします。

マージ異常のトラブルシューティングプロセスは以下の図に示されています。

プロセスの紹介

1. システムテーブルおよびRS層での同時実行状況を確認します。

   1. テナントのコンパクション状態を確認します。システムテナントの下で、CDB_OB_MAJOR_COMPACTIONビューを確認し、各テナントのコンパクション状態を確認します。

      obclient(root@sys)[oceanbase]> SELECT * FROM oceanbase.CDB_OB_MAJOR_COMPACTION;
      

      クエリ結果に基づいて、LAST_SCN = GLOBAL_BROADCAST_SCN の場合、前回のコンパクションが完了したバージョン番号と現在のコンパクションバージョン番号が同じであり、このラウンドのコンパクションは終了しています。そうでない場合は、他のフィールドに基づいてさらに確認する必要があります：

      • IS_SUSPENDED列がTrueの場合、コンパクションが手動で一時停止されたことを示します。SQL文ALTER SYSTEM RESUME MERGE TENANT tenant_name;を実行して復旧する必要があります。

      • STATUSが継続的にCOMPACTINGの場合、コンパクションがスタックしていることを示します。さらに調査する必要があります。

      • IS_ERRORが空ではない場合、さらに調査する必要があります。IS_ERRORの値がCHECKSUM_ERRORの場合、そのテナントでチェックサム検証の不一致が発生したことを示します。

   2. 現在のテナントのすべてのtabletのコンパクション進捗状況を照会し、指定されたバージョンにコンパクションされていないレコードをフィルタリングします。

      コンパクションが終了したかどうかを判断するロジックは、そのテナントのすべてのTablet（要件を満たさない一部のTabletを除外）が指定されたバージョン番号にコンパクションされているかどうかを確認することです。指定されたバージョンにコンパクションされていないTabletが1つでもあれば、そのテナントのコンパクションは終了しません。次に、そのテナントのどのTabletが指定されたバージョンにコンパクションされていないかを確認する必要があります。

      CDB_OB_TABLET_REPLICASおよびCDB_OB_MAJOR_COMPACTIONビューを照会します。tenant_id = 1004を例にします。

      obclient(root@sys)[oceanbase]> SELECT
          t.svr_ip,
          t.svr_port,
          t.tenant_id,
          t.ls_id,
          t.tablet_id,
          t.compaction_scn AS tablet_version,
          m.global_broadcast_scn AS target_version
      FROM
          oceanbase.CDB_OB_TABLET_REPLICAS t,
          oceanbase.CDB_OB_MAJOR_COMPACTION m
      WHERE
          t.tenant_id = m.tenant_id
          AND t.tenant_id = 1004
          AND m.global_broadcast_scn > 0
          AND (t.compaction_scn < m.global_broadcast_scn)
      ORDER BY t.compaction_scn;
      

      クエリ結果に基づいて：

      • クエリ結果がNULLの場合、RSの検証段階であり、コンパクションは正常です。

      • クエリ結果がNULLでない場合、クエリ結果は指定されたバージョンにコンパクションされていないTabletです。

        その中で、compaction_scnフィールドはCDB_OB_TABLET_REPLICASビューから取得され、現在のTabletがコンパクションを完了した最大SCNを示します。global_broadcast_scnフィールドはCDB_OB_MAJOR_COMPACTIONビューから取得され、このラウンドのコンパクションのターゲットバージョンを示します。compaction_scn < global_broadcast_scnの場合、Tabletがコンパクションを完了していないことを示し、さらに調査する必要があります。

   3. Tabletがコンパクションを完了していない場合、Tabletがコンパクションタスクを実行しているかどうかを確認する必要があります。

      GV$OB_TABLET_COMPACTION_PROGRESSビューを照会します。tenant_id = 1004を例にします。

      obclient(root@sys)[oceanbase]> SELECT * FROM oceanbase.GV$OB_TABLET_COMPACTION_PROGRESS WHERE tenant_id = 1004 AND type = "MAJOR_MERGE" AND status LIKE "%RUNNING%";
      

      クエリ結果に基づいて、Tabletがコンパクションを実行している場合は、コンパクション完了を待機します。一定時間待機しても、実行中のTabletがなく、CDB_OB_TABLET_REPLICASおよびCDB_OB_MAJOR_COMPACTIONビューでコンパクションが完了していないTabletの数が減少しない場合は、コンパクション診断ビューを照会して、問題をさらに特定します。

2. コンパクション診断ビューを照会して、診断情報を取得します。

   コンパクション診断ビューには、コンパクションプロセス中のさまざまな例外エラー情報が含まれており、トラブルシューティングに役立ちます。tenant_id = 1004でコンパクションが完了していないTabletのTablet_ID = 200001を例にします。

   obclient(root@sys)[oceanbase]> SELECT * FROM oceanbase.GV$OB_COMPACTION_DIAGNOSE_INFO WHERE TENANT_ID = 1004 AND TABLET_ID = 200001\G
   

   diagnose_infoフィールドに表示される情報に基づいて、次の処理を実行します：

   • weak read ts is not readyまたはslave_read_version is less than freeze_ts, can not merge：スレーブの読み取りがメジャポイントをプッシュしていないため、コンパクション異常が発生しました。技術サポートに連絡して、対応をお願いします。

   • memtable can not minor merge：MemTableがダンプ条件に達していないため、Mini Compactionが遅く、clog回収が遅く、メモリが爆発しています。技術サポートに連絡して、対応をお願いします。

   • sstable count is not safe：SSTableの数が多すぎるため、Mini compactionができず、clog回収が遅く、メモリが爆発しています。技術サポートに連絡して、対応をお願いします。

     同時に、diagnose_infoにはSSTableの数が多すぎる原因も表示されます：

     • SNAPSHOT_FOR_MAJOR：Major Compaction

     • SNAPSHOT_FOR_DDL：テーブルのDDL、例えばインデックス作成。

     • SNAPSHOT_FOR_MULTI_VERSION：マルチバージョンデータが多すぎ、undo_retentionの値が大きすぎます。

   • dag may hang：DAGが一定時間更新されておらず、スタックしている可能性があります。10分以上この状態が続く場合は、技術サポートに連絡して、対応をお願いします。

   • freeze_info is invalid：freeze_infoがプッシュされていないため、コンパクション異常が発生しました。技術サポートに連絡して、対応をお願いします。

   • memtable rec_log_ts not stable：ログストリームのフリーズプロセス中に、連続する最大のリコール（再生）ポイントが長時間、対応するTabletのMemTableのrec_log_tsをプッシュしていないため、より深い原因はリコール（再生）が遅いことです。技術サポートに連絡して、対応をお願いします。

   • traverse_trans_to_submit_redo_log failed：redo logの送信に失敗しました。技術サポートに連絡して、対応をお願いします。

   • trans table has not merged, can not schedule minor merge：V3.2.xバージョンでは、トランザクション状態テーブルのダンプが成功した後にのみ、データテーブルのダンプを開始できます。これにより、データテーブルがダンプされない可能性があります。技術サポートに連絡して、対応をお願いします。

   • memtable not ready for flush：ログストリームのフリーズプロセス中に、MemTableが長時間ダンプ条件に達していないため、ダンプタイムアウトやメモリ爆発が発生する可能性があります。技術サポートに連絡して、対応をお願いします。

   • memtable no destroy after release：MemTableが解放された後、長時間破棄されていません。主な原因はMemTableのインポートカウントのリークです。技術サポートに連絡して、対応をお願いします。

   • memtable can not create dag successfully：MemTableがダンプ条件に達した後、長時間ダンプタスクを正常に開始できませんでした。技術サポートに連絡して、対応をお願いします。

   • compaction has finished in storage：ストレージ層のコンパクションは終了しましたが、RSの後続処理が完了していません。技術サポートに連絡して、対応をお願いします。

   • there is too many tablets. tablet count xxx：診断時にイテレーションするパーティションが多すぎるため、そのLSの診断がスキップされました。

3. コンパクション診断ビューのエラー情報に基づいて、問題を分類できます。具体的な問題については、関連ドキュメントまたは典型的なケースを参照してトラブルシューティングを行うことができます。

よくあるケース

以下のケースでは、モードを区別しません。

• OceanBaseデータベースV4.3バージョンでクラスタのメジャーコンパクションがスタックし、一部のTabletのコンパクションで-4016例外が発生します。

• テーブル数がハイウォータマークを超えると、配列に新しいSSTableを追加できなくなり、その結果Mini Mergeを実行できない可能性があります。

• locality変更中に、localityをz1,z2からz1,z2,z3に変更し、新しく追加されたz3上のZoneログストリームがリーダーになると、データコンパクション操作がスタックする可能性があります。

• 各Zoneのコンパクションが完了してidle状態になった後も、クラスタのコンパクション状態は依然としてmergingのままです。

関連ドキュメント

• コンパクション情報の表示

• ダンプ情報の表示

• GV$OB_COMPACTION_DIAGNOSE_INFO