CodeZine(コードジン)

特集ページ一覧

柔軟で確実な高可用性を実現するSQL Server 2012の「AlwaysOn」機能

進化したSQL Server 2012の新機能紹介(2)

  • LINEで送る
  • このエントリーをはてなブックマークに追加

目次

AlwaysOn可用性グループとミラーリングの比較

 AlwaysOn可用性グループは、データベースを別のSQL Serverインスタンスに複製する機能です。データベースを随時(もしくはリアルタイムに)複製するため、障害が発生した場合は、速やかに複製していたデータベースに切り替えることで、少ないダウンタイムでサービスを継続で提供できます。

 AlwaysOn可用性グループでは、ミラーリング機能と比較して次の3つが変わりました。

(1)複数のデータベースをまとめて管理できるように

 ミラーリングでは、データベースごとの管理でした。AlwaysOnでは、複数のデータベースを一まとめに管理できるようになりました。フェールオーバー時に、複数データベースをまとめてフェールオーバーできます。

(2)最大4か所にデータベースを複製できるように

 ミラーリングでは、複製先は1か所だけでした。AlwasysOnでは、最大4か所にデータベースを複製できるようになりました。

(3)複製したデータベースを活用しやすく

 ミラーリングでは、複製先のデータベースを使用するには、スナップショット作成し、スナップショットを参照する必要がありました。AlwaysOnでは、複製したデータベースをアクティブセカンダリとセカンダリバックアップで活用しやすくなりました。

複数のデータベースをまとめて管理する可用性グループ

 SQL Serverは、インスタンスに複数のデータベースを作成できます。そのため、アプリケーションは複数のデータベースにデータを分割する設計をすることが多くなります。例えば、人事データベースと営業データベース、給与データベースとデータを分け、アプリケーションから複数のデータベースを参照します。そのため、システムを継続提供するには、関連するデータベースがすべて使用できる必要があります。

 ミラーリングでは、データベースを1:1でマッピングするため、複数のデータベースをまとめてフェールオーバーすることはできませんでした。AlwaysOn可用性グループでは、フェイルオーバーするときには可用性グループ内のデータベースをまとめてフェイルオーバーし、サービスを継続提供できます(図1)。

図1 可用性グループの概念
図1 可用性グループの概念

 可用性グループは、Windowsフェールオーバー上の異なるノードにレプリカを配置します。可用性グループは、Windowsフェイルオーバーメカニズムを元にヘルスチェックや障害通知を提供します。可用性グループの単位で、データベースを別の可用性レプリカのSQL Serverインスタンスに複製しホストします。それぞれの可用性レプリカ上にデータベースが独立して存在するため、SQL Serverフェールオーバークラスタインスタンスのように共有ストレージは必要ありません。

最大4か所にデータベースを複製できる

 プライマリ可用性レプリカと、プライマリ可用性レプリカの複製であるセカンダリ可用性レプリカ、接続先を管理する可用性グループリスナーの3つでAlwaysOn可用性グループが構成されます。

 ミラーリング機能では複製先のインスタンスは1つだけでしたが、AlwaysOn可用性グループでは複製先として最大4つまでセカンダリ可用性レプリカを指定できます(図2)。

図2 ミラーリングとAlwaysOn可用性グループ
図2 ミラーリングとAlwaysOn可用性グループ

アクティブセカンダリ

 セカンダリレプリカで使用している本番サーバと同じ性能のマシンを待機のためだけに置いておくのではなく、ITリソースを有効活用したいものです。

 例えば、本番サーバでバックアップをしたり、レポート分析をすると本番サーバの性能に悪影響を及ぼすので、本番サーバから切り離されたセカンダリレプリカの環境で実施することで活用できる可能性があります。ミラーリング機能では、複製先のデータベースは待機状態で保持され、そのままでは使用できませんでした(注2)。

