5/11 に透過的なフェールオーバー機能がプレビューとなりました。
これにより、SQL Database のアクティブ Geo レプリケーションにおいて、データベースロールの切り替え後も同じ接続文字列を利用し続けることができるようになりました。どんどん進化するサービスとしての SQL Server の魅力について少しでも皆さんと共有できればと思います。
今回は、本機能の仕組みを簡単に説明しながら実際にどのように機能しているかを画面ショット付きでお伝えしてみます。
イメージ図としてはこんな感じです。
なお、タイトルにもございますように本機能はパブリックプレビュー段階で正式にリリースされた機能ではございません。将来的に全ての挙動が変更となる可能性が有ります事、予めご了承ください。
アプリケーションがデータベースに接続する際には、接続先を識別する必要があります。従来の仕組みでは、データベースの論理サーバー名を基に識別していました。
上記の図で言うと「sv1.database.windows.net」です。大切なことは、この接続先情報を持っているのはアプリケーション側であるということです。ですから、この状態で地理的なフェールオーバーが発生すると・・
データベース側は切り替えに成功しても、アプリケーション側は読み取り専用サーバーに格下げされた「sv1.database.windows.net」に対して引き続き書き込みを行おうとして、エラーで異常終了するという事態が発生していました。もったいない！！
今までの仕組みはどこに考慮点があったのでしょうか？そうです。後々変更される可能性がある文字列をアプリケーション側に渡していたというところなのです。であれば、初めから不変の文字列をアプリケーション側に渡しておけばこの問題は発生しないということになります。それが今回の「透過的な」フェールオーバーの仕組みとなります。
透過的なフェールオーバー機能においては、初めから
の 2 種類を生成しておき、これをアプリケーション側に渡しておくのです。これらの文字列はフェールオーバーしようが変更されません。
そして、これらのアドレス (FQDN) は DNS の機能を用いて皆さんの気づかない内に、本当の論理サーバー名に変換されています。上記の図で言うと、
という形で変換されます。
この状態で地理的なフェールオーバーが発生すると、今まで通りデーターベースサーバーのロールが切り替わった後に、DNS の名前解決レコードが自動的に書き換えられるのです。
つまり、データベースの切り替えに合わせて
という形で変換されるようになります。FQDN 自体は変更されていないので、アプリケーション側は何一つ気づくことなくリージョン間の切り替えが成功するわけです。
なお、読み取り専用 FQDN については現段階では変化しない仕様のようです。これは、フェールオーバーするシナリオを考えれば致し方ない事なのかもしれません。つまり、プライマリ側に問題があったためにフェールオーバーした場合、「読み取り専用 FQDN」が旧プライマリになったとしてもアクセスできない事態が想定できるためです。
それでは、流れで見てみましょう。なお、本手順においては、データベースが作成された後からの流れとさせていただきます。
「データベース」-「geo レプリケーション」と移動し、画面中央のインフォメーションを押下します。
最低限、「セカンダリサーバー」「フェールオーバーグループ名」の 2 箇所を設定して構成します。後者は、DNS のレコードの文字列に利用されますので慎重に！
これで設定は完了です
執筆時点の 7/3 においては、接続文字列の確認画面にすんなりたどりつけなくて少し画面ショットが多くなってしまいました。
「データベース」-「概要」と移動し、画面中央の「サーバー名」を押下します。
「フェールオーバーグループ」と移動し、画面中央の「フェールオーバーグループ」を押下します。
画面中央に表示された「読み取り/書き込みのリスナーエンドポイント」と「読み取り専用のリスナーエンドポイント」の二つが今回の目的の文字列となります。
前項の手順で得られた二つの文字列を NSLOOKUP コマンドにて確認すると、それぞれのレコードの名前解決具合が判ります。
となっている事がわかります。つまり、アプリケーションは、
となります。裏のサーバー名は気にする必要はありません。
では、フェールオーバーをさせてみましょう。先ほど接続文字列を確認した画面に移動してください。「サーバー」を選択して、コンテキストメニューから「フェールオーバー」を選んで完了です。
前項までに得られた文字列を再度 NSLOOKUP コマンドにて確認すると、レコードの名前解決具合に変化があったことがわかります。
となりました。アプリケーションから見た時の文字列は不変ですが、裏で解決される名前が変わったことにより、データベースとしての切り替えは行われています。あくまでプライマリ側だけですが。
システム全体で考えた時にはデータベースの事だけを考えていれば良いというものではありません。ですから、本機能で全てが簡単になったわけではありませんが、データベースの災害対策というのはウェイトとしては非常に大きい事は間違いありません。
どんどん便利になりますね。
次回予告
