AlwaysOn 可用性グループの概要 (SQL Server)

このトピックでは、SQL Server 2014 で 1 つ以上の可用性グループを構成および管理するための中心的なAlways On可用性グループの概念について説明します。 可用性グループによって提供される利点の概要とAlways On可用性グループの用語の概要については、「AlwaysOn 可用性グループ (SQL Server)」を参照してください。

可用性グループ は、 可用性データベースとして知られる、ひとまとまりでフェールオーバーされる個別のユーザー データベースのセットのためのフェールオーバー環境をサポートします。 可用性グループは、プライマリ データベースのセットをサポートし、1 ～ 8 セットの対応するセカンダリ データベースをサポートします。 セカンダリ データベースは、バックアップではありません。 継続してデータベースおよびそのトランザクション ログを定期的にバックアップします。

可用性データベースの各セットは、 可用性レプリカによりホストされます。 可用性レプリカには、2 つの種類があります。1 つは、単一の プライマリ レプリカで、 プライマリ データベースをホストします。もう 1 種類は、1 ～ 8 つの セカンダリ レプリカで、それぞれがセカンダリ データベースのセットをホストし、可用性グループの潜在的なフェールオーバー ターゲットとして機能します。 可用性グループは、可用性レプリカのレベルでフェールオーバーします。 可用性レプリカでは、データセット レベル (1 つの可用性グループのデータベースのセット) でのみ冗長性が提供されます。 データベースの問題 (たとえば、データ ファイルの損失やトランザクション ログの破損による障害が疑われる場合など) が発生してもフェールオーバーは行われません。

プライマリ レプリカは、クライアントからプライマリ データベースへの読み取り/書き込み接続を可能にします。 さらに、データベース レベルで発生する データの同期と呼ばれるプロセスを介して、 プライマリ レプリカは、各プライマリ データベースのトランザクション ログ レコードをすべてのセカンダリ データベースに送信します。 すべてのセカンダリ レプリカは、トランザクション ログ レコードをキャッシュし (ログの書き込み )、それを対応するセカンダリ データベースに適用します。 データの同期は、プライマリ データベースと接続されているそれぞれのセカンダリ データベースとの間で、他のデータベースとは無関係に発生します。 したがって、セカンダリ データベースの中断や障害が発生した場合でも他のセカンダリ データベースはその影響を受けません。また、プライマリ データベースの中断や障害が発生した場合でも他のプライマリ データベースはその影響を受けません。

必要に応じて、1 つ以上のセカンダリ レプリカでセカンダリ データベースへの読み取り専用アクセスをサポートするように構成できます。また、任意のセカンダリ レプリカでセカンダリ データベースのバックアップを許容するように構成できます。

可用性グループAlways On展開するには、Windows Server フェールオーバー クラスタリング (WSFC) クラスターが必要です。 指定された可用性グループの各可用性レプリカは、同一の WSFC クラスターの異なるノード上に存在する必要があります。 唯一の例外は、別の WSFC クラスターに移行するときに、可用性グループは一時的に 2 つのクラスターにまたがることができるという点です。

WSFC リソース グループは、作成されたすべての可用性グループに対して作成されます。 WSFC クラスターは、このリソース グループを監視して、プライマリ レプリカの正常性を評価します。 Always On可用性グループのクォーラムは、特定のクラスター ノードが可用性レプリカをホストしているかどうかに関係なく、WSFC クラスター内のすべてのノードに基づいています。 データベース ミラーリングとは対照的に、Always On可用性グループにはミラーリング監視ロールはありません。

次の図は、1 つのプライマリ レプリカと 4 つのセカンダリ レプリカを含む可用性グループを示しています。 最大 8 つのセカンダリ レプリカ (1 つのプライマリ レプリカと 2 つの同期コミット セカンダリ レプリカ) がサポートされています。

可用性データベース

可用性グループに追加するデータベースは、オンラインの読み取り/書き込みデータベースであることが必要であり、プライマリ レプリカをホストするサーバー インスタンスに置かれている必要があります。 追加されたデータベースは、プライマリ データベースとして可用性グループに参加しますが、引き続きクライアントから使用できます。 新しいプライマリ データベースのバックアップが、セカンダリ レプリカをホストするサーバー インスタンスに復元されない限り (RESTORE WITH NORECOVERY を使用します)、対応するセカンダリ データベースは存在しません。 新しいセカンダリ データベースは、可用性グループに参加するまでは RESTORING 状態です。 詳細については、「AlwaysOn セカンダリ データベースでのデータ移動の開始 (SQL Server)」を参照してください。

可用性グループに参加すると、セカンダリ データベースは ONLINE 状態になり、対応するプライマリ データベースとのデータ同期が開始されます。 データ同期 は、プライマリ データベースへの変更をセカンダリ データベースに再現するプロセスです。 データ同期では、プライマリ データベースがトランザクション ログ レコードをセカンダリ データベースに送信します。

