スタンバイデータベースを参照することができる
本来の目的は障害がおこってしまった時のために用意している、スタンバイ用データベースであるセカンダリレプリカではありますが、せっかく同じデータがそこにあるのなら、有効に活用したいと考えるのが人情ですね。そのようなユーザのリクエストに応えるかたちで、AlwaysOnの4個のセカンダリレプリカは参照することができるようになっています。データを更新する必要のないアプリケーションは、いづれかのセカンダリレプリカにアクセスすることができるため、ワークロードのバランスをとり易くなります。セカンダリレプリカでは更新系の処理が行われることがないため、他のトランザクションの排他ロックなどにブロックされることがありません。また、データベースのサイズによっては時間がかかってしまうバックアップや整合性の確認 (dbcc checkdbコマンドなど)をセカンダリレプリカで処理させる、といった利用方法も考えられます。
フェールオーバー条件がカスタマイズできる
従来のフェールオーバークラスタリングでは、フェールオーバー発生の条件をほとんどカスタマイズすることができませんでした。また、残念ながらSQL Serverインスタンスの稼働状況の確認方法も、あまり気が利いたものではありませんでした。そのような状況への反省をもとに、AlwaysOnで、フェールオーバーの設定方法が大きく変更されることになりました。SQL Serverインスタンスやデータベースを含むAvailability Groupの重要性をもとに、フェールオーバー発生の条件をポリシーとして6段階にわけて設定することできるようになりました。
さて、2回にわたりSQL Serverの高可用性への取り組みや、AlwaysOnの代表的な機能を紹介しましたが、いかがでしたでしょうか。
AlwaysOn に関しては、主なトピックに限定してとりあげても、とても意欲的な取り組みが行われていることをイメージしていただけたのではないかと思います。このAlwaysOnの実装によって SQL Serverの可用性は、飛躍的に高まることになります。それは、よりシビアな信頼性が求められるミッションクリティカルな環境でSQL Serverが選択される機会を、これまで以上に増やしていくに違いありません。
次回は、再び日本マイクロソフト プレミアフィールドエンジニアリング部の古賀が登場して、Denaliで拡張されたTransact-SQLのさまざまな機能を紹介する予定です。お楽しみに！
