マージ異常はテスト環境でよく見られる問題の一つです。マージ異常は、クエリの遅延、ディスク容量の異常な使用、DDLの無効化、Checksumエラーなどの問題を引き起こす可能性があります。
皆さんが迅速に問題の根本原因を特定し、効率的に解決できるように、本記事では明確で実用的なマージ異常のトラブルシューティングプロセスをまとめました。このプロセスは明確な操作手順を提供し、問題処理の効率を向上させ、業務への影響を可能な限り軽減することを目的としており、日常の運用保守作業を強力にサポートします。
マージ異常のトラブルシューティングプロセスは以下の図のとおりです。
プロセスの概要
システムテーブルおよびRS層でのマージの発生状況を確認します。
テナントのマージ状態を確認します。システムテナント内で、
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がNULLでない場合、さらに調査する必要があります。IS_ERRORの値がCHECKSUM_ERRORの場合、そのテナントでChecksum検証の不整合が発生していることを意味します。
現在のテナントのすべてのtabletのマージ進捗状況を照会し、指定バージョンにマージされていないレコードをフィルタリングします。
マージ終了の判定ロジックは、そのテナントのすべてのTablet(要件に合致しない一部のTabletを除外)が指定バージョン番号にマージされているかどうかを確認することです。いずれか一つのTabletが指定バージョンにマージされていない場合、そのテナントのマージは終了しません。次に、そのテナント内で指定バージョンにマージされていない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がマージを完了していないことを意味し、さらに調査する必要があります。
メジャーコンパクションが完了していない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数が減少しない場合は、メジャーコンパクション診断ビューをクエリして、問題をさらに特定します。
メジャーコンパクション診断ビューをクエリし、診断情報を取得します。
メジャーコンパクション診断ビューには、メジャーコンパクションプロセス中のさまざまな異常エラー情報が含まれており、トラブルシューティングに役立ちます。
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\Gdiagnose_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:メジャーコンパクション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が解放された後、長時間Destroyされていません。主な原因はMemTableの参照カウントリークです。テクニカルサポートに連絡してください。memtable can not create dag successfully:MemTableがダンプ条件に達した後、長時間ダンプタスクを正常に開始できません。テクニカルサポートに連絡してください。compaction has finished in storage:ストレージ層のメジャーコンパクションは終了しましたが、RSの後続処理が完了していません。テクニカルサポートに連絡してください。there is too many tablets. tablet count xxx:診断時に走査するパーティションが多すぎるため、そのLSの診断をスキップしました。
メジャーコンパクション診断ビューのエラーメッセージに基づいて問題を分類できます。具体的な問題については、関連ドキュメントや典型的なケースを参照して調査してください。
典型的なケース
以下のケースでは、モードの区別はありません。
OceanBaseデータベースV4.3バージョンで、クラスタのメジャーコンパクションが停止し、一部のTabletのコンパクションで
-4016例外が発生した場合。具体的な調査操作については、OceanBaseデータベースV4.3バージョンでクラスタのメジャーコンパクション中にtablet haven't kept medium snapshot(ret=-4016が発生した原因と対処方法を参照してください。Tableの数がハイウォータマークを超えると、新しいSSTableを配列に追加できなくなり、その結果、Mini Mergeが実行できない可能性があります。このような状況に遭遇した場合は、SSTableの数が多すぎる問題の調査を参照してください。
localityの変更プロセス中に、localityを
z1,z2からz1,z2,z3に変更し、新しく追加されたz3上のZoneログストリームがLeaderになった場合、データコンパクション操作が停止する可能性があります。具体的な調査操作については、locality変更が停止し、それによってコンパクションが停止した場合の調査方法を参照してください。各Zoneのコンパクションが完了してidle状態になった後も、クラスタのコンパクション状態が
mergingのままの場合。具体的な調査操作については、各Zoneのコンパクションが完了してidle状態になった後も、クラスタのコンパクション状態がmergingのままの場合を参照してください。クラスタのメジャーコンパクションが停止し、コンパクション中に帯域幅がフルに使われている場合、詳細な調査操作については、クラスタのメジャーコンパクションが停止し、コンパクション中に帯域幅がフルに使われている原因と対処方法を参照してください。
OceanBaseデータベースV4.xバージョンで、メジャーコンパクションが停止する問題を調査する方法については、メジャーコンパクションが停止する問題を調査する方法を参照してください。
OceanBaseデータベースV4.xバージョンで、RS側のメジャーコンパクションが停止する問題を調査する方法については、V4.xバージョンRS側メジャーコンパクション停止調査マニュアルを参照してください。