可用性レプリカ

各可用性グループは、可用性レプリカと呼ばれる 2 つ以上のフェールオーバー パートナーを定義します。 可用性レプリカ は、可用性グループのコンポーネントです。 各可用性レプリカは、可用性グループ内の可用性データベースのコピーをホストします。 各可用性グループで、個々の可用性レプリカは、1 つの WSFC クラスターの別々のノード上に存在する SQL Server の個々のインスタンスによってホストされる必要があります。 これらのサーバー インスタンスそれぞれで、AlwaysOn を有効にする必要があります。

指定したインスタンスで、1 つの可用性グループにつき 1 つだけ可用性レプリカをホストすることができます。 ただし、各インスタンスを多数の可用性グループに使用することはできます。 指定したインスタンスは、スタンドアロン インスタンスまたは SQL Server フェールオーバー クラスター インスタンス (FCI) として使用できます。 サーバー レベルの冗長性が必要な場合は、フェールオーバー クラスター インスタンスを使用します。

すべての可用性レプリカには、初期ロールとして、プライマリ ロールまたはセカンダリ ロールが割り当てられています。これが、レプリカの可用性データベースによって継承されます。 指定されたレプリカのロールにより、読み取り/書き込みデータベースと読み取り専用のデータベースのどちらがホストされるかが決定されます。 プライマリ レプリカと呼ばれる 1 つのレプリカには、プライマリ ロールが割り当てられ、 プライマリ データベースと呼ばれる読み取り/書き込みデータベースをホストします。 それ以外の 1 つ以上のレプリカは セカンダリ レプリカと呼ばれ、セカンダリ ロールが割り当てられます。 セカンダリ レプリカは、セカンダリ データベースと呼ばれる読み取り専用のデータベースをホストします。

可用性モード

可用性モードは、各可用性レプリカのプロパティです。 可用性モードによって、特定のセカンダリ レプリカがディスクにトランザクション ログ レコードを書き込む (ログ書き込み) まで、プライマリ レプリカによるデータベースへのトランザクションのコミットを待機するかどうかが決定されます。 Always On可用性グループでは、非同期コミット モードと同期コミット モードの 2 つの可用性モードがサポートされています。

• Asynchronous-commit mode

  この可用性モードを使用する可用性レプリカは、非同期コミット レプリカと呼ばれます。 非同期コミット モードでは、非同期コミット セカンダリ レプリカによりログが書き込まれことが確認されるまで待機せずに、プライマリ レプリカがトランザクションをコミットします。 非同期コミット モードでは、セカンダリ データベースでのトランザクションの遅延が最小になりますが、セカンダリ データベースがプライマリ データベースよりも遅延する場合があるため、一部のデータが失われる可能性があります。

• Synchronous-commit mode

  この可用性モードを使用する可用性レプリカは、 同期コミット レプリカと呼ばれます。 同期コミット モードの場合、同期コミット プライマリ レプリカは、同期コミット セカンダリ レプリカによるログ書き込みが確認されるまで待機した後で、トランザクションをコミットします。 同期コミット モードでは、特定のセカンダリ データベースがプライマリ データベースに 1 回同期されれば、コミットされたトランザクションが完全に保護されることが保証されます。 この保護の欠点は、トランザクションの遅延が増加することです。

詳細については、「 可用性モード (AlwaysOn 可用性グループ)」を参照してください。

フェールオーバーの種類

プライマリ レプリカとセカンダリ レプリカとのセッションのコンテキスト内で、プライマリ ロールとセカンダリ ロールが フェールオーバーと呼ばれるプロセスで交換されることがあります。 フェールオーバー中に、対象のセカンダリ レプリカがプライマリ ロールに移行し、新しいプライマリ レプリカになります。 新しいプライマリ レプリカのデータベースがプライマリ データベースとしてオンラインになります。クライアント アプリケーションから、これらのデータベースに接続できるようになります。 元のプライマリ レプリカは使用可能になるとセカンダリ ロールに移行し、セカンダリ レプリカになります 元のプライマリ データベースはセカンダリ データベースになり、データ同期が再開されます。

フェールオーバーには、自動、手動、および強制 (データ損失の可能性あり) という 3 つの形式があります。 特定のセカンダリ レプリカでサポートされるフェールオーバーの形式は、可用性モードによって決まります。同期コミット モードでは、プライマリ レプリカのフェールオーバー モードおよび対象のセカンダリ レプリカによって決まります。次に例を示します。

