データベースの緊急対応プロセスは、一般的にイベント検知、異常情報収集、分析診断、意思決定処理のいくつかのステップに分かれています。本記事では、一般的なケースを例に挙げ、ユーザーが問題の根本原因を迅速に特定し判断するのをサポートする分析・意思決定手法をいくつか紹介します。
イベント認識
緊急事態の認識は、通常、アプリケーションシステムのアラート、データベースのアラート、ユーザーからの報告フィードバック、日常的な巡回検査などによって行われます。どのような方法で発見された場合でも、イベント／障害対応の第一歩は、障害情報の同期（現在の影響範囲および対応担当者を含む）と異常エラーメッセージの迅速な収集であるべきです。これにより、次の分析および緊急対応の根拠が得られます。
異常情報の収集
一般的に、異常情報は以下の観点から収集・整理する必要があります：
異常発生：通常、最初のレベルは業務関連の情報です。例えば、ユーザーがログインできない、注文が失敗した、指定されたページを開けないなどです。異常情報収集の第一歩は、業務アラートや監視情報からデータベース関連のアラート情報を特定し、特定することです。例えば、アプリケーションのDAL層ログ、ミドルウェア、クライアントなどから報告されるデータベース関連の異常情報などです。
異常発生時間：障害/異常が発生した正確な時点と、持続時間を確認します。
異常の範囲：異常が単一のアプリケーションで発生しているのか、すべてのアプリケーションで発生しているのかを確認します。対応するOBクラスタがグローバルに影響を受けているのか、あるいは特定のクラスタまたはテナントに限定されているのかを確認します。グローバル範囲の影響の場合、通常はインフラストラクチャの異常から調査を開始します。局所的な障害や異常の場合は、具体的なクラスタ、テナント、データベース、obproxyの詳細情報を確認する必要があります。
エラー関連ログ：異常がトリガーされた期間中のエラーログ情報を収集します。これは通常、アプリケーションのDAL層ログおよびクライアントログから取得します。
変更/リリースの有無：障害発生時刻の前後で業務にリリースや変更があったかどうかを確認し、もしそうであれば具体的な情報を収集します。実際のシナリオでは、多くの障害や異常は変更によって引き起こされることが多いです。
関連業務への影響：現在の障害の影響範囲を確認し、影響が継続する場合、上流または下流の他のシステムに影響を及ぼす可能性があるかどうかを判断します。該当する情報を参考に、事前のダウングレードやレート制限が必要かどうかを決定します。この部分はデータベースだけにとどまらず、サイト信頼性エンジニアリング（SRE）の全体的な戦略に関わるため、ここでは詳細な説明は省略します。
分析診断＆意思決定ツリー
前述のとおり、緊急事態の発生源は大きく二つに分類されます。一つはアプリケーションから検出される異常であり、もう一つはデータベース自身の巡回検査やアラートです。後者は一般的に具体的なDBイベントを指し、詳細な緊急対応方法については、本章の後半で詳しく分析します。このセクションでは、業務側のエラーや異常に焦点を当て、段階的な分析と判断を通じて、可能な限り迅速に問題を特定する思考と方法について説明します。
トラブルシューティングの手順
トラブルシューティングのアプローチ
まず、OceanBaseクラスタのヘルスチェックを素早く実行します。
いかなる緊急事態も調査を開始する前に、最も基本的な異常を早期に排除し、無駄な調査を避けることが重要です。OceanBaseの正常な動作に影響を与える主要なソフトウェア・ハードウェア要因は以下の通りです：
NTP時刻が同期されているかどうか
サーバーがダウンしていないかどうか
ログディスクやデータディスクの空き容量が満杯ではないかどうか
データセンターのネットワークにジッターが発生していないかどうか
ロードバランシング機器/コンポーネント（F5/LVSなど）に障害が発生していないかどうか
クラスタの基本的なヘルスチェック項目については、OceanBaseクラウドプラットフォームが迅速なヘルス巡回機能を提供しています。詳細については、《OCPユーザーガイド》を参照してください。
異常発生時の業務トラフィックの急増を確認する
最も基本的な外部異常を排除した後、次に確認すべきは、異常発生時の外部からの業務リクエスト量が平常時に比べて明らかに増加していないかどうか、つまり業務上の通常のトラフィック急増によって引き起こされる各種リソース不足などの異常問題です。
アプリケーション層からデータベース関連のエラーや異常を分析する
前述の2つのケースでは、実際の本番運用において、迅速に確認できる情報はしばしば一部に限られます（例：明確なハードウェアダウン、ネットワーク切断、ディスク満杯、業務トラフィックの増加など）。しかし、実際のシナリオでは多くの要因が最初から迅速に確認できない場合があります（例：I/O/ネットワークのジッター、データ分布の変化、ヒット数の少ない業務ロジックが集中して発生するなど）。このような場合は、さらなる分析が必要です。一般的に、アプリケーション層から露呈するデータベース関連のエラーや異常は、主に以下のカテゴリに分類されます：
アプリケーション接続プールが満杯
アプリケーションリクエストのタイムアウト
アプリケーション接続失敗
アプリケーション書き込み失敗
アプリケーションロックの干渉
以下、いくつかのケースをそれぞれ紹介します。
アプリケーション接続プール満杯 / アプリケーションリクエストタイムアウト
接続プール満杯は、アプリケーション側で最も一般的なデータベース異常の一つです。多くの異常事象が段階的に伝わり、最終的にはアプリケーション側の接続プールが満杯となり、新しい接続を確立できない状態として現れます。接続プール満杯の直接的な原因はアプリケーションリクエストのタイムアウトです。実際の状況から見ると、問題を引き起こす要因は発生頻度の高い順に大まかに以下の通りです：
データベース内に実行計画が異常なスローSQLがあり、応答時間が長くなり、アプリケーション側が接続を繰り返し再試行します。
この場合の解決策は、スローSQLの実行計画に介入するか、直接レート制限をかけることです。詳細な処理フローについては、SQLクエリによる異常を参照してください。
データベース内のSQL応答時間が長い（明らかな異常な実行計画は検出されていない）、またはトランザクションが長時間コミットできない場合。この場合は一般的に以下のような状況に分類されます：
実行中のセッションリクエストを確認し、業務情報と照らし合わせてトランザクションの実行状況を判断します。この場合、よく見られるのはOBserverノードの異常、例えばI/O/メモリ/ネットワークの異常です。この場合、まず疑わしいノードを隔離して回復可能かどうか観察することができます。その後、具体的な異常に対してダウングレード処理を行います。詳細については、その他のハードウェア・ネットワーク関連の問題を参照してください。
ハードウェアに明確な問題は見つからないが、ノードのI/O負荷が非常に高い、またはNIC負荷が高すぎてSQLリクエストがタイムアウトする場合。この場合の処理方法は、ノードNIC負荷が高すぎるおよびノードI/O負荷が高すぎるを参照してください。
SQLクエリ時間が異常になるもう一つのケースは、LSM-Treeアーキテクチャに近いデータベース特有の現象で、OceanBaseでは「bufferテーブル問題」と呼んでいます。詳細については、bufferテーブルを参照してください。
データベースノードのCPU/メモリ容量が不足しており、CPU不足によりテナントキューが蓄積し、メモリ満杯により書き込み失敗が発生する。これによりSQL RTが増加する。
この場合、まずCPU使用率とテナントメモリ使用量を確認し、必要に応じて拡張またはその他の適切な手段で対処することを推奨します。詳細については、テナントリクエストキューの積み上がりおよびテナントメモリが満杯を参照してください。
アプリケーションの接続失敗
アプリケーションの接続失敗は、一般的に2つのケースに分けられます。1つはOBProxyへの接続失敗、もう1つはObserverへの接続失敗です。直接の接続失敗よりも、接続タイムアウトの方が一般的です。
OBProxyへの接続失敗
アプリケーションからOBProxyへの接続失敗が発生した場合、まずアプリケーションとOBProxy間のネットワーク経路の問題を除外する必要があります。次に、OBProxyの上位層にロードバランシングデバイスやコンポーネントが設定されており、障害が発生していないかを調査します。これら2つのケースを除外した後、OBProxy自体の障害やトラフィックの増加によりOBProxyスレッドが満杯になった可能性があります（エラーメッセージは
too many sessionsなどと類似します）。この場合の対処方法については、ODP側の障害およびODPスレッド満杯を参照してください。Observerへの接続失敗
Observerへの接続失敗については、まず迅速に除外すべきものはネットワーク障害、すなわちOBProxyからObserverへの経路です。インフラが安定している環境では、ネットワーク回線の問題が発生する確率は実際には低いです。明確な指標がネットワーク問題を示していない限り、分析に多くの時間を費やす必要はありません。より一般的なのは、Observer自体の接続に問題が発生している場合です。この場合、以下のいくつかの経路で分析・特定できます：
sysテナントまたはその他の内部テナントにキューの蓄積がないか確認します。observerログを確認し、SYSキューに積み上がりがないか判断します。OceanBaseクラスタは接続作成を最初にsysテナントで処理するため、問題が発生すると接続失敗につながります。対処方法については、SYSテナント/RSサービスの問題を参照してください。
ノードのCPU/IOが異常に高くないか確認します。observerログを確認し、ユーザーテナントのキューに蓄積がないか判断します。ユーザーテナントのリソース不足も接続タイムアウトを引き起こす可能性があります。対処方法については、テナントリクエストキューの積み上がりを参照してください。
異常なSQLによるリソース占有問題については、調査の考え方の詳細はSQLクエリによる異常を参照してください。
アプリケーションの書き込み失敗
OceanBaseの書き込み関連の問題はいくつかの大きなカテゴリに分けられ、そのほとんどがメモリと直接関係しています。実際の本番環境では、発生頻度の高い順に以下の観点から分析・診断できます：
短時間における一括書き込み操作（例：一括インポート、訂正、削除操作）により、ユーザーテナントのメモリが満杯になる。
これが最も一般的なケースです。エラーメッセージは通常
Over tenant memory limitsとして現れます。OceanBaseはLSM-Tree構造をベースとした準メモリデータベースであり、あらゆる書き込み操作はメモリリソースを消費します。一定のしきい値に達すると、メモリはダンプ/マージが完了するまで解放されません。そのため、ダンプの速度がメモリの消費速度に追いつかない場合、最終的にメモリが枯渇し、アプリケーションの書き込みがゼロに落ち込むことがあります。このケースでの対処方法については、テナントメモリが満杯になった場合を参照してください。長時間トランザクションやハングトランザクションによりダンプが停止し、メモリが解放されずに満杯になる。
同じくメモリが満杯になるケースとして、コミットされていないトランザクションが存在するため、アクティブなメモリが凍結・ダンプできなくなることで、結果としてメモリが爆発的に増加する場合があります。長時間終了していないステートメントを確認するか、コマンドラインSQLを使用して実行中の長時間トランザクションを特定します。
テナント内部の他のモジュールがメモリを過剰に占有し、MemStoreが割り当てられず、結果としてメモリ満杯のエラーが発生する。
この場合は、書き込み量が多すぎるためにMemStoreのメモリが満杯になるのではなく、他のSQL問題が引き起こしたテナントの非MemStoreモジュールのメモリ問題です。この時の現象は、テナントのMemStoreメモリ使用率がそれほど高くないにもかかわらず、書き込み時にエラーが発生することです。システムメモリ不足/リークを参照してください。
clogログディスクが満杯になり、paxosの多数派が同期できず、パーティションが主を持たず、業務が書き込みできない。
clogはOceanBaseのトランザクションログであり、同様にWALメカニズムを採用しています。ディスクが満杯になると、書き込みのコミットが失敗となります。対処方法については、ノードログディスク容量が満杯になった場合を参照してください。
システムRSモジュールに異常が発生し、マージのフリーズが停止し、その間書き込みができない。
このシナリオは一般的ではありません。OceanBaseは、書き込みによるダンプが一定のしきい値に達した後、または日次マージの前に、まず大規模バージョンのフリーズ操作を実行します。つまり、アクティブなメモリをフリーズした上で、ダンプ/マージを行います。通常、フリーズ操作は1秒以内に完了しますが、異常な場合はそれ以上かかることがあります。この時、ユーザーは書き込みできません。このシナリオでの緊急対応策は、RSを手動で切り替えるか再起動することです。SYSテナント/RSサービスの問題を参照してください。
アプリケーションロックの干渉
特定の行に対して同時実行的に更新を行うシナリオでは、行ロックの競合が発生しやすく、各リクエストの待機時間が長くなることがあります。さらに、アプリケーションの接続プールが満杯になる問題にも波及する可能性があります。ロック競合の原因は一般的に以下のような場合があります：
業務側のSQL RTが向上し、行ロックが解放されず、ロック競合がRTの向上によって引き起こされる結果となります。この場合は、RTの向上問題を解決する必要があります。詳細については、前述の章 アプリケーション接続プール満杯/アプリケーションリクエストタイムアウト を参照してください。
行にコミットされていないトランザクション、またはハングトランザクションが存在する。
ホットスポット行の同時実行処理によるロック競合が発生し、逆にRTが向上する。
ホットスポット行の更新はリレーショナルデータベースに共通する問題であり、この種の問題に対しては緊急時に有効な対処法がないことが多いです（業務形態によるもので、一般的にはレート制限や降格処理を検討します）。長期的な最適化の観点からは、トランザクションロジックの最適化調整（例：select for update wait 1 の方法）を検討できます。OceanBaseはホットスポットの同時実行処理に関して積極的に取り組んでおり、既に効果的な最適化ソリューションを導入しています。詳細については、OceanBaseデータベースの 事前行ロック解除 機能を参照してください。これにより、単一行の同時実行のパフォーマンスが向上します。
変更の実施・ロールバックと注意点
前章の分析による特定を経て、皆さんは一般的な緊急事態への対処について一定の理解を深めたことでしょう。残りは対応する緊急措置を講じ、データベースの正常な稼働を回復させることです。OceanBaseの緊急対応にあたっては、以下の点に特に注意してください：
発行された各緊急変更操作を明確に記録し、復旧失敗時のさらなる詳細な診断の参照情報として確認します。
できるだけバックアップ情報を記録することを推奨します。これには、異常期間中のobserverログやコアファイルなどが含まれます。
本章で議論されている緊急復旧操作は、原則としてクラスタデータの多数派を破壊せず、データの一貫性を保証することを前提としています。複数レプリカの障害で単一レプリカをアクティブ化する必要がある場合や、複数レプリカのCLOGを処理する必要がある場合は、OceanBaseテクニカルサポートにお問い合わせください。
緊急措置の実行が完了し、業務が止まることなく回復した後は、一部のパラメータ設定の変更をロールバックし、問題/障害について振り返ることを推奨します。緊急時に保持された現場情報に基づき、問題の根本原因究明の作業を開始することができます。