SQL Server Always On 可用性グループ [2026 ガイド]

Always On可用性グループ（AG）は SQL Server Enterprise 高可用性データベースレベルで動作する、可用性と災害復旧ソリューションです。可用性グループは、1つ以上のユーザーデータベースを単一のフェイルオーバーユニットにグループ化し、継続的なトランザクションログ配布を通じて最大8つのセカンダリレプリカに複製します。プライマリレプリカに障害が発生すると、指定された同期セカンダリが自動的に引き継ぎ、共有ストレージや手動による介入なしに数秒でアクセスを復旧します。

1.2 Always On 可用性グループとフェールオーバークラスターインスタンス

SQL Server Always On には、可用性グループ (AG) とフェールオーバークラスターインスタンス (FCI) という 2 つの異なるテクノロジが含まれます。

	Always On 可用性グループ	Always On フェールオーバークラスターインスタンス
フェイルオーバースコープ	データベースレベル	インスタンスレベル（すべてのデータベースが同時にフェイルオーバー）
データ複製	各セカンダリへのログベースのレプリケーション	なし - すべてのノードが同じストレージを共有します
共有ストレージ	必須ではありません	必須（ストレージエリアネットワーク (SAN)、iSCSI、S2D、または SMB）
読み取り可能なセカンダリ	はい	いいえ
災害からの回復	組み込み（サイト間の非同期レプリカ）	AGとペアリングしないと内蔵されません

それぞれを使用する場合: インスタンスレベルのフェイルオーバーが必要で、既に共有ストレージインフラストラクチャがある場合は、FCIを使用してください。データベースレベルの粒度、読み取り可能なセカンダリ、または災害復旧が必要な場合は、AGを使用してください。最も完全な保護を実現するには、両方を組み合わせます。各レプリカをFCIノードとして実行し、それらをAGでリンクしてください。

1.3 利点と限界

メリット：

同期レプリカのほぼゼロの復旧時間目標 (RTO) を備えた自動フェイルオーバー。
同期コミットモードでのデータ損失ゼロ (復旧ポイント目標 (RPO) = 0)。
共有ストレージは不要です。各レプリカは独立したローカルストレージを使用します。
読み取り可能なセカンダリは、プライマリからレポートとバックアップのワークロードをオフロードします。
単一の構成内でローカル高可用性 (HA) とクロスサイト災害復旧 (DR) の両方をサポートします。

制限事項：

すべてのレプリカに Windows Server フェールオーバークラスタリングが必要です。
完全な機能セットを備えた Enterprise Edition (Standard Edition は大幅な制限付きで Basic AG をサポートします)。
同期コミットモードでは、ネットワークの往復時間に比例して書き込み操作の遅延が増加します。
ログイン、SQLエージェントジョブ、リンクサーバーは自動的に同期されません。 SQL Server 2019年以前（解決済み） SQL Server 2022 には可用性グループが含まれていました。

2. Always On 可用性グループのアーキテクチャ

2.1 コアコンポーネントと概念

2.1.1 可用性データベース

可用性データベースは、可用性グループに参加するユーザーデータベースです。これらのデータベースは、特定の要件を満たす必要があります。つまり、完全復旧モデルを使用し、完全バックアップを取得し、可用性グループに追加される前にプライマリレプリカ上に存在している必要があります。

データベースが可用性グループに参加すると、同期されたセットの一部となり、ユニットとしてフェイルオーバーします。可用性グループ内のすべてのデータベースは同じフェイルオーバー状態を共有します。つまり、プライマリレプリカに障害が発生した場合、すべてのデータベースが同じセカンダリレプリカに同時にフェイルオーバーします。これにより、複数の関連データベースに依存するアプリケーションの一貫性が確保されます。

2.1.2 可用性レプリカ

可用性レプリカは SQL Server 可用性データベースのコピーをホストするインスタンス。各レプリカは、トランザクションログレコードの転送によって同期された、データベースの物理コピーを保持します。可用性グループには、最大9つのレプリカを含めることができます。内訳は、プライマリレプリカ1つとセカンダリレプリカ最大8つです。

2.1.3 プライマリレプリカ

プライマリレプリカは、可用性データベースの読み書き可能なコピーをホストします。すべてのデータ変更（INSERT、UPDATE、DELETE）はプライマリレプリカ上で行われます。クライアントアプリケーションは、すべての書き込み操作、およびデフォルトでは読み取り操作のためにプライマリレプリカに接続します。

2.1.4 セカンダリレプリカ

セカンダリレプリカは、可用性データベースの読み取り専用コピーをホストし、プライマリレプリカから受信したトランザクションログレコードを継続的に適用することで維持されます。各セカンダリレプリカは、ログレコードを受信、強化、適用することで、データベースコピーをプライマリと同期させます。

2.2 可用性モード

2.2.1 同期コミットモード

同期コミットモードでは、プライマリレプリカがトランザクションログレコードがセカンダリレプリカに書き込まれたことを確認してからトランザクションをコミットすることで、データ損失ゼロの保護を実現します。このモードは、データ損失が許容されない高可用性構成に不可欠です。

2.2.2 非同期コミットモード

非同期コミットモードでは、セカンダリレプリカがログのハードニングを確認するまで待たずにトランザクションをコミットできるため、プライマリレプリカのパフォーマンスが優先されます。このモードは、災害復旧レプリカや、ネットワーク遅延により同期コミットが困難な場合に適しています。

トレードオフとして、フェイルオーバー中にデータ損失が発生する可能性が挙げられます。プライマリレプリカに障害が発生した場合、コミット済みのトランザクションの一部がセカンダリレプリカに到達していない可能性があります。潜在的なデータ損失の量は、ネットワーク帯域幅、セカンダリレプリカのパフォーマンス、そして障害発生のタイミングによって異なります。非同期モードを使用する場合、組織はこのリスクを受け入れる必要があります。