• 同期コミット モードでは、ターゲット セカンダリ レプリカが現在 avt1 と同期されている場合、2 つの形式のフェールオーバー計画による手動フェールオーバー と 自動フェールオーバーがサポートされます。 これらのフェールオーバーの形式のサポートは、フェールオーバー パートナーの フェールオーバー モード プロパティ の設定によって決まります。 プライマリ レプリカとセカンダリ レプリカのどちらかのフェールオーバー モードが "手動" に設定されている場合、そのセカンダリ レプリカに対しては手動フェールオーバーのみがサポートされます。 プライマリ レプリカとセカンダリ レプリカのどちらのフェールオーバー モードも "自動" に設定されている場合、そのセカンダリ レプリカでは自動フェールオーバーと手動フェールオーバーの両方がサポートされます。

  • 計画的な手動フェールオーバー (データ損失なし)

    データベース管理者がフェールオーバー コマンドを発行した後に手動フェールオーバーが開始され、同期されたセカンダリ レプリカがプライマリ ロールに移行し (データ保護の保証あり)、プライマリ レプリカはセカンダリ ロールに移行します。 手動フェールオーバーには、プライマリ レプリカと対象のセカンダリ レプリカの両方が同期コミット モードで実行されていることが必要です。また、セカンダリ レプリカが既に同期されている必要があります。

  • 自動フェールオーバー (データ損失なし)

    エラーが発生すると、自動フェールオーバーが開始されて、同期されたセカンダリ レプリカがプライマリ ロールに移行します (データ保護が保証されます)。 元のプライマリ レプリカは、使用可能になるとセカンダリ ロールに移行します。 自動フェールオーバーでは、プライマリ レプリカと対象のセカンダリ レプリカの両方が同期コミット モードで実行されていることが必要です。また、フェールオーバー モードが "自動" に設定されている必要があります。 さらに、セカンダリ レプリカが既に同期され、WSFC クォーラムを持ち、可用性グループの 柔軟なフェールオーバー ポリシーで指定された条件を満たしている必要があります。

    重要

    SQL Server フェールオーバー クラスター インスタンス (FCI) は可用性グループによる自動フェールオーバーをサポートしないため、FCI によってホストされる可用性レプリカは手動フェールオーバー用にのみ構成できます。

  Note

  同期されたセカンダリ レプリカ上で強制フェールオーバー コマンドを発行した場合、セカンダリ レプリカは計画された手動フェールオーバーの場合と同様に動作します。

• 非同期コミット モードで使用されるフェールオーバーは、 強制フェールオーバーと通常呼ばれる強制手動フェールオーバーのみです (データ損失の可能性あり)。 強制フェールオーバーは手動のみで開始できるため、手動フェールオーバーの一種と見なされます。 強制フェールオーバーは、障害復旧オプションです。 対象のセカンダリ レプリカがプライマリ レプリカに同期されない場合に使用できる唯一のフェールオーバー形式です。

詳細については、「 フェールオーバーとフェールオーバー モード (AlwaysOn 可用性グループ)」を参照してください。

クライアント接続

可用性グループ リスナーを作成することによって、特定の可用性グループのプライマリ レプリカへのクライアント接続を提供できます。 可用性グループ リスナー には、クライアント接続を適切な可用性レプリカに送るために特定の可用性グループにアタッチされる一連のリソースが用意されています。

可用性グループ リスナーは、仮想ネットワーク名 (VNN) として機能する一意の DNS 名、1 つ以上の仮想 IP アドレス (VIP)、および TCP ポート番号に関連付けられています。 詳細については、可用性グループ リスナー、クライアント接続、およびアプリケーションのフェールオーバー (SQL Server) に関するページを参照してください。

アクティブなセカンダリ レプリカ

Always On可用性グループでは、アクティブなセカンダリ レプリカがサポートされます。 アクティブなセカンダリ機能では以下をサポートしています。

• セカンダリ レプリカでのバックアップ操作の実行

  セカンダリ レプリカでは、ログ バックアップと、データベース全体、ファイル、またはファイル グループの コピーのみの バックアップを実行できます。 可用性グループを構成して、バックアップを実行する優先順位を指定できます。 優先順位は SQL Server によって適用されるものではないので、アドホック バックアップには影響がないことを理解しておくことが重要です。 この優先順位の解釈は、特定の可用性グループの各データベースに対するバックアップ ジョブのスクリプトでのロジックに依存します (ある場合)。 同じ可用性グループ内の個々の可用性レプリカで実行されるバックアップの優先順位を指定できます。 詳細については、「 アクティブなセカンダリ: セカンダリ レプリカでのバックアップ (AlwaysOn 可用性グループ)」を参照してください。

