[SQL Server] 高可用性ソリューションについて

皆さん、こんにちは。 今回は SQL Server の高可用性ソリューションについて紹介します。

SQL Server では、複数の可用性ソリューションを実現させるための機能が備わっています。 しかしながら、複数の可用性ソリューションが存在するため、どの機���を選択すべきかについて、迷われている方もおられるのではないでしょうか。

今回、SQL Server で実現可能な高可用性ソリューションの各機能をポイント別に評価し、比較してみたいと思います。

まず初めに、評価するポイントとして、以下の項目を定義しました。

高可用性ソリューションの各機能を上記のポイントで評価したものが、以下の表になります。

注1) AlwaysOn 可用性グループでは、プライマリとレプリカ間の同期状態を常に監視しており、既定のタイムアウト値 (SESSION_TIMEOUT もしくは PARTNER_TIMEOUT) の間までに、プライマリとレプリカ間の通信が正常に行えない状態を検知した場合、レプリカを切断するという動作が行われます。 また、プライマリとレプリカ間の通信の正常性を確認している間、レプリカへの同期処理は待ち状態となり、レプリカ側が異常な状態と判断され、レプリカが可用性グループから解除されるまで、プライマリ側で行われた UPDATE/DELETE/INSERT 処理のコミット処理は待ち状態となります。

尚、レプリカが解除された以降では、プライマリ側の UPDATE/DELETE/INSERT 処理のコミット処理は即座に行われ、レプリカへの同期処理で待ちが発生することはありません。また、プライマリとレプリカ間の通信が正常に行えることが検知された場合、自動的にプライマリとレプリカ間の同期が開始されます。

※ 機能は異なりますが、データベース ミラーリングでも類似の動作が行われます。

注2)同期モードの場合、プライマリ側で行われたトランザクション処理のコミットが、レプリカ (もしくは ミラー) への書き込みが完了した後に行われます。 そのため、プライマリとレプリカ (もしくは ミラー）間は、常に同期が保たれた状態になり、障害発生によるデータ損失のリスクを回避することが可能となります。

注3)非同期モードの場合、プライマリとレプリカ (もしくは ミラー) 間のデータ同期が非同期で行われるため、何らかの障害がプライマリ側で発生し、レプリカ (もしくは ミラー) に配信されていないトランザクションがプライマリ側に残っていた場合は、データ損失が発生します。 そのため、レプリカ (もしくは ミラー) をプライマリに昇格されるためには、強制フェールオーバーを実施する必要があります。尚、強制フェールオーバーを実施せず、プライマリ側が正常に動作する状況に復旧された場合、同期モードと同様に、自動的に同期の再開が行われます。

注4)プライマリ クラスタノード上で稼動している SQL Server リソースの停止、SQL Server リソースグループの移動、新プライマリ クラスタ ノード上での SQL Server リソースの起動処理の時間が必要となります。 そのため、通常 数分程度で本処理は完了することが予測されますが、データベースの整合性を保つためにリカバリが必要なトランザクションが多ければ、数分以上の時間を要する可能性があります。

注5) AlwaysOn フェールオーバー クラスタリング インスタンス の場合、各クラスタノード上で、共有ディスク (もしくは SMB) に配置されたデータベース物理ファイルを共有するため、ディスク装置 (ストレージ) 側でも冗長性を持たせる必要があり��す。

注6)リアルタイムによるデータ同期が保証されていない機能であるため、何らかの障害発生時に レプリケーション サブスクライバ、ログ配布先に配信されていないトランザクションが存在する場合、データ損失が発生する可能性があります。尚、レプリケーション プライマリ、ログ配布元の環境が正常に動作できる状態に復旧された場合、同期の再開が行われます。

いかがでしたでしょうか。今回はポイントを絞ったうえでの機能比較を実施しました。

実際にシステム構成を設計される場合、コストなどの様々な要素により、多岐にわたる検討が必要であると思いますが、その一助になれば幸いです。

[参考情報]

高可用性ソリューション (SQL Server)

※ 本Blogの内容は、2014年10月 現在の内容となっております