データベース緊急対応の概要

広義には、障害が発生した場合だけでなく、クラスタの設計能力や計画を超えるあらゆる状況において緊急対応が必要となる場合があります。緊急事態対応の最優先事項は根本原因の究明ではなく、まずは「出血を止める」こと、つまりクラスタができるだけ早く正常なサービス能力を回復させることです。

問題発見チャネル

緊急事態の発見は、通常、能動的発見と受動的検知の2種類に分類され、一般的に以下のチャネルがあります：

• 業務監視アラート（アプリケーション層監視）

• データベースの日常巡回検査（詳細については、監視とアラート セクションの 監視 を参照してください）

• データベース監視アラート（詳細については、監視とアラート セクションの アラート を参照してください）

緊急事態の分類

ハードウェア＆インフラストラクチャ障害

通常、ソフトウェアまたはハードウェアの問題によって引き起こされます。その多くはOceanBaseが自動的に復旧できますが、一部の場合は緊急対応による能動的介入が必要です。一般的なインフラストラクチャ障害は以下のカテゴリに分類されます：

• サーバーハードウェア障害によるダウン

• サーバーNTP時刻のずれ

• ケージ/データセンターレベルの電力障害

• スタンドアロンNIC障害、またはケージ/データセンターネットワークのジッターなど

• ODPクラスタロードバランシング装置障害

業務アクセス変化による容量不足

マーケティングキャンペーンなどの理由で業務層のアクセス量が急増したり、新しい業務が立ち上げられたりすると、データベースへのアクセスが初期設計容量を超えることがよくあります。この場合、パフォーマンスの低下、応答時間の長延び、接続タイムアウトなど、一連の問題が発生します。OceanBaseにおいて、パフォーマンス容量不足は通常、以下のような状況で表れます：

• SQLクエリによるクラスタリソース使用率の過剰

• クラスタノードのディスクI/O過多

• クラスタノードのNIC負荷過多

• テナントリクエストキューの積み上がり

• テナントメモリ満杯

• ODPスレッド満杯

• クラスタノードログディスク容量満杯

• クラスタノードデータディスク容量満杯

OceanBaseクラスタのその他の問題

上記の2つの大きなカテゴリ以外にも、OceanBaseの分散アーキテクチャ下で、特定のユースケースやユーザー習慣によって引き起こされる問題があります。これらの問題の原因は多岐にわたり、業務のアクセス方法によるものもあれば、稀にソフトウェアバグが原因となる場合もあります。一般的な緊急対応手法を用いて「出血を止める」処理を行うことができます。これらの問題には通常、以下が含まれます：

• テナントダンプの停止

• クラスタフリーズ/マージの停止

• 一時停止トランザクション＆長時間トランザクション

• sysテナントキューの積み上がり

• ノードプロセスの異常終了

• 内部モジュールのメモリ不足/リーク

上記の3つのカテゴリの問題の中には、直接的に「現象」として表れるものもあれば、他の異常現象の原因となるものもあります。これら異なる緊急対応シナリオに対して適切に対処する方法については、分析診断&意思決定プロセスを参照してください。