• 1 つ以上のセカンダリ レプリカへの読み取り専用アクセス (読み取り可能なセカンダリ レプリカ)

  セカンダリ ロールを実行するときに、ローカル データベースへの読み取り専用アクセスを許可するように可用性レプリカを構成できます (ただし、一部の操作は完全にはサポートされていません)。 また、読み取り専用ワークロードがプライマリ レプリカで実行されないようにする場合は、プライマリ ロールで実行されているときに読み取り/書き込みアクセスのみを許可するようにレプリカを構成できます。 詳細については、「 アクティブなセカンダリ: 読み取り可能なセカンダリ レプリカ (AlwaysOn 可用性グループ)」を参照してください。

  可用性グループに、現在、可用性グループ リスナーと 1 つ以上の読み取り可能なセカンダリ レプリカが存在する場合、SQL Server では読み取りを目的とした接続要求をそれらのいずれかにルーティングできます (読み取り専用ルーティング)。 詳細については、可用性グループ リスナー、クライアント接続、およびアプリケーションのフェールオーバー (SQL Server) に関するページを参照してください。

セッション タイムアウト期間

セッション タイムアウト期間は、可用性レプリカのプロパティで、他の可用性レプリカとの接続を閉じるまでに非アクティブに保持できる時間を決定します。 プライマリ レプリカとセカンダリ レプリカは、アクティブであることを通知するために互いに ping を実行します。 他のレプリカからタイムアウト期間内に ping を受信した場合は、その接続がまだ開いており、サーバー インスタンスが通信していることを示します。 可用性レプリカは、ping を受信すると、接続のセッション タイムアウト カウンターをリセットします。

セッション タイムアウト期間を設定することにより、相手レプリカからの ping を受信するまで無期限に待機することがなくなります。 セッション タイムアウト期間中に相手のレプリカから ping を受信しなかった場合、レプリカはタイムアウトします。レプリカの接続は閉じられ、タイムアウトしたレプリカは DISCONNECTED 状態になります。 切断されたレプリカが同期コミット モード用に構成されている場合でも、トランザクションは、そのレプリカが再接続および再同期するのを待機しません。

各可用性レプリカの既定のセッション タイムアウト期間は 10 秒です。 この値はユーザーが構成でき、最小値は 5 秒です。 通常は、タイムアウト期間を 10 秒以上にしておくことをお勧めします。 値を 10 秒未満に設定すると、負荷の高いシステムで誤認エラーが示される可能性があります。

ページの自動修復

各可用性レプリカでは、ローカル データベースに破損ページがあると、データ ページの読み取りを妨げるエラーを解決して自動的に復旧しようとします。 セカンダリ レプリカがページを読み取ることができない場合、プライマリ レプリカに対してページの新しいコピーを要求します。 プライマリ レプリカがページを読み取ることができない場合、すべてのセカンダリ レプリカに新しいコピーの要求をブロードキャストし、最初に応答したレプリカからページを取得します。 要求が受け入れられ、新しいコピーを取得できた場合は、読み取り不可能なページがそのコピーに置き換えられます。通常、これによりエラーは解決します。

詳細については、「 ページの自動修復 (可用性グループとデータベース ミラーリングの場合)」を参照してください。

Related Tasks

• AlwaysOn 可用性グループの概要 (SQL Server)

関連コンテンツ

• ブログ:

  AlwaysON - HADRON 学習シリーズ:HADRON 対応データベースでのワーカー プールの使用

  SQL Server AlwaysOn チームのブログ:SQL Server AlwaysOn チームのオフィシャル ブログ

  CSS SQL Server エンジニアのブログ

• ビデオ:

  Microsoft SQL Server コード ネーム "Denali" AlwaysOn シリーズ パート 1: 次世代の高可用性ソリューションの概要

  Microsoft SQL Server コードネーム "Denali" AlwaysOn シリーズ パート 2: AlwaysOn を使用したミッション クリティカルな高可用性ソリューションの構築

• ホワイト ペーパー:

  高可用性と災害復旧のための Microsoft SQL Server AlwaysOn ソリューション ガイド

  SQL Server 2012 に関する Microsoft ホワイト ペーパー

  SQL Server ユーザー諮問チームのホワイト ペーパー

参照

可用性モード (AlwaysOn 可用性グループ)フェールオーバーモードとフェールオーバー モード (AlwaysOn 可用性グループ)AlwaysOn 可用性グループの Transact-SQL ステートメントの概要 (SQL Server)AlwaysOn 可用性グループの PowerShell コマンドレットの概要 (SQL Server)In-Memory OLTP データベースの高可用性サポートAlwaysOn 可用性グループの前提条件、制限事項、および推奨事項 (SQL Server)可用性グループの作成と構成 (SQL Server)アクティブなセカンダリ: 読み取り可能なセカンダリ レプリカ (AlwaysOn 可用性グループ)アクティブなセカンダリ: セカンダリ レプリカでのバックアップ (AlwaysOn 可用性グループ)可用性グループ リスナー、クライアント接続、およびアプリケーション フェールオーバー (SQL Server)