クラスタ構成の実行系と，リカバリ専用サーバである1台の待機系で稼働します。実行系の複数のアプリケーションサーバのうち一つでも障害が発生すると，クラスタソフトウェアで障害を検出し，待機系であるリカバリ専用サーバに切り替えられます。待機系では，ダウンした実行系のアプリケーションサーバのトランザクションを決着します。

リカバリ処理の流れについて次の図に示します。

図22-13　リカバリ処理の流れ

1. リカバリ専用サーバのクラスタソフトウェアが障害を検知します。
   実行系のアプリケーションサーバCで障害が発生し，ダウンすると，待機系のリカバリ専用サーバのクラスタソフトウェアはアプリケーションサーバCのダウンを検知します。
   
2. リカバリ専用サーバのクラスタソフトウェアで系切り替えを実施します。
   待機系のリカバリ専用サーバに切り替えます。このとき，共用ディスク装置の切り替え，共用ディスク装置のマウント，および仮想ホストのIPアドレスの設定をします。
   
3. リカバリ専用サーバをロックします。
   リカバリ専用サーバでは，順次，リカバリ処理を実施します。このため，リカバリ処理を実施する前に，リカバリ専用サーバをロックします。
   
4. リカバリ専用サーバのクラスタソフトウェアでリカバリコマンドを実行し，リカバリ専用サーバのアプリケーションサーバをリカバリモードで起動します。
5. ダウンしたアプリケーションサーバCで仕掛かり中だったトランザクションのリカバリ処理を，リカバリ専用サーバで実施します。
   リカバリ専用サーバでは，トランザクションのリカバリ処理だけが実施されます。リカバリ処理終了後，リカバリ専用サーバのアプリケーションサーバは終了します。
   
6. リカバリ専用サーバのロックを解除します。
7. リカバリ専用サーバのクラスタソフトウェアでアプリケーションサーバ終了後の処理を実施します。
   共用ディスク装置の切り替え，共用ディスク装置のアンマウント，および仮想ホストのIPアドレスの削除をします。
   

ほかの実行系のアプリケーションサーバに障害が発生している場合は，リカバリ処理をします。なお，実行系のアプリケーションサーバAおよびBについては，アプリケーションサーバCのダウンの影響を受けず，アプリケーション処理を実行します。

注意事項

• 複数の実行系で障害が発生し，アプリケーションサーバがダウンした場合は，リカバリ専用サーバ（待機系）では，排他で順次リカバリ処理をします。
• リカバリ専用サーバでのリカバリ処理中は，リカバリ専用サーバのサービスポートが閉塞されるため，処理の受け付けはされません。
• リカバリ専用サーバでは，リカバリ処理が終了しない場合に備えて，タイムアウト監視が実施されます。
• データベースのダウンによってタイムアウトした場合は，手動でリカバリ処理をしてください。詳細については，マニュアル「Cosminexus　システム運用ガイド」を参照してください。
• リカバリ専用サーバがダウンした場合などの二重障害については，対応していません。