ロードシェア運用では、クラスタシステム内の各ノードにSymfoware Serverを配置します。このようなシステムでSymfoware Serverの1つがダウンした場合でも、業務への影響を最小限にするために、以下のリカバリ機能を用意しています。
ロードシェア運用でSymfoware Serverの1つがダウンすると、そのRDBシステムで行っていた業務が縮退し、業務全体として支障が出ます。そのため、フェイルオーバ運用のホットスタンバイ機能を併用し、RDBシステムのダウンに備えることができます。フェイルオーバ運用を併用することにより、RDBシステムの1つがダウンしても業務は待機系のシステムに引き継がれ、業務全体への影響は少なくなります。
また、ロードシェア運用には、高速にリカバリを行う、フラッシュトリートメントリカバリの機能があります。フラッシュトリートメントリカバリでは、TCP/IPを使用して運用中にデータベースの更新ログを待機ノードのメモリ上に逐次送信します。切替え事象が発生した場合、逐次送信していた待機ノードのメモリ上の更新ログを用いてリカバリを行うことで、ログの読込みを必要としません。さらに、データベースへの反映を業務と並行してバックグラウンドで行うことで、大幅なダウンリカバリ時間の短縮を実現します。
また、フラッシュトリートメントリカバリは、業務再開タイミングや再開後のアクセス可能データが異なるような2種類の方式が存在します。それらを同期フラッシュトリートメントリカバリと非同期フラッシュトリートメントリカバリと呼びます。以下でその違いを説明します。
同期フラッシュトリートメントリカバリ
運用中に更新ログを待機ノードへ逐次送信します。切替え事象が発生した場合、待機ノードでメモリ上の更新ログを利用して、仕掛りデータのリカバリを共用バッファ上で行います。リカバリ完了後に業務再開を可能にし、その後データベースへの反映作業を業務処理と並行して行います。そのため、迅速な業務再開が可能です。また、再開後には必ず即時に業務続行可能な状態になっています。
非同期フラッシュトリートメントリカバリ
運用中に更新ログを待機ノードへ逐次送信します。切替え事象が発生した場合、仕掛りデータを閉塞(フラッシュトリートメント閉塞と呼びます)します。閉塞完了後に業務再開可能とします。その後、業務と並行して待機ノードでメモリ上の更新ログを利用して、仕掛りデータのリカバリを共用バッファ上で行い、データベースへの反映作業も業務処理と並行して行います。
共用バッファ上のデータのリカバリを業務再開後に業務処理と並行して行うため、同期フラッシュトリートメントリカバリよりもさらに速い業務の再開が可能です。しかし、業務続行に必要なページがフラッシュトリートメント閉塞状態になっていると、すべての閉塞データのリカバリ完了まで実質的な業務再開が遅滞します。
注意
フラッシュトリートメントリカバリ中にクラスタサービス状態を変更した場合、Symfoware Serverは強制停止となります。
OSパニックや何らかのトラブルにより、あるノードがダウンした場合、次のような事象が発生します。
ダウンしたRDBシステムで動作していたアプリケーションが他ノードのRDBシステムのデータベースを更新していた場合、更新したRDBシステムでは、そのトランザクションがインダウト状態となり、更新した資源がインダウト閉塞することがあります。インダウト閉塞すると、閉塞が解除されるまで一時的にアクセスができなくなります。インダウト状態は、コミット処理の延長での2フェーズコミットで、1フェーズが完了した時点でダウンした場合に起こる非常にまれな事象です。
インダウトリカバリは、業務拡張された複数ノードで行われます。
インダウト閉塞は、ダウンしたRDBシステムがダウンリカバリを完了し、ネットワークが活性化した段階でインダウトリカバリが行われ、解除されます。
ノードダウン時のトランザクションおよびデータベースの扱いを、以下に示します。
