前編では外部からAlwaysOn構成のDBに接続することができました。
ここでは、実際にサーバをダウンさせて、動作のテストを行ってみたいと思います。

##全体構成

その１：前提知識の整理と基礎環境構築編
その２：WSFC(Window Server Failover Clustering)構築編
その３：AlwaysOn構築編
その４：接続確認編
その５：テストしてみる
その６：その他（可用性グループへのDB追加など）

##本編での主な内容

フェールオーバーさせてみる
復旧？させてみる

##フェールオーバーさせてみる

では、実際に現在プライマリとして稼働しているSQL1をダウンさせて動作を確認してみます。
現在、SQL1がプライマリになっていることをいちおう確認します。

アクセスしてデータも確認しておきます。今は3件です。

では、実際にダウンさせてみましょう。Windows Updateが溜まっていたので「更新してシャットダウン」してみました。実運用でも、パッチを当てるという作業はあるかと思います。

SQL1が更新処理をしているときに、再度データをを参照してみます。データが参照できます。
フェールオーバーしているようです。

では、SQL1はダウン中なので、SQL2のManagement Studioで状態を確認してみます。
SQL1がダウン状態で、SQL2がプライマリになっていることが確認できます。

では、この状態で、SQL2に対して更新処理を行っておきましょう。1件データを追加しておきます。

なぜかオートインクリメントがいきなり1000とかにカウントアップされていまね。フェールオーバーがかかるとオートインクリメントは一気に1000位が上がるようです。仕様でしょうか。仕様だとしたら実装では注意が必要ですね。

SQL1を起動させてみます。セカンダリとして起動し、かつ、SQL2で更新したデータが取得できています。

自動フェールオーバーでは、本当に何もしなくても、簡単に冗長化することができることが分かりました。
Windows Azure等では、Azure自体のメンテナンスのために、VMがリスタートされることがあるので、そういうシーンでは自動フェールオーバーは有用かもしれません。

##復旧？させてみる

正直、AlwaysOnでは、可用性グループのどれかが動いていればOKなので、例えばSQL1が復活したからといって、無理にプライマリをSQL1に戻したりする必要は無いかなと思いますし、どれがプライマリになっているかを意識しない運用の方がいいと思います。が、なんらかの理由でSQL1をプライマリに戻したい場合は、単純に、SQL2をダウンさせるのが一番手っ取り早いです。

##余談

フェールオーバーさせると、オートインクリメントが1000カウントアップするようです。再度、SQL1をプライマリに戻すと、桁が2000番台になりました。そのご後は、1つずつカウントアップするようです。
軽く調べた範囲では、AlwaysOnはあまり関係なく、ある条件下でSQLが再起動すると、このような現象が起こるようです。。。

カウントアップの件は、引き続き調査をしてみますが、ひとまずフェールオーバー自体はうまく動きました。
その他、網羅できなかった点をその6で書いてみたいと思います。