SQL Server パフォーマンスチューニング、コンサルティング、アドバイス、相談、定期診断、トレーニング

ホーム＞技術情報＞ SQL Server 2012 自習書 DWH 関連の新機能

SQL Server 2012 自習書シリーズ（HTML 版）
新機能編 No.2「AlwaysOn による可用性の向上」

松本美穂と松本崇博が執筆した SQL Server 2012 自習書シリーズの「新機能編 No.2 AlwaysOn による可用性の向上」の HTML 版です。日本マイクロソフトさんの Web サイトで Word または PDF 形式でダウンロードできますが、今回、HTML 版として公開する許可をいただきましたので、ここに掲載いたします。[2014年12月26日]

目次へ | 前のページへ | 次のページへ

2.9　障害のシミュレーション1：自動フェールオーバーの場合

◆ 障害のシミュレーション1：自動フェールオーバーの場合

ここでは、プライマリ（SERVER1）に障害が発生した場合の動作を確認してみましょう。プライマリに障害が発生した場合は、次のように自動フェールオーバーが行われて、セカンダリ（SERVER2）がプライマリへ自動的に切り替わってくれます。

◆ Let's Try

それでは、これを試してみましょう。

1．まずは、プライマリ側（SERVER1）へ接続して、データを 1件追加しておきます。

-- プライマリ側でデータの追加
USE AGTestDB
INSERT INTO t1 VALUES(6)
SELECT * FROM t1

00128

2．続いて、SHUTDOWN ステートメントを次のように実行して、プライマリを強制停止します。

-- プライマリを強制停止
SHUTDOWN WITH NOWAIT

00129

サービスが停止されると、自動フェールオーバーが内部実行されます（自動フェールオーバーにかかる時間は 10秒程度です）。

◆ 自動フェールオーバーの確認

1．次に、自動フェールオーバーが実行されたことを確認するために、オブジェクトエクスプローラーで元セカンダリ側（SERVER2）を最新の情報に更新して、可用性グループの状態を確認します。

00130

SERVER2 がプライマリへ変更されていることから、自動フェールオーバーが正常に完了したことを確認できます。また、元プライマリ（SERVER1）は、［接続状態］が「接続解除」、［同期状態］が「同期されていません」と表示されていることも確認できます（障害が発生して接続できていない場合には、このように表示されます）。

2．次に、SERVER2（現在のプライマリ）へ接続して、「t1」テーブルの中身を確認します。

USE AGTestDB
SELECT * FROM t1

00131

元のプライマリ（SERVER1）側で追加したデータ「6」が反映されていることを確認できます。

3．次に、Visual Studio 2010 で作成した Windows アプリケーションを実行して、正しく結果が取得できることを確認します。

00132

アプリケーションは、リスナー（AG1_Listener）で接続しているので、フェールオーバー後でも、どちらのサーバーが処理しているかを意識することなく、何の問題もなくアプリケーションを実行できることを確認できます。

このように、可用性グループでは、プライマリに障害が発生した場合には、自動的にフェールオーバーが実行されるので、ダウンタイム（停止時間）はわずか10秒程度です（フェールオーバーにかかる時間は、実行されているトランザクション量によっても変化します）。

◆ 元プライマリの起動

次に、元プライマリ（SERVER1）のサービスを開始した場合の動作を確認してみましょう。元プライマリを起動すると、次のようにセカンダリとして動作するようになります。

それでは、これを試してみましょう。

1．オブジェクトエクスプローラーで、元プライマリ（SERVER1）を右クリックして［開始］をクリックします。

00134

「サービスを開始しますか」と尋ねられるので、［はい］をクリックして、サービスを開始します。

2．サービスが開始されたら、オブジェクトエクスプローラーを最新の情報に更新して、可用性グループの状態を確認してみましょう。

00135

元プライマリがセカンダリとして、復帰していることを確認できます。

Note：可用性グループでの障害検知（FailureConditionLevel）
データベースミラーリングでは、DBM PING と呼ばれる通信パケットを利用して障害検知が行われていますが、可用性グループでは、WSFC（Windows Server フェールオーバークラスター）のリソース機能を利用して障害検知が行われています。可用性グループを作成すると、可用性グループ名と同じ名前のリソースが次のように作成されています（フェールオーバークラスターマネージャーツールから確認できます）。
00136

このリソースの［プロパティ］タブを開くと、次のように「FailureConditionLevel」というプロパティがあり、この値を変更することで、どのような障害を SQL Server の障害と見なすのかを 5段階で設定することが可能です。
00137

既定値は「3」に設定されて、この場合は SQL Server の致命的な内部エラー（重大な書き込み違反など）が発生した場合に障害と見なすようになっています。
FailureConditionLevel の詳細については、オンラインブックの以下の場所が参考になります。
可用性グループの自動フェールオーバーのための柔軟なフェールオーバーポリシー
http://msdn.microsoft.com/ja-jp/library/hh710061.aspx
FailureConditionLevel は、次のように ALTER AVAILABILITY GROUP ステートメントを利用して変更することもできます。

ALTER AVAILABILITY GROUP 可用性グループ名
SET (FAILURE_CONDITION_LEVEL = 3)

目次へ | 前のページへ | 次のページへ