Sun Cluster 2.2 のシステム管理

HA-DBMS の障害検証

Sun Cluster HA for Oracle、Sun Cluster HA for Sybase、Sun Cluster HA for Informix の各障害検証は、データベースサーバーを同じように監視します。HA-DBMS の障害検証を構成するには、ユーティリティ haoracle(1M)hasybase(1M)hainformix(1M) の 1 つを実行します (これらのユーティリティのオプションの詳細はマニュアルページを参照)。

ユーティリティの構成とアクティブ化が終わると、クライアントアクセスをシミュレートして、ローカルノードで 2 つのプロセスが開始され、遠隔ノードで 2 つのプロセスが開始されます。遠隔の障害検証は、ha_dbms_serv デーモンによって初期化され、hareg -y detaservicename が初期化される際に起動されます。

HA-DBMS モジュールは、2 つの方法を使用して DBMS サービスが使用できるかどうかを監視します。HA-DBMS は、まず DBMS 自体から統計情報を抽出します。

クライアントの作業が行われていることを統計情報が示す場合、DBMS の検証はそれ以上必要ありません。作業が行われていないことを DBMS 統計が示す場合、HA-DBMS は DBMS に対して小さなテストトランザクションを発行します。この場合、偶然にすべてのクライアントがアイドル状態であると、DBMS 統計は作業がまったく発生していないことを示します。つまり、テストトランザクションはハングしたデータベース状態と通常のアイドル状態を区別します。テストトランザクションは、アクティビティが存在しないことを統計情報が示す場合にだけ実行されるため、アクティブなデータベースにオーバーヘッドを強要することはありません。このトランザクションでは次の作業が行われます。

HA-DBMS は、テイクオーバーを引き起こすコードと引き起こさないコードが示されたテーブルを使用して、DBMS が返すエラーコードを慎重に調べます。たとえば、Sun Cluster HA for Oracle では、table space full というケースはテイクオーバーを発生させません。これは、この状況を修復するには管理者が介入する必要があるためです (テイクオーバーが発生すると新しいマスターサーバーは同じ table space full 状態になります)。

一方、 could not allocate Unix semaphore のようなエラーリターンコードでは、Sun Cluster HA for Oracle はこのサーバーマシンで ORACLE をローカルに再起動しようとします。ローカル再起動が発生したばかりの場合は、代わってほかのマシンが (それ自体の妥当性検査にパスした後で) テイクオーバーします。