2.3 フェイルオーバーの種類

2.3.1 自動フェイルオーバー

自動フェイルオーバーにより、可用性グループはプライマリレプリカの障害を検出し、管理者の介入なしにセカンダリレプリカをプライマリに自動的に昇格させることができます。この機能により、障害への手動対応が不要になり、RTOが最小限に抑えられます。

自動フェイルオーバーでは、データ損失ゼロを保証するために同期コミットモードが必要です。有効にすると、可用性グループはプライマリレプリカの正常性を継続的に監視します。プライマリレプリカが応答しなくなったり、障害が発生した場合、Windows Server フェールオーバークラスターは指定されたセカンダリレプリカへの自動フェイルオーバーを開始します。

2.3.2 手動フェイルオーバー

手動フェイルオーバーを使用すると、管理者は計画的なメンテナンスやテストのために、プライマリレプリカの役割をセカンダリレプリカに意図的に切り替えることができます。自動フェイルオーバーとは異なり、手動フェイルオーバーを開始するには管理者の明示的な操作が必要です。

同期コミットレプリカでは、データ損失のない手動フェイルオーバーが可能です。管理者は、以下の手順でフェイルオーバーを開始します。 SQL Server Management Studio、Transact-SQL、またはPowerShellを使用します。プライマリレプリカは、現在のトランザクションの処理を完了し、残りのすべてのログレコードをターゲットセカンダリに送信し、プライマリロールを転送する前に確認を待ちます。

非同期コミットレプリカでも手動フェイルオーバーは可能ですが、強制フェイルオーバーが必要となり、データ損失の可能性があります。管理者は、プライマリレプリカが利用できず、ダウンタイムの延長よりもデータ損失が許容できる、実際の災害シナリオにおいてのみ、強制手動フェイルオーバーを使用する必要があります。

2.3.3 強制フェイルオーバー

強制フェイルオーバーでは、データ損失の可能性を明示的に確認した上で、非同期のセカンダリレプリカまたは完全に同期されていないセカンダリレプリカへのフェイルオーバーが可能です。このオプションは、プライマリレプリカが利用できず、同期されたセカンダリレプリカも存在しない場合の最後の手段として機能します。

2.4 データ同期

2.4.1 データ同期の仕組み

Always On 可用性グループにおけるデータ同期は、プライマリレプリカからすべてのセカンダリレプリカへのトランザクションログレコードの継続的な送信を通じて行われます。このログベースの同期により、各レプリカの独立したストレージを維持しながら一貫性を確保できます。

2.4.2 トランザクションログ記録と強化

トランザクションログの強化は、ログレコードをセカンダリレプリカの耐久性の高いストレージに書き込む重要なステップです。強化により、ログレコードはセカンダリレプリカの障害発生時にも保持され、リカバリ時に再生できるようになります。

2.5 読み取りスケールと読み取り可能なセカンダリレプリカ

2.5.1 読み取り専用ワークロードのオフロード

読み取り可能なセカンダリレプリカにより、組織はプライマリレプリカから読み取り集中型のワークロードをオフロードし、システム全体のパフォーマンスとリソース使用率を向上させることができます。この読み取りスケール機能は、従来の高可用性ソリューションに対する可用性グループの重要な利点の一つです。

組織は、可用性グループの構成を設計する際に、読み取り専用ワークロードの要件を考慮する必要があります。複数の読み取り可能なセカンダリサーバーを使用することで、レポート負荷を複数のサーバーに分散できます。読み取り専用ルーティングリストは、セカンダリサーバーが読み取り目的の接続を受信する順序を定義し、負荷分散戦略を実現します。

2.5.2 セカンダリレプリカのバックアップ操作

セカンダリレプリカでバックアップを実行すると、プライマリレプリカの入出力（I/O）負荷とCPU負荷が軽減され、トランザクションワークロードに集中できるようになります。この機能により、組織は本番環境のパフォーマンスに影響を与えることなく、バックアップ要件を満たすことができます。

SQL Server セカンダリレプリカ上の完全データベースバックアップ、差分バックアップ、トランザクションログバックアップをサポートします。バックアップ設定は、セカンダリレプリカを優先、プライマリレプリカを優先、セカンダリレプリカのみを優先、または任意のレプリカのいずれかに設定できます。バックアップシステムは、これらの設定と現在の可用性に基づいて、適切なレプリカを自動的に選択します。

の詳細について SQL Server バックアップについては、総合ガイド.

2.6 可用性グループリスナー

2.6.1 リスナーとは何ですか?

可用性グループリスナーは、クライアントアプリケーションが可用性グループデータベースに接続するために使用する仮想ネットワーク名 (VNN) と IP アドレスです。リスナーは接続を現在のプライマリレプリカに自動的にリダイレクトするため、アプリケーションが現在どのサーバーがプライマリであるかを追跡する必要がなくなります。

2.6.2 クライアント接続ルーティング

リスナーを介したクライアント接続ルーティングは、読み取り/書き込みと読み取り専用の両方の接続インテントをサポートします。リスナーは接続要求を検査し、アプリケーションのインテントに基づいて適切なレプリカにルーティングします。

3. 前提条件と要件

3.1 可用性グループのための Windows Server フェールオーバークラスタリング

3.1.1 Windows Server フェールオーバークラスタリングの基礎

Windows Server フェールオーバークラスタリング (WSFC) は、クラスターメンバーシップ、ヘルスモニタリング、フェールオーバーオーケストレーションを管理することで、Always On 可用性グループの基盤を提供します。フェールオーバークラスターインスタンスとは異なり、可用性グループでは WSFC をクラスターの調整にのみ使用し、共有ストレージの管理には使用しません。

