広義には、障害が発生した場合だけでなく、クラスタの設計能力や計画予想を超えるすべての状況において緊急対応が必要となる可能性があります。緊急事態の処理における最優先事項は根本原因の特定ではなく、まずは迅速に事態を収束させ、クラスタができるだけ早く正常なサービス能力を取り戻すことです。
問題発見チャネル
緊急事態の発見は、通常、能動的発見と受動的検知の二つに分類され、一般的に以下のチャネルがあります：
ビジネスモニタリングアラート（アプリケーション層モニタリング）
データベースの日常巡回検査（詳細については、モニタリングとアラートセクションのモニタリングを参照してください）
データベースモニタリングアラート（詳細については、モニタリングとアラートセクションのアラートを参照してください）
緊急事態の分類
ハードウェア＆インフラストラクチャ障害
通常、ソフトウェアおよびハードウェアの問題によって引き起こされます。その多くはOceanBaseが自動的に復旧できますが、一部の場合は緊急手段による積極的な介入が必要です。一般的なインフラストラクチャ障害には以下のものが含まれます：
サーバーハードウェア障害によるダウン
サーバーNTP時計のずれ
ケージ／データセンター級の電力障害
スタンドアロンNIC障害、またはケージ／データセンターのネットワークジッターなど
ODPクラスタロードバランシングデバイス障害
ビジネスアクセス変化による容量不足
マーケティング活動などの理由でビジネス層のアクセス量が急増したり、新しいビジネスがリリースされたりすると、データベースへのアクセスが初期設計容量を超える可能性があります。この場合、パフォーマンスの低下、レスポンス時間の延長、接続タイムアウトなどの一連の問題が発生します。OceanBaseにおいて、パフォーマンス容量不足は通常、以下のような状況で表れます：
SQLクエリによるクラスタリソース利用率の過剰
クラスタノードのディスクI/Oの過剰
クラスタノードのNIC負荷の過剰
テナントリクエストキューの滞留
テナントメモリの書き込み上限
ODPスレッドの上限
クラスタノードログディスク容量の上限
クラスタノードデータディスク容量の上限
OceanBaseクラスタのその他の問題
上記の二つの大きなカテゴリーに加えて、OceanBaseの分散アーキテクチャ下で特有のユースシナリオやユーザー習慣によって引き起こされる問題もあります。これらの問題の原因は多岐にわたり、ビジネスのアクセス方法によるものもあれば、ごく一部の場合はソフトウェアバグが原因となることもあります。一般的な緊急対応手段を用いて事態を収束させることができます。これらの問題には通常、以下のものが含まれます：
テナントダンプの停止
クラスタのフリーズ／コンパクションの停止
持続トランザクション＆長時間トランザクション
sysテナントキューの滞留
ノードプロセスの異常終了
内部モジュールのメモリ不足／リーク
上記の三つのカテゴリーの問題には、直接「現象」として現れるものもあれば、他の異常現象の原因となるものもあります。これらの異なる緊急シナリオに対して正しく対処する方法については、分析診断＆意思決定プロセスを参照してください。