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

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

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

可用性データベースの各セットは、 可用性レプリカによってホストされます。 2 種類の可用性レプリカが存在します。1 つの プライマリ レプリカです。 はプライマリ データベースをホストし、1 ~ 8 個の セカンダリ レプリカをホストし、それぞれが一連のセカンダリ データベースをホストし、可用性グループの潜在的なフェールオーバー ターゲットとして機能します。 可用性グループは、可用性レプリカのレベルでフェールオーバーします。 可用性レプリカは、1 つの可用性グループ内の一連のデータベースに対して、データベース レベルでのみ冗長性を提供します。 フェールオーバーは、データ ファイルの損失やトランザクション ログの破損が原因でデータベースが疑われるなど、データベースの問題が原因ではありません。

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

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

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

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

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

可用性データベース

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

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

可用性レプリカ

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

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

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

可用性モード

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

• 非同期コミット モード

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

• 同期コミット モード

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

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

フェールオーバーの種類

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

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

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

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

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

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

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

    Important

    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) に関するページを参照してください。

Session-Timeout 期間

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

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

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

ページの自動修復

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

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

関連タスク

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

関連コンテンツ

• ブログ:

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

  SQL Server AlwaysOn チームブログ: AlwaysOn チームブログSQL Server公式

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

• 動画:

  Microsoft SQL Server Code-Named "Denali" AlwaysOn シリーズ、パート 1: 次世代高可用性ソリューションの概要

  Microsoft SQL Server Code-Named "Denali" AlwaysOn シリーズ、パート 2: AlwaysOn を使用した Mission-Critical 高可用性ソリューションの構築

• ホワイト ペーパー:

  高可用性とディザスター リカバリーのための 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)