各 SQL Server 可用性グループに参加するインスタンスは、WSFC クラスター内のノードである必要があります。クラスターは、クォーラム投票、ノードの正常性検出、および可用性グループのリソース状態を管理します。プライマリレプリカに障害が発生すると、WSFC はフェールオーバープロセスを調整し、新しいプライマリレプリカを反映するようにクラスターリソースを更新します。

3.1.2 クラスタクォーラム構成

クラスタークォーラムは、ネットワーク接続の問題が発生した場合にどのノードが動作できるかを決定し、複数のノードが独立してプライマリを主張するスプリットブレインシナリオを防止します。クォーラム構成は、クラスターの決定における多数決の構成要素を定義します。

可用性グループには、いくつかのクォーラムモードを使用できます。

ノードマジョリティはクラスターノードの投票のみを使用し、奇数のノードを持つクラスターに適しています。
ノードおよびファイル共有マジョリティは、偶数ノードクラスターに適したファイル共有監視投票を追加します。
ノードとディスクマジョリティはディスク監視を使用しますが、共有ストレージは不要であるため、可用性グループではあまり一般的ではありません。

3.1.3 マルチサブネットクラスタリング

マルチサブネットクラスタリングにより、可用性グループのレプリカを異なるネットワークサブネットにまたがって配置できるようになり、データセンターをまたがる地理的に分散したデプロイメントをサポートします。この機能は、レプリカが別々の場所に存在するディザスターリカバリー構成に不可欠です。

3.2 SQL Server エディション要件

3.2.1 エンタープライズエディションの機能

SQL Server Enterprise Edition は、制限なく完全な可用性グループの機能を提供します。最大 8 つのセカンダリレプリカ、読み取り可能なセカンダリ、自動シード、分散可用性グループ、およびすべての高度な機能をサポートします。

3.2.2 Standard Edition の機能 (基本的な可用性グループ)

SQL Server 2016 Standard Edition以降では、大幅な制限付きで基本可用性グループがサポートされています。基本可用性グループは、よりシンプルな要件を持つ組織向けに、低コストでコアとなる高可用性機能を提供します。

4. Always On 可用性グループの構成

4.1 環境の準備

可用性グループを作成する前に、Active Directory アカウント、サーバー構成、およびネットワークインフラストラクチャが適切に配置された環境を準備する必要があります。

4.1.1 ドメインコントローラのセットアップ

Active Directoryドメインコントローラは、可用性グループクラスタをサポートするように構成する必要があり、 SQL Server サービスアカウント。

ドメイン管理者の資格情報を使用してドメインコントローラーにログインします。
店は開いています サーバーマネージャ に移動して ツール -> Active Directoryユーザーとコンピュータ.
組織単位を作成する SQL Server オブジェクトが存在しない場合は、そのオブジェクトを返します。
すべてのクラスターノードのコンピューターオブジェクトが Active Directory に存在することを確認します。
ドメインネームシステム (DNS) サービスが適切に構成され、すべてのサーバー名が正しく解決されることを確認します。

4.1.2 サービスアカウントの作成

専用のActive Directoryサービスアカウントを作成する SQL Server 各ノード上のサービス。

店は開いています Active Directoryユーザーとコンピュータ ドメインコントローラー上。
適切な組織単位を右クリックして選択 New -> ユーザー.
サービスアカウント名（例：svc_SQLServer）を入力し、 ユーザーのログオン名.
詳しくはこちら次へ強力なパスワードを入力します。
選択 ユーザーはパスワードを変更できません (NAIST) と パスワードは期限切れにならない.
詳しくはこちら次へその後 仕上げ アカウントを作成します。
必要な追加のサービスアカウントについて繰り返します（SQL Server エージェント、SSRS など)。

4.1.3 管理者権限の設定

サービスアカウントと構成に使用するアカウント SQL Server すべてのクラスターノードに対する適切な権限を持っている必要があります。

各クラスターノードサーバーにログインします。
店は開いています コンピューター管理 お気軽にご連絡ください メニューまたはサーバーマネージャー。
研究開発を拡張 ローカルユーザーとグループ をクリックして グループ.
右クリックする 管理者 をクリックして特性.
詳しくはこちら追加サービスアカウント名を入力します。
詳しくはこちら 名前を確認する アカウントを認証するには、 OK.
詳しくはこちら OK 管理者のプロパティダイアログを閉じます。
すべてのクラスターノードで繰り返します。

4.2 WSFCのインストールと構成

Always On 可用性グループを有効にする前に、すべてのノードに Windows Server フェールオーバークラスタリングをインストールして構成する必要があります。

4.2.1 フェールオーバークラスタリング機能のインストール

可用性グループに参加する各サーバーにフェールオーバークラスタリング機能をインストールします。

店は開いています サーバーマネージャ 最初のクラスターノードで。
詳しくはこちら管理 -> 役割と機能を追加する.
詳しくはこちら次へ紹介画面を通して。
選択 役割ベースまたは機能ベースのインストール をクリックし次へ.
ローカルサーバーを選択してクリック次へ.
役割画面をスキップしてクリック次へ.
機能画面で、 フェイルオーバークラスタリング.
詳しくはこちら 機能を追加 管理ツールを含めるように求められた場合。
詳しくはこちら次へその後 インストールを開始する.
インストールが完了するまで待ってクリックします 閉じる.
クラスターに参加するすべてのサーバーで繰り返します。

4.2.2 フェールオーバークラスターの作成

すべてのノードにフェールオーバークラスタリング機能をインストールした後、1 つのノードからクラスターを作成します。