注2

 ミラーサーバー(AlwaysOn可用性グループのセカンダリ)のデータベースを読み取りで使う場合はスナップショットを取得する必要があり、データベースをそのまま使用することはできませんでした。

 SQL Server 2012では、AlwaysOn可用性グループで、セカンダリレプリカをアクティブセカンダリとして、参照専用接続として使用できます。

 セカンダリレプリカの接続モードは、「接続を禁止」「読み取りを目的とした接続のみを許可」「すべての接続を許可」の3種類から選択することができます。

 「接続を禁止」に設定した場合、セカンダリレプリカに接続しようとするとエラーが発生し接続できません。

 「読み取りを目的とした接続のみを許可」に設定した場合は、接続する際に読み取り専用を宣言して接続すると参照することができます。読み取り専用を宣言するには、接続文字列で「ApplicationIntent」を設定します。また、SQL Server 2012用のSQL Server Native Clientの設定画面で読み取り専用に設定します(図3)。

図3 SQL Server Native Clientの設定画面
図3 SQL Server Native Clientの設定画面

 「すべての接続を許可」に設定した場合は、読み取り専用の宣言有無にかかわらず接続することができます。

セカンダリバックアップ

 可用性グループに参加しているデータベースのバックアップは、どのレプリカでもバックアップすることができます。プライマリレプリカでフルバックアップをし、セカンダリレプリカ上でのログバックアップを実施することもできます。使用しているデータ同期モードに関係なく実施することができます。

 どのレプリカ上でログバックアップを実施したとしても1つのログチェインを形成します。図4のように、セカンダリレプリカ1でトランザクションログを取得した後、セカンダリレプリカ4でトランザクションログバックアップを取得する場合、セカンダリレプリカ1で取得した続きからトランザクションログを取得します。

図4 ミラーリングとAlwaysOn可用性グループ
図4 ミラーリングとAlwaysOn可用性グループ

 つまりトランザクションログバックアップは、同一レプリカに固定して実施する必要はありません。どのレプリカでバックアップしても構いませんが、トランザクションログバックアップの格納は、1か所に固定し格納することを推奨します。リストア時には、すべてのトランザクションログを適用する必要があります。もしレプリカのローカル上に取得していて、そのレプリカが稼働しなくなると、深刻な影響が出るからです。

 SQL Server 2012のデータベース リカバリアドバイザーウィザードを使用すると、リストア時に多くのメリットがあります。例えば、異なるレプリカ上にあるバックアップファイルをログシーケンスナンバーに基づいて一覧表示します。図5では、2008R2-SQL12-02サーバー、2008R2-SQL12-03サーバーに分散しているトランザクションログが一覧表示されています。

図5 複数サーバに配置されているトランザクションログを認識
図5 複数サーバに配置されているトランザクションログを認識

  • LINEで送る
  • このエントリーをはてなブックマークに追加

バックナンバー

連載:進化したSQL Server 2012の新機能紹介

著者プロフィール

  • WINGSプロジェクト 大和屋 貴仁(ヤマトヤ タカヒト )

    <WINGSプロジェクトについて> 有限会社 WINGSプロジェクトが運営する、テクニカル執筆コミュニティ(代表 山田祥寛)。主にWeb開発分野の書籍/記事執筆、翻訳、講演等を幅広く手がける。2018年11月時点での登録メンバは55名で、現在も執筆メンバを募集中。興味のある方は、どしどし応募頂...

  • 山田 祥寛(ヤマダ ヨシヒロ)

    静岡県榛原町生まれ。一橋大学経済学部卒業後、NECにてシステム企画業務に携わるが、2003年4月に念願かなってフリーライターに転身。Microsoft MVP for ASP/ASP.NET。執筆コミュニティ「WINGSプロジェクト」代表。 主な著書に「入門シリーズ(サーバサイドAjax/XM...

あなたにオススメ

All contents copyright © 2005-2021 Shoeisha Co., Ltd. All rights reserved. ver.1.5