店は開いています フェールオーバークラスターマネージャー from サーバーマネージャ -> ツール.
詳しくはこちら クラスターの作成 アクションウィンドウで。
詳しくはこちら次へ「始める前に」ページをご覧ください。
詳しくはこちら ブラウズ クラスターノードとなるすべてのサーバーを追加します。
詳しくはこちら次へすべてのノードを追加した後。
脱退する すべてのテストを実行する（推奨） 選択してクリック次へ.
検証テストの結果を確認し、エラーや警告に対処します。
詳しくはこちら 仕上げ 検証が正常に完了した後。
クラスターの名前と IP アドレスを入力します。
チェックしない 対象となるすべてのストレージをクラスターに追加します 共有ストレージは不要です。
詳しくはこちら次へ確認内容を確認します。
詳しくはこちら 仕上げ クラスターを作成します。

4.2.3 クラスタ構成の検証

クラスター構成を検証して、すべてのノードが適切に通信でき、クラスターが正しく動作することを確認します。

In フェールオーバークラスターマネージャー、クラスター名を右クリックします。
選択 クラスターの検証 メニューから。
詳しくはこちら次へ「始める前に」ページをご覧ください。
選択 すべてのテストを実行する（推奨） をクリックし次へ.
詳しくはこちら次へ検証テストを開始します。
テストが完了したら検証レポートを確認します。
レポートで特定された障害や警告に対処します。
詳しくはこちら 仕上げ ウィザードを閉じます。

4.3 インストール SQL Server 可用性グループ用

インストールを開始する SQL Server スタンドアロンインストールオプションを使用して可用性グループに参加する各ノードで。

実行する SQL Server 最初のノードにインストールメディアを作成します。
選択 New SQL Server スタンドアロンインストール.
プロダクトキーを入力するか、評価版を選択してください。
ライセンス条項に同意して、をクリックします。次へ.
前提条件のチェックを完了し、問題があれば対処します。
機能選択ページで、 データベースエンジンサービス.
インスタンス名を構成します (すべてのノードで同じインスタンス名を使用します)。
「サーバー構成」ページで、サービスアカウントの資格情報を指定します。
サービス起動タイプを次のように構成します オートマチック.
データベースエンジン構成ページで、認証モードを選択します。
管理者アカウントを追加します。
すべてのノードにわたって一貫したパスを使用してデータディレクトリを構成します。
インストールを完了し、成功を確認します。
同じ設定で他のすべてのクラスターノードにインストールを繰り返します。

4.4 Always On 可用性グループ機能の有効化

インストールした後 SQL Server すべてのノードで、各インスタンスの Always On 可用性グループ機能を有効にします。

4.4.1 有効化 SQL Server 構成マネージャー

　 SQL Server グラフィカルインターフェイスを通じて Always On 可用性グループを有効にするには、Configuration Manager を使用します。

店は開いています SQL Server 構成マネージャー 最初のノードで。
研究開発を拡張 SQL Server Services 左ペインに表示されます。
を右クリックします。 SQL Server インスタンスと選択特性.
クリック AlwaysOn高可用性 タブには何も表示されないことに注意してください。
チェック AlwaysOn可用性グループを有効にする.
Windows フェールオーバークラスター名が正しいことを確認します。
詳しくはこちら OK を入力して変更を保存してください。
詳しくはこちら OK サービスを再起動する必要があるという警告が表示されます。
を右クリックします。 SQL Server サービスと選択 再起動.
サービスが正常に再起動するまでお待ちください。
すべてのクラスターノードで繰り返します。

4.4.2 PowerShell 経由で有効化

PowerShell は、複数のノードにわたって Always On 可用性グループを有効にするスクリプト化された方法を提供します。

最初のノードで管理者として PowerShell を開きます。
インポートする SQL Server PowerShell モジュール:
```
Import-Module SQLPS -DisableNameChecking
```

Always On 可用性グループを有効にする:

Enable-SqlAlwaysOn -ServerInstance "ServerName\InstanceName" -Force

Forceパラメータを使用すると、サービスは自動的に再起動されます。

機能が有効になっていることを確認します。

Get-ItemProperty "SQLSERVER:\SQL\ServerName\InstanceName" | Select-Object IsHadrEnabled

適切なサーバー名とインスタンス名を置き換えて、各クラスターノードに対して繰り返します。

4.4.3 機能が有効になっていることを確認する

構成を続行する前に、すべてのインスタンスで Always On 可用性グループが有効になっていることを確認します。

それぞれに接続 SQL Server インスタンスを使用して SQL Server ManagementStudio。
新しいクエリウィンドウを開いて、次を実行します。
```
SELECT SERVERPROPERTY('IsHadrEnabled')
```
結果が 1 (有効) であることを確認します。
ジョブタイプが SQL Server インスタンスは、フェールオーバークラスターマネージャーのクラスターロールの下に表示されます。
次のコマンドを実行して、可用性グループエンドポイントが存在することを確認します。
```
SELECT * FROM sys.endpoints WHERE type_desc = 'DATABASE_MIRRORING'
```
エンドポイントが存在しない場合は、可用性グループの作成中に作成されます。

4.5 可用性グループ用のデータベースの準備

データベースを可用性グループに追加するには、特定の要件を満たしている必要があります。

4.5.1 データベース復旧モデルの要件

プライマリレプリカを可用性グループに追加する前に、データベース復旧モデルを FULL に変更します。

プライマリレプリカに接続するには SQL Server ManagementStudio。
データベースを右クリックして選択特性.
まず オプション ページで見やすくするために変数を解析したりすることができます。
前日比 回復モデル 〜へフル.
詳しくはこちら OK 変更を保存します。
あるいは、Transact-SQL を使用します。
```
ALTER DATABASE DatabaseName SET RECOVERY FULL;
```

4.5.2 データベースの完全バックアップの取得

可用性グループに必要なバックアップチェーンを確立するには、完全なデータベースバックアップを実行します。

In SQL Server Management Studio で、データベースを右クリックします。
選択 タスク -> バックアップ.
確認します バックアップの種類 に設定されていますフル.
バックアップ先を選択するか、新しい保存先を追加します。
詳しくはこちら OK バックアップを実行します。

あるいは、Transact-SQL を使用します。

BACKUP DATABASE DatabaseName TO DISK = 'C:\Backup\DatabaseName.bak';

4.5.3 トランザクションログのバックアップ

ログチェーンが確立されていることを確認し、初期化時間を最小限に抑えるために、トランザクションログのバックアップを実行します。

In SQL Server Management Studio で、データベースを右クリックします。
選択 タスク -> バックアップ.
前日比 バックアップの種類 〜へ トランザクションログ.
バックアップ先を選択します。
詳しくはこちら OK バックアップを実行します。

あるいは、Transact-SQL を使用します。

BACKUP LOG DatabaseName TO DISK = 'C:\Backup\DatabaseName.trn';

4.6 可用性グループの作成

好みや自動化の要件に応じて、利用可能ないくつかの方法のいずれかを使用して可用性グループを作成します。

4.6.1 新しい可用性グループウィザードの使用

新しい可用性グループウィザードは、可用性グループを作成するためのグラフィカルインターフェイスを提供します。

In SQL Server Management Studio から、プライマリレプリカをホストするインスタンスに接続します。
研究開発を拡張 AlwaysOn高可用性 オブジェクトエクスプローラーで。
右クリックする 可用性グループ をクリックして 新しい可用性グループウィザード.
詳しくはこちら次へ紹介ページにて。
可用性グループの名前を入力してクリックします次へ.
「データベースの選択」ページで、含めるデータベースを選択します。
データベースがすべての前提条件を満たしていることを確認し、クリックします。次へ.
「レプリカの指定」ページで、 レプリカを追加.
各セカンダリレプリカインスタンスに接続します。
各インスタンスのレプリカプロパティ (可用性モード、フェイルオーバーモード) を構成します。
クリック Endpoints タブをクリックしてエンドポイントの構成を確認します。
クリック バックアップ設定 タブをクリックして、バックアップの優先順位を設定します。
クリック リスナー タブをクリックし、オプションでリスナーを作成します。
詳しくはこちら次へデータの同期方法を選択します。
検証結果を確認し、問題があれば対処します。
詳しくはこちら次へ概要を確認します。
詳しくはこちら 仕上げ 可用性グループを作成します。
進行状況を監視し、作成が成功したことを確認します。

4.6.2 Transact-SQLの使用

スクリプト化可能で繰り返し可能な展開のために、Transact-SQL を使用して可用性グループを作成します。

プライマリレプリカに可用性グループを作成します。

CREATE AVAILABILITY GROUP AG_Name
FOR DATABASE DatabaseName
REPLICA ON
  'PrimaryServer\Instance' WITH
    (ENDPOINT_URL = 'TCP://PrimaryServer:5022',
     AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
     FAILOVER_MODE = AUTOMATIC,
     SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL)),
  'SecondaryServer\Instance' WITH
    (ENDPOINT_URL = 'TCP://SecondaryServer:5022',
     AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
     FAILOVER_MODE = AUTOMATIC,
     SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL));

セカンダリレプリカを可用性グループに参加させます。
```
ALTER AVAILABILITY GROUP AG_Name JOIN;
```

セカンダリデータベースに参加します。

ALTER DATABASE DatabaseName SET HADR AVAILABILITY GROUP = AG_Name;

4.6.3 PowerShellの使用

PowerShell は、可用性グループの作成と管理のためのスクリプト機能を提供します。

可用性グループオブジェクトを作成します。

$AG = New-SqlAvailabilityGroup -Name "AG_Name" -Path "SQLSERVER:\SQL\PrimaryServer\Instance"

データベースを追加します:

Add-SqlAvailabilityDatabase -Path "SQLSERVER:\SQL\PrimaryServer\Instance\AvailabilityGroups\AG_Name" -Database "DatabaseName"

New-SqlAvailabilityReplica コマンドレットを使用して、必要なプロパティを持つレプリカを構成します。
Join-SqlAvailabilityGroup コマンドレットを使用してセカンダリレプリカを結合します。

4.7 可用性グループへのレプリカの追加

各インスタンスが可用性グループに参加する方法を制御するレプリカ固有のプロパティを構成します。

4.7.1 レプリカプロパティの設定

各レプリカのプロパティを設定して、可用性グループ内での役割と機能を定義します。

In SQL Server 管理スタジオ、展開 AlwaysOn高可用性 -> 可用性グループ.
可用性グループを展開し、展開します 可用性レプリカ.
レプリカを右クリックして選択特性.
プライマリロールとセカンダリロールの接続設定を確認して変更します。
必要に応じてセッションタイムアウト値を構成します。
詳しくはこちら OK 変更を保存する。

4.7.2 可用性モードの設定

レプリカ間の同期動作を制御するために可用性モードを構成します。

可用性グループを右クリックして、特性.
全般ページに移動します 可用性レプリカ のセクションから無料でダウンロードできます。
各レプリカごとに、 同期コミット or 非同期コミット をドロップダウンから選択します。
ローカルの高可用性レプリカには同期コミットを使用します。
地理的に離れた災害復旧レプリカには非同期コミットを使用します。
詳しくはこちら OK 構成を保存します。

4.7.3 フェイルオーバーモードの設定

フェイルオーバーモードを構成して、各レプリカでフェイルオーバーが発生する方法を制御します。

可用性グループを右クリックして、特性.
全般ページに移動します 可用性レプリカ のセクションから無料でダウンロードできます。
同期コミットレプリカの場合は、 オートマチック or マニュアル フェイルオーバーモード。
自動フェイルオーバーには同期コミットモードが必要であり、無人フェイルオーバーが可能になります。
非同期コミットレプリカの場合、手動フェイルオーバーのみが利用可能です。
自動フェールオーバー用に最大 3 つのレプリカ (プライマリ 1 つとセカンダリ 2 つ) を構成します。
詳しくはこちら OK 設定を適用します。

4.7.4 バックアップ設定の構成

バックアップ設定を行って、バックアップ操作を実行する場所を制御します。

可用性グループを右クリックして、特性.
選択 バックアップ設定 左ペインに表示されます。
次のいずれかのバックアップ設定を選択します。
- セカンダリを優先する: 利用可能な場合はセカンダリにバックアップ、そうでない場合はプライマリにバックアップ
- セカンダリのみ: セカンダリレプリカのみのバックアップ
- プライマリー: プライマリレプリカのみのバックアップ
- レプリカ: 利用可能なレプリカ上のバックアップ
各レプリカのバックアップ優先度の値を設定します (0 ～ 100)。
優先度値が高いほど、優先的にバックアップされる対象を示します。
詳しくはこちら OK 設定を保存します。

4.8 可用性グループリスナーの構成

現在のプライマリレプリカに自動的にリダイレクトする単一の接続ポイントを提供するリスナーを作成します。

4.8.1 リスナーの作成

クライアント接続管理のために、可用性グループにリスナーを追加します。

In SQL Server Management Studio で、可用性グループを展開します。
右クリックする 可用性グループリスナー をクリックして リスナーを追加.
リスナーの DNS 名を入力します (例: AG_Listener)。
ポート番号を入力します（デフォルトは 1433）。
選択 固定IP ネットワークモード用。
詳しくはこちら追加各サブネットに IP アドレスを追加します。
IP アドレスを入力し、サブネットを選択します。
詳しくはこちら OK リスナーを作成します。
リスナーがオブジェクトエクスプローラーに表示され、オンラインになっていることを確認します。

4.8.2 DNSとIP設定の構成

リスナーの DNS 登録とネットワーク構成を確認します。

ドメインコントローラーで DNS マネージャーを開きます。
リスナー名がすべての IP アドレスに登録されていることを確認します。
クライアントマシンからの DNS 解決をテストします。
```
nslookup ListenerName
```
構成されたすべての IP アドレスが返されることを確認します。
フェールオーバークラスターマネージャーで展開します役割可用性グループを選択します。
IP アドレスリソースがオンラインであることを確認します。
ネットワーク名リソースがオンラインであることを確認します。

4.8.3 リスナーの接続性のテスト

クライアントアプリケーションがリスナー経由で接続できることを確認します。

クライアントマシンから開く SQL Server ManagementStudio。
サーバー名の代わりにリスナー名を使用して接続します。
現在のプライマリレプリカへの接続を確認するクエリを実行します。
```
SELECT @@SERVERNAME;
```
接続文字列に ApplicationIntent=ReadOnly を追加して、読み取り意図ルーティングをテストします。
接続が読み取り可能なセカンダリレプリカにリダイレクトされることを確認します。
可用性グループを手動でフェールオーバーし、再接続を確認してフェールオーバーをテストします。

4.9 データ同期方法

データベースコピーを使用してセカンダリレプリカを初期化するためのデータ同期方法を選択します。

4.9.1 自動シード

自動シードにより、手動によるバックアップや復元を必要とせずに、データベースデータがネットワーク経由で転送されます。

可用性グループの作成中に、 自動シード処理 同期方法として。
レプリカ間のネットワーク接続と十分な帯域幅を確保します。
プライマリレプリカは、データベースデータをセカンダリレプリカに自動的にストリーミングします。
可用性グループダッシュボードまたは DMV を使用して、シードの進行状況を監視します。
自動シードには SQL Server 2016以降。
大規模なデータベースの場合は、ネットワークへの影響を考慮し、使用率の低い期間にスケジュールしてください。

4.9.2 手動シード（バックアップと復元）

手動シードでは、プライマリでバックアップを取得し、それをセカンダリレプリカで復元します。

プライマリレプリカで完全バックアップを取得します。
```
BACKUP DATABASE DatabaseName TO DISK = '\\SharePath\DatabaseName.bak';
```
トランザクションログのバックアップを取得します。
```
BACKUP LOG DatabaseName TO DISK = '\\SharePath\DatabaseName.trn';
```

各セカンダリレプリカで、完全バックアップを復元します。

RESTORE DATABASE DatabaseName FROM DISK = '\\SharePath\DatabaseName.bak' WITH NORECOVERY;

ログバックアップを復元します。

RESTORE LOG DatabaseName FROM DISK = '\\SharePath\DatabaseName.trn' WITH NORECOVERY;

データベースを可用性グループに参加させます。

ALTER DATABASE DatabaseName SET HADR AVAILABILITY GROUP = AG_Name;

同期が開始され、データベースが SYNCHRONIZED 状態に達したことを確認します。

4.9.3 データベーススナップショットファイル

データベーススナップショットファイルを使用して、既存のデータベースファイルからセカンダリレプリカを初期化します。

プライマリレプリカ上のデータベースをデタッチまたはバックアップします。
同じファイルパスを使用して、データベースファイルを各セカンダリレプリカにコピーします。
セカンダリレプリカでは、データベースをアタッチするか、回復せずに復元します。
データベースが RESTORING 状態であることを確認します。
データベースを可用性グループに参加させます。
この方法は、ネットワーク転送が不可能な非常に大規模なデータベースに役立ちます。

5。よくある質問

5.1 一般的な質問

Q: Always On FCI と Always On AG の違いは何ですか?

A: Always On フェールオーバークラスターインスタンスは共有ストレージを使用してインスタンスレベルの高可用性を提供しますが、Always On 可用性グループは共有ストレージを使用せずにデータベースレベルの高可用性を提供します。AG は読み取り可能なセカンダリとより柔軟な地理的分散を提供します。

Q: Always On 可用性グループを SQL Server スタンダードエディション？

A：はい。 SQL Server 2016 Standard Edition 以降では、AG ごとに 1 つのデータベース、最大 2 つのレプリカ、読み取り可能なセカンダリサポートなしなどの制限付きで、基本可用性グループをサポートします。

Q: Always On 可用性グループには共有ストレージが必要ですか?

A: いいえ、可用性グループは共有ストレージを必要としません。各レプリカは、トランザクションログシッピングによって同期された、ローカルストレージ上にデータベースの独立したコピーを保持します。

Q: 可用性グループ内のレプリカの最大数はいくつですか?

A: SQL Server Enterprise Edition は最大 9 つのレプリカ（プライマリ 1 つとセカンダリ 8 つ）をサポートします。分散型可用性グループは、2 つの可用性グループ全体で最大 18 個のレプリカをサポートできます。

5.2 設定に関する質問

Q: 同期コミットモードと非同期コミットモードのどちらを選択すればよいですか?

A: 同一データセンター内または低レイテンシネットワーク内でデータ損失ゼロが求められる場合は、同期コミットを使用してください。遠隔地の災害復旧レプリカで同期コミットがパフォーマンスに影響を与える場合は、非同期コミットを使用してください。

Q: 同じ可用性グループ内に同期レプリカと非同期レプリカを混在させることはできますか?

A: はい、可用性グループは同期レプリカと非同期レプリカの両方を含む混合構成をサポートしています。これにより、同期レプリカによるローカルの高可用性と、非同期レプリカによる遠隔地の災害復旧が可能になります。

Q: フェイルオーバー中に接続はどうなりますか?

A: フェイルオーバーが発生すると、既存の接続は切断されます。接続再試行ロジックを備えたアプリケーションは、リスナーを介して新しいプライマリに自動的に再接続します。フェイルオーバープロセスは通常、数秒から数分以内に完了します。

Q: レプリカ間でログインとジョブを同期する必要がありますか?

A：で SQL Server 2019 以前では、はい – ログイン、SQL エージェントジョブ、およびリンクサーバーを手動で同期する必要があります。 SQL Server 2022 では、これらのオブジェクトを自動的に含める包含可用性グループが導入されています。

5.3 管理に関する質問

Q: セカンダリレプリカでバックアップを実行できますか?

A: はい、セカンダリレプリカは完全バックアップ、差分バックアップ、トランザクションログバックアップをサポートしています。バックアップ設定を構成することで、プライマリレプリカからバックアップをオフロードし、リソース使用率を削減できます。

Q: パッチを当てるにはどうすればいいですか SQL Server ダウンタイムを最小限に抑えて?

A: ローリングアップグレードでは、まずセカンダリレプリカにパッチを適用し、次にパッチを適用したセカンダリレプリカに手動でフェイルオーバーし、最後に以前のプライマリレプリカにパッチを適用します。これにより、フェイルオーバー中のダウンタイムを最小限に抑えることができます。

Q: 既存の可用性グループにデータベースを追加できますか?

A: はい、実行中の可用性グループにデータベースを追加できます。データベースは完全復旧モデルで完全バックアップされている必要があり、セカンダリレプリカは自動シードまたは手動バックアップと復元を使用してシードされている必要があります。

Q: 自動シードとは何ですか? また、使用する必要がありますか?

A: 自動シードは、データベースのデータをネットワーク経由で転送し、手動バックアップなしでセカンダリレプリカを初期化します。小規模なデータベースやネットワーク帯域幅が十分な場合に使用してください。非常に大規模なデータベースの場合は、手動シードの方が高速な場合があります。

Q: 可用性グループでは DBCC CHECKDB をどこで実行すればよいですか?

A: プライマリレプリカの負荷を軽減するには、セカンダリレプリカでDBCC CHECKDBを実行する必要があります。データベース整合性チェックは、プライマリレプリカのパフォーマンスに影響を与えることなく、セカンダリデータベースに対して実行できます。

DBCC CHECKDBの詳細については、総合ガイド.

5.4 トラブルシューティングに関する質問

Q: データベースが NOT SYNCHRONIZING 状態になっているのはなぜですか?

A: 一般的な原因としては、ネットワーク接続の問題、データ移動の中断、セカンダリレプリカのディスク容量不足、エンドポイントの問題などが挙げられます。同期の正常性の説明を確認し、 SQL Server 詳細はエラーログを参照してください。セカンダリデータベースが回復状態またはショー回復保留中具体的な修正方法については、リンク先のガイドを参照してください。

Q: プライマリが利用できない場合にフェイルオーバーを強制するにはどうすればよいですか?

A: セカンダリレプリカに接続し、ALTER AVAILABILITY GROUP AG_Name FORCE_FAILOVER_ALLOW_DATA_LOSS を実行します。これにより、データ損失の可能性が認識され、セカンダリが直ちにプライマリに昇格されます。

Q: クライアントがリスナーに接続できないのはなぜですか?

A: フェールオーバークラスターマネージャーでリスナーがオンラインであること、DNS 登録が成功していること、すべてのリスナー IP がクライアントからアクセス可能であること、ファイアウォールルールによってリスナーポートへのトラフィックが許可されていることを確認します。

Q: 大きな再実行キューはどういう意味ですか?

A: 大きなREDOキューは、セカンダリレプリカがログレコードの到着速度に追いつけないことを示しています。これは、ディスクI/Oのボトルネック、CPUの制約、またはセカンダリにおける読み取り専用クエリのブロックを示している可能性があります。

Q: 災害がすべてのレプリカに影響し、バックアップも破損している場合はどうすればよいでしょうか?

A: この最悪のシナリオは極めてまれですが、ランサムウェア攻撃、広範囲にわたるストレージ障害、または連鎖的な災害によって発生する可能性があります。主な防御策は予防です。地理的に分散したレプリカを維持し、バックアップを別の場所に保存し、
災害復旧手順を定期的にテストしてください。標準的な復旧オプションがすべて失敗した場合は、専門の SQLデータ復旧ツール緊急時の最後の手段として、破損した MDF ファイルからデータを抽出しようとする場合があります。

5.5 ライセンスと費用に関する質問

Q: Always On 可用性グループのライセンスはどのように付与されますか?

A: SQL Server ライセンスはエディションとデプロイメントモデルによって異なります。Enterprise Editionの可用性グループでは、すべてのレプリカにEnterpriseライセンスが必要です。パッシブセカンダリレプリカは、一定の条件下で無償ライセンスの対象となる場合があります。

Q：使用できますか SQL Server 可用性グループ用の Developer Edition ですか?

A: はい、Developer Editionには、完全な可用性グループのサポートを含むEnterprise Editionのすべての機能が含まれています。ただし、開発とテストのみにライセンスが付与され、本番環境での使用はできません。

Q: 読み取り可能なセカンダリには追加のライセンスが必要ですか?

A: ライセンスはシナリオによって異なります。災害復旧用のパッシブセカンダリには通常、ライセンスは不要です。読み取り専用ワークロードを処理するアクティブセカンダリには、具体的な条件は異なりますが、一般的にライセンスが必要です。

Q: 高可用性を無料で実現する方法はありますか？ SQL Server?

A: SQL Server Express Edition は可用性グループをサポートしていません。 SQL Server Standard Edition は、以下の基本可用性グループをサポートしています。 SQL Server 2016年、スタンダードエディションのライセンス費用で基本的な高可用性を提供開始。

Q: 分散型可用性グループとは何ですか?

A: 分散型可用性グループは、2つの別々の可用性グループにまたがる特殊なタイプの可用性グループであり、従来の可用性グループの機能を超えるシナリオを可能にします。 SQL Server 2016 年、分散型可用性グループは、スケーリングと地理的分散の要件に対応します。

6. 結論

6.1 重要なポイントのまとめ

SQL Server Always On 可用性グループは、ミッションクリティカルなデータベース向けの、Microsoft の最高峰の高可用性および災害復旧ソリューションです。共有ストレージを必要とせずにデータベースレベルのフェイルオーバーを実現し、読み取り可能なセカンダリレプリカによるワークロードのオフロード、そして包括的なデータ保護を実現する柔軟な地理的分散を実現します。ログシッピング or レプリケーション可用性グループは、より堅牢で操作が簡単なアップグレードパスを提供します。

6.2 Always On 可用性グループを使用する場合

自動フェイルオーバー機能を備えたデータベースレベルの高可用性が必要な場合は、可用性グループを選択してください。重要なデータベースのデータ損失ゼロの保護を必要とする組織は、自動フェイルオーバー機能を備えた同期コミットレプリカのメリットを享受できます。読み取りスケール機能を必要とするアプリケーションでは、読み取り可能なセカンダリレプリカを活用してクエリワークロードを分散できます。

6.3 実装の開始

可用性グループの計画は、RTO、RPO、予算制約などのビジネス要件を評価することから始めます。現在のデータベースインフラストラクチャ、アプリケーションの依存関係、高可用性ギャップを文書化します。リソースの制約内で要件を満たす可用性グループアーキテクチャを設計します。

参考情報

Microsoft 公式ドキュメント: Always On 可用性グループとは何ですか?
Microsoft 公式ドキュメント: Always On可用性グループの利用開始
Microsoft 公式ドキュメント: 分散型可用性グループ

著者について

袁勝 10年以上の経験を持つ上級データベース管理者（DBA）です。 SQL Server 環境およびエンタープライズデータベース管理に精通しており、金融サービス、医療、製造業など、様々な組織において数百件のデータベース復旧シナリオを解決してきました。

ユアンの専門は SQL Server データベースの復旧、高可用性ソリューション、パフォーマンス最適化など、幅広い分野に精通しています。彼は、マルチテラバイト規模のデータベースの管理、Always On可用性グループの実装、ミッションクリティカルなビジネスシステム向けの自動バックアップおよび復旧戦略の開発など、豊富な実務経験を有しています。

Yuanは、技術的な専門知識と実践的なアプローチを通じて、データベース管理者やITプロフェッショナルが複雑な問題を解決するのに役立つ包括的なガイドの作成に重点を置いています。 SQL Server 効率的に課題に取り組みます。常に最新の SQL Server リリースと Microsoft の進化するデータベーステクノロジを活用し、定期的にリカバリシナリオをテストして、推奨事項が実際のベストプラクティスを反映していることを確認します。

について質問があります SQL Server 回復または追加のデータベーストラブルシューティングガイダンスが必要ですか？Yuanは歓迎しますフィードバックと提案これらの技術リソースを改善するためです。

SQL Server Always On 可用性グループ: 完全ガイド [2026]

1. Always On 可用性グループについて

1.1 それは何であり、どのように機能するのか

1.2 Always On 可用性グループとフェールオーバー クラスター インスタンス