次の方法で共有

可用性グループの変更 (Transact-SQL)

適用対象:SQL Server

SQL Server の既存の AlwaysOn 可用性グループを変更します。 ほとんどの ALTER AVAILABILITY GROUP 引数は、現在のプライマリ レプリカでのみサポートされます。 ただし、 JOIN、 FAILOVER、および FORCE_FAILOVER_ALLOW_DATA_LOSS の引数は、セカンダリ レプリカでのみサポートされます。

Transact-SQL 構文表記規則

構文

ALTER AVAILABILITY GROUP group_name
  {
     SET ( <set_option_spec> )
   | ADD DATABASE database_name
   | REMOVE DATABASE database_name
   | ADD REPLICA ON <add_replica_spec>
   | MODIFY REPLICA ON <modify_replica_spec>
   | REMOVE REPLICA ON <server_instance>
   | JOIN
   | JOIN AVAILABILITY GROUP ON <add_availability_group_spec> [ , ...2 ]
   | MODIFY AVAILABILITY GROUP ON <modify_availability_group_spec> [ , ...2 ]
   | GRANT CREATE ANY DATABASE
   | DENY CREATE ANY DATABASE
   | FAILOVER
   | FORCE_FAILOVER_ALLOW_DATA_LOSS
   | ADD LISTENER 'dns_name' ( <add_listener_option> )
   | MODIFY LISTENER 'dns_name' ( <modify_listener_option> )
   | RESTART LISTENER 'dns_name'
   | REMOVE LISTENER 'dns_name'
   | OFFLINE
  }
[ ; ]

<set_option_spec> ::=
    AUTOMATED_BACKUP_PREFERENCE = { PRIMARY | SECONDARY_ONLY | SECONDARY | NONE }
  | FAILURE_CONDITION_LEVEL  = { 1 | 2 | 3 | 4 | 5 }
  | HEALTH_CHECK_TIMEOUT = milliseconds
  | DB_FAILOVER  = { ON | OFF }
  | DTC_SUPPORT  = { PER_DB | NONE }
  | REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = { integer }
  | ROLE = SECONDARY
  | CLUSTER_CONNECTION_OPTIONS = 'key_value_pairs> [ ;... ] '

<server_instance> ::=
 { 'system_name [ \instance_name ] ' | 'FCI_network_name [ \instance_name ] ' }

<add_replica_spec>::=
  <server_instance> WITH
    (
       ENDPOINT_URL = 'TCP://system-address:port' ,
       AVAILABILITY_MODE = { SYNCHRONOUS_COMMIT | ASYNCHRONOUS_COMMIT | CONFIGURATION_ONLY } ,
       FAILOVER_MODE = { AUTOMATIC | MANUAL }
       [ , <add_replica_option> [ , ...n ] ]
    )

  <add_replica_option>::=
       SEEDING_MODE = { AUTOMATIC | MANUAL }
     | BACKUP_PRIORITY = n
     | SECONDARY_ROLE ( {
            [ ALLOW_CONNECTIONS = { NO | READ_ONLY | ALL } ]
        [ , ] [ READ_ONLY_ROUTING_URL = 'TCP://system-address:port' ]
     } )
     | PRIMARY_ROLE ( {
            [ ALLOW_CONNECTIONS = { READ_WRITE | ALL } ]
        [ , ] [ READ_ONLY_ROUTING_LIST = { ( '<server_instance>' [ , ...n ] ) | NONE } ]
        [ , ] [ READ_WRITE_ROUTING_URL = 'TCP://system-address:port' ]
     } )
     | SESSION_TIMEOUT = integer

<modify_replica_spec>::=
  <server_instance> WITH
    (
       ENDPOINT_URL = 'TCP://system-address:port'
     | AVAILABILITY_MODE = { SYNCHRONOUS_COMMIT | ASYNCHRONOUS_COMMIT }
     | FAILOVER_MODE = { AUTOMATIC | MANUAL }
     | SEEDING_MODE = { AUTOMATIC | MANUAL }
     | BACKUP_PRIORITY = n
     | SECONDARY_ROLE ( {
          [ ALLOW_CONNECTIONS = { NO | READ_ONLY | ALL }  ]
        | [ READ_ONLY_ROUTING_URL = { 'TCP://system-address:port' | NONE } ]
          } )
     | PRIMARY_ROLE ( {
          [ ALLOW_CONNECTIONS = { READ_WRITE | ALL }   ]
        | [ READ_ONLY_ROUTING_LIST = { ( '<server_instance>' [ , ...n ] ) | NONE } ]
        | [ READ_WRITE_ROUTING_URL = { 'TCP://system-address:port' | NONE }  ]
          } )
     | SESSION_TIMEOUT = seconds
    )

<add_availability_group_spec>::=
 <ag_name> WITH
    (
       LISTENER_URL = 'TCP://system-address:port' ,
       AVAILABILITY_MODE = { SYNCHRONOUS_COMMIT | ASYNCHRONOUS_COMMIT } ,
       FAILOVER_MODE = MANUAL ,
       SEEDING_MODE = { AUTOMATIC | MANUAL }
    )

<modify_availability_group_spec>::=
 <ag_name> WITH
    (
       LISTENER = 'TCP://system-address:port'
       | AVAILABILITY_MODE = { SYNCHRONOUS_COMMIT | ASYNCHRONOUS_COMMIT }
       | SEEDING_MODE = { AUTOMATIC | MANUAL }
    )

<add_listener_option> ::=
   {
      WITH DHCP [ ON ( <network_subnet_option> ) ]
    | WITH IP ( { ( <ip_address_option> ) } [ , ...n ] ) [ , PORT = listener_port ]
   }

  <network_subnet_option> ::=
     'ipv4_address' , 'ipv4_mask'

  <ip_address_option> ::=
     {
        'four_part_ipv4_address' , 'four_part_ipv4_mask'
      | 'ipv6_address'
     }

<modify_listener_option>::=
    {
       ADD IP ( <ip_address_option> )
     | PORT = listener_port
     | REMOVE IP ( 'ipv4_address' | 'ipv6_address')
    }

引数

group_name

新しい可用性グループの名前を指定します。 group_name は有効な SQL Server の識別子であり、WSFC クラスター内のすべての可用性グループ間で一意である必要があります。

AUTOMATED_BACKUP_PREFERENCE = { PRIMARY |SECONDARY_ONLY|SECONDARY |NONE }

バックアップを実行する場所を選択するときに、バックアップ ジョブがプライマリ レプリカを評価する方法に関する基本設定を指定します。 自動バックアップの優先設定を考慮して、特定のバックアップ ジョブのスクリプトを作成できます。 優先順位は SQL Server によって適用されるものではないので、アドホック バックアップには影響がないことを理解しておくことが重要です。

プライマリ レプリカでのみサポートされます。

値は次のとおりです。

原発

バックアップが常にプライマリ レプリカで実行されることを指定します。 このオプションは、セカンダリ レプリカでバックアップを実行するときにサポートされない差分バックアップの作成などのバックアップ機能が必要な場合に便利です。

重要

ログ配布を使用して可用性グループのセカンダリ データベースを準備する場合は、すべてのセカンダリ データベースが準備されて可用性グループに参加するまで、自動バックアップ優先設定を Primary に設定します。

SECONDARY_ONLY

プライマリ レプリカでバックアップが実行されないように指定します。 プライマリ レプリカがオンラインの唯一のレプリカである場合、バックアップは行われません。

付帯

プライマリ レプリカがオンラインの唯一のレプリカである場合を除き、セカンダリ レプリカでバックアップを実行することを指定します。 その場合、バックアップはプライマリ レプリカで行われます。 これは既定の動作です。

なし

バックアップを実行するレプリカを選択するときにバックアップ ジョブが可用性レプリカのロールを無視するように指定します。 バックアップ ジョブは、動作状態および接続状態と組み合わせて、各可用性レプリカのバックアップ優先順位などの他の要素を評価する場合があります。

重要

AUTOMATED_BACKUP_PREFERENCE設定は適用されません。 この基本設定の解釈は、特定の可用性グループ内のデータベースのバックアップ ジョブにスクリプトを作成するロジック (存在する場合) によって異なります。 自動バックアップ設定は、アドホック バックアップには影響しません。 詳細については、「 Always On 可用性グループのセカンダリ レプリカでのバックアップの構成」を参照してください。

注意

既存の可用性グループの自動バックアップ設定を表示するには、sys.availability_groups カタログ ビューのautomated_backup_preferenceまたはautomated_backup_preference_desc列を選択します。 さらに、 sys.fn_hadr_backup_is_preferred_replica を使用して、優先バックアップ レプリカを決定できます。 この関数は、AUTOMATED_BACKUP_PREFERENCE = NONE場合でも、少なくとも 1 つのレプリカに対して常に1を返します。

FAILURE_CONDITION_LEVEL = { 1 | 2 | 3 | 4 | 5 }

この可用性グループの自動フェールオーバーをトリガーするエラー状態を指定します。 FAILURE_CONDITION_LEVEL はグループ レベルで設定されますが、同期コミット可用性モード (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT) 用に構成されている可用性レプリカにのみ関連します。 さらに、障害状態では、プライマリ レプリカとセカンダリ レプリカの両方が自動フェールオーバー モード (FAILOVER_MODE = AUTOMATIC) 用に構成されており、セカンダリ レプリカが現在プライマリ レプリカと同期されている場合にのみ、自動フェールオーバーをトリガーできます。

プライマリ レプリカでのみサポートされます。

エラー状態レベルの範囲は 1 ～ 5 で、レベル 1 が最も制限が緩く、レベル 5 が最も制限の厳しい指定です。 任意の状態レベルは、それより制限が緩いすべてのレベルを含みます。 したがって、最も厳しい状態レベル 5 にはそれより制限が緩い状態レベル (1 から 4) が含まれ、レベル 4 にはレベル 1 から 3 が含まれます。以下同様です。 次の表では、各レベルに対応するエラー状態について説明します。

レベル エラー状態
1 次のいずれかが発生したときに自動フェールオーバーを開始することを指定します。

SQL Server サービスがダウンした。

WSFC クラスターに接続するための可用性グループのリースは、サーバー インスタンスから ACK を受け取っていないため、期限切れになります。 詳細については、「How It Works:SQL Server Always On Lease Timeout」 (動作方法: SQL Server Always On のリース タイムアウト) を参照してください。
2 次のいずれかが発生したときに自動フェールオーバーを開始することを指定します。

SQL Server のインスタンスがクラスターに接続せず、可用性グループのユーザー指定の HEALTH_CHECK_TIMEOUT しきい値を超えています。

可用性レプリカがエラー状態である。
3 孤立したスピンロック、重大な書き込みアクセス違反、ダンプの量が多すぎるなど、重大な SQL Server 内部エラーで自動フェールオーバーが開始されることを指定します。

これは既定の動作です。
4 SQL Server 内部リソース プールの永続的なメモリ不足状態など、中程度の SQL Server 内部エラーで自動フェールオーバーが開始されるように指定します。
5 次のような、修飾された障害状態で自動フェールオーバーが開始されることを指定します。

SQL エンジンのワーカー スレッドが枯渇している。

解決不可能なデッドロックが検出された。

注意

SQL Server のインスタンスによるクライアント要求への応答の欠如は、可用性グループには関係ありません。

FAILURE_CONDITION_LEVEL値とHEALTH_CHECK_TIMEOUT値は、特定のグループの柔軟なフェールオーバー ポリシーを定義します。 この柔軟なフェールオーバー ポリシーを使用すると、自動フェールオーバーを引き起こす条件をきめ細かく制御できます。 詳細については、「 Always On 可用性グループの柔軟な自動フェールオーバー ポリシーを構成する」を参照してください。

HEALTH_CHECK_TIMEOUT = ミリ秒

WSFC クラスターがサーバー インスタンスが低速であるか応答していないと見なす前に、 sp_server_diagnostics システム ストアド プロシージャがサーバー正常性情報を返す待機時間をミリ秒単位で指定します。 HEALTH_CHECK_TIMEOUTグループ レベルで設定しますが、これは、自動フェールオーバー (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT) を使用して同期コミット可用性モード用に構成した可用性レプリカにのみ関連します。 さらに、正常性チェック タイムアウトは、プライマリ レプリカとセカンダリ レプリカの両方が自動フェールオーバー モード (FAILOVER_MODE = AUTOMATIC) 用に構成されており、セカンダリ レプリカが現在プライマリ レプリカと同期されている場合にのみ、自動フェールオーバーをトリガーできます。

既定の HEALTH_CHECK_TIMEOUT 値は 30,000 ミリ秒 (30 秒) です。 最小値は 15,000 ミリ秒 (15 秒) で、最大値は 4,294,967,295 ミリ秒です。

プライマリ レプリカでのみサポートされます。

重要

sp_server_diagnostics では、データベース レベルで正常性チェックが実行されません。

DB_FAILOVER = { ON |オフ }

プライマリ レプリカ上のデータベースがオフラインのときに実行する応答を指定します。 ONに設定すると、可用性グループ内のデータベースのONLINE以外の状態が発生すると、自動フェールオーバーがトリガーされます。 このオプションを OFF に設定すると、インスタンスの正常性のみが自動フェールオーバーをトリガーします。

この設定の詳細については、「 可用性グループ データベース レベルの正常性検出フェールオーバー オプション」を参照してください。

DTC_SUPPORT = { PER_DB |NONE }

この可用性グループに対して分散トランザクションを有効にするかどうかを指定します。 分散トランザクションは SQL Server 2016 (13.x) 以降の可用性グループ データベースに対してのみサポートされ、複数データベースにまたがるトランザクションは SQL Server 2016 (13.x) SP2 以降に対してのみサポートされます。 PER_DB は、これらのトランザクションをサポートする可用性グループを作成し、可用性グループ内のデータベースを含むデータベース間トランザクションを分散トランザクションに自動的に昇格させます。 NONE は、分散トランザクションへのデータベース間トランザクションの自動昇格を防ぎ、DTC の安定した RMID にデータベースを登録しません。 分散トランザクションは、 NONE 設定を使用しても防止されませんが、状況によってはデータベースのフェールオーバーと自動復旧が成功しない可能性があります。 詳細については、「 トランザクション - 可用性グループとデータベース ミラーリング」を参照してください。

注意

可用性グループの DTC_SUPPORT 設定の変更のサポートは、SQL Server 2016 (13.x) Service Pack 2 で導入されました。 このオプションは、以前のバージョンでは使用できません。 以前のバージョンの SQL Server でこの設定を変更するには、可用性グループをもう一度 DROP して CREATE する必要があります。

重要

DTC では、分散トランザクションあたりの登録は 32 に制限されています。 可用性グループ内の各データベースは個別に DTC に参加するため、トランザクションに 32 を超えるデータベースが含まれている場合、SQL Server が 33 番目のデータベースに参加しようとすると、次のエラーが発生する可能性があります。

Enlist operation failed: 0x8004d101(XACT_E_TOOMANY_ENLISTMENTS). SQL Server could not register with Microsoft Distributed Transaction Coordinator (MS DTC) as a resource manager for this transaction. The transaction may have been stopped by the client or the resource manager.

SQL Server での分散トランザクションの詳細については、「 分散トランザクション」を参照してください。

REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT

SQL Server 2017 (14.x) で導入されています。 コミットに必要な同期セカンダリ レプリカの最小数を設定します。この数を超えると、プライマリ レプリカがトランザクションをコミットします。 SQL Server トランザクションは、セカンダリ レプリカの最小数の最新情報がトランザクション ログに与えられるまで待機することになります。

  • 既定値は0。 SQL Server 2016 (13.x) と同じ動作になります。
  • 最小値: 0。
  • 最大値: レプリカ数から 1 を引いた数。

REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT は同期コミット モードのレプリカに関連します。 レプリカが同期コミット モードのとき、同期レプリカに対する書き込みがレプリカ データベース トランザクション ログにコミットされるまで、プライマリ レプリカへの書き込みは待機します。 セカンダリ同期レプリカをホストする SQL Server が応答を停止すると、プライマリ レプリカをホストする SQL Server はそのセカンダリ レプリカを NOT SYNCHRONIZED としてマークし、続行します。 応答しないデータベースがオンラインに戻ると、データベースは "同期されていません" 状態になり、プライマリが再び同期できるようになるまでレプリカは異常としてマークされます。 この設定により、レプリカの最小数が各トランザクションをコミットするまで、プライマリ レプリカは続行されません。 レプリカの最小数が使用できない場合、プライマリでのコミットは失敗します。 クラスター タイプ EXTERNAL の場合、可用性グループがクラスター リソースに追加されると、設定が変更されます。 「可用性グループの構成の高可用性とデータの保護」を参照してください。

SQL Server 2022 (16.x) 以降では、分散型可用性グループに REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT を設定できます。 この設定は、 CREATE AVAILABILITY GROUPではサポートされていません。 ALTER AVAILABILITY GROUPを使用してREQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMITを設定できます。 次に例を示します。

ALTER AVAILABILITY GROUP [<name>]
  SET (REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = <integer>);

役割

有効なパラメーターは SECONDARYのみであり、この SET オプションは分散型可用性グループでのみ有効です。 これを使用して 、分散型可用性グループをフェールオーバーします。

CLUSTER_CONNECTION_OPTIONS

対象:SQL Server 2025(17.x)以降のバージョン

CLUSTER_CONNECTION_OPTIONS句を使用して、Windows Server フェールオーバー クラスターと可用性グループレプリカ間の通信に TLS 1.3 暗号化を適用します。 キーと値のペアの一覧として、セミコロンで区切ってオプションを指定します。 キーと値のペアを使用して、可用性グループの接続文字列の暗号化を構成します。

既定の暗号化に戻すには、 CLUSTER_CONNECTION_OPTIONS 句を空の文字列に設定します。 SQL Server 2025(17.x)は、可用性グループのレプリカやリスナーへの接続がデフォルトで Encrypt=Mandatoryと TrustServerCertificate=Yes されています。

詳細については、厳密な暗号化と TDS 8.0 を使用した可用性グループへの接続を確認してください。

次の表では、 CLUSTER_CONNECTION_OPTIONS 句で使用できるキーと値のペアについて説明します。

Key サポートされている値 Description
Encrypt Mandatory、 Strict、 Optional 可用性グループへの暗号化を適用する方法を指定します。 サーバーが暗号化をサポートしていない場合、接続は失敗します。 暗号化を Mandatory に設定する場合は、 TrustServerCertificate を yes に設定する必要があります。 暗号化を Strict に設定すると、 TrustServerCertificate は無視されます。

注: このキー値ペアは必須です。
HostNameInCertificate レプリカ名または AG リスナー名 暗号化に使用される証明書のレプリカ名または可用性グループ リスナー名を指定します。 この値は、証明書の サブジェクトの別名 の値と一致する必要があります。 サーバー名が証明書に一覧表示されている場合は、 HostNameInCertificate キーと値のペアを省略できます。 サーバー名が証明書に一覧表示されていない場合は、 HostNameInCertificate キーと値のペアをサーバー名と共に指定する必要があります。

注: このキー値のペアは省略可能です。
TrustServerCertificate Yes、No ドライバーがサーバーの TLS/SSL 証明書を検証しないことを指定するには、 yes に設定します。 no場合、ドライバーは証明書を検証します。 詳細については、 TDS 8.0 を参照してください。

注: このキー値のペアは省略可能です。
ServerCertificate 証明書へのパス HostNameInCertificateを使用しない場合は、証明書へのパスを渡すことができます。 クラスター サービス アカウントには、指定された場所から証明書を読み取るアクセス許可が必要です。

注: このキー値のペアは省略可能です。
CLUSTER_CONNECTION_OPTIONS 空の文字列 ('') 既存の構成をクリアし、 Encrypt=Mandatory と TrustServerCertificate=Yesの既定の暗号化設定に戻します。

句CLUSTER_CONNECTION_OPTIONS使用方法については、例を確認してください。

データベースdatabase_nameの追加

可用性グループに追加する 1 つ以上のユーザー データベースのリストを指定します。 これらのデータベースは、現在のプライマリ レプリカをホストする SQL Server インスタンス上にある必要があります。 1 つの可用性グループに対して複数のデータベースを指定できますが、各データベースが所属できる可用性グループは 1 つだけです。 可用性グループがサポートできるデータベースの種類については、「Always On 可用性グループの 前提条件、制限事項、および推奨事項」を参照してください。 可用性グループに既に属しているローカル データベースを確認するには、sys.databases カタログ ビューの replica_id 列を参照してください。

プライマリ レプリカでのみサポートされます。

注意

可用性グループを作成したら、セカンダリ レプリカをホストする各サーバー インスタンスに接続する必要があります。 次に、各セカンダリ データベースを準備し、可用性グループに参加させます。 詳細については、「AlwaysOn セカンダリ データベース上のデータ移動の開始 (SQL Server)」を参照してください。

データベースdatabase_nameの削除

指定したプライマリ データベースと、対応するセカンダリ データベースを可用性グループから削除します。 プライマリ レプリカでのみサポートされます。

可用性グループから可用性データベースを削除した後の推奨される手順については、「 Always On 可用性グループからプライマリ データベースを削除する」を参照してください。

レプリカを追加

可用性グループのセカンダリ レプリカをホストする 1 ～ 8 個の SQL Server インスタンスを指定します。 各レプリカは、そのサーバー インスタンス アドレスの後に WITH (...) 句が続いて指定されます。

プライマリ レプリカでのみサポートされます。

すべての新しいセカンダリ レプリカを可用性グループに参加させる必要があります。 詳細については、このセクションで後述する JOIN オプションの説明を参照してください。

<server_instance>

レプリカのホストである SQL Server のインスタンスのアドレスを指定します。 アドレスの形式は、インスタンスが既定のインスタンスか名前付きインスタンスか、スタンドアロン インスタンスかフェールオーバー クラスター インスタンス (FCI) かによって異なります。 構文は次のとおりです。

{ 'system_name[\instance_name]' |'FCI_network_name[\instance_name]' }

このアドレスの構成要素は次のとおりです。

system_name

SQL Server のターゲット インスタンスが存在するコンピューター システムの NetBIOS 名。 このコンピューターは WSFC ノードである必要があります。

FCI_network_name

SQL Server フェールオーバー クラスターへのアクセスに使用するネットワーク名。 サーバー インスタンスが SQL Server フェールオーバー パートナーとして参加する場合は、この名前を使用します。 FCI サーバー インスタンスで SELECT @@SERVERNAME を実行すると、'FCI_network_name[\instance_name]' 文字列全体 (完全なレプリカ名) が返されます。

詳細については、 @@SERVERNAMEを参照してください。

instance_name

ホストをsystem_nameまたはFCI_network_nameし、Always On が有効になっている SQL Server のインスタンスの名前。 既定のサーバー インスタンスの場合、 instance_name は省略可能です。 インスタンス名では大文字と小文字が区別されません。 スタンドアロン サーバー インスタンスでは、この値の名前は、 SELECT @@SERVERNAMEを実行して返される値と同じです。

\

system_nameまたはFCI_network_nameから分離するために、instance_nameを指定する場合にのみ使用される区切り記号。

WSFC ノードとサーバー インスタンスの前提条件については、「 Always On 可用性グループの前提条件、制限事項、および推奨事項」を参照してください。

ENDPOINT_URL = '*TCP:// system-address:*port'

追加または変更する可用性レプリカをホストする SQL Server のインスタンス上の データベース ミラーリング エンドポイント の URL パスを指定します。

ENDPOINT_URL は ADD REPLICA ON 句では必須であり、 MODIFY REPLICA ON 句では省略可能です。 詳細については、「 エンドポイント URL の指定 - 可用性レプリカの追加または変更」を参照してください。

'TCP:// system-address:port'

エンドポイントの URL または読み取り専用ルーティングの URL を指定するための URL を指定します。 URL のパラメーターは次のとおりです。

system-address

システム名、完全修飾ドメイン名、IP アドレスなど、対象のコンピューター システムを明確に識別する文字列。

ポート

サーバー インスタンスのミラーリング エンドポイントに関連付けられているポート番号 ( ENDPOINT_URL オプションの場合) またはサーバー インスタンスのデータベース エンジンで使用されるポート番号 ( READ_ONLY_ROUTING_URL オプションの場合)。

AVAILABILITY_MODE = { SYNCHRONOUS_COMMIT |ASYNCHRONOUS_COMMIT |CONFIGURATION_ONLY }

プライマリ レプリカが特定のプライマリ データベースでトランザクションをコミットする前に、セカンダリ レプリカがログ レコードのディスクへの書き込みを確認するまで待機するかどうかを指定します。 同じプライマリ レプリカに対する異なるデータベースでのトランザクションは個別にコミットできます。

SYNCHRONOUS_COMMIT

プライマリ レプリカがこのセカンダリ レプリカ (同期コミット モード) で強化されるまで、トランザクションのコミットを待機することを指定します。 プライマリ レプリカを含め、最大 3 つのレプリカに対して SYNCHRONOUS_COMMIT を指定できます。

ASYNCHRONOUS_COMMIT

このセカンダリ レプリカでログが書き込まれるのを待たずに、プライマリ レプリカによってトランザクションがコミットされるよう指定します (同期コミット可用性モード)。 プライマリ レプリカを含め、最大 5 つの可用性レプリカに対して ASYNCHRONOUS_COMMIT を指定できます。

CONFIGURATION_ONLY

プライマリ レプリカがこのレプリカの master データベースに可用性グループ構成メタデータを同期的にコミットすることを指定します。 レプリカにはユーザー データが含まれません。 このオプションの特徴:

  • Express Edition など、SQL Server のあらゆるエディションでホストできます。

  • CONFIGURATION_ONLY レプリカのデータ ミラーリング エンドポイントがWITNESS型である必要があります。

  • 変更できません。

  • CLUSTER_TYPE = WSFCする場合は無効です。

    詳細については、「可用性グループ構成の高可用性とデータ保護」をご覧ください。

AVAILABILITY_MODE は ADD REPLICA ON 句では必須であり、 MODIFY REPLICA ON 句では省略可能です。 詳細については、「Always On 可用性グループの可用性モードの違い」を参照してください。

FAILOVER_MODE = { 自動 |マニュアル }

定義する可用性レプリカのフェールオーバー モードを指定します。

自動

自動フェールオーバーを有効にします。 AUTOMATIC は、 AVAILABILITY_MODE = SYNCHRONOUS_COMMITも指定した場合にのみサポートされます。 プライマリ レプリカを含む 3 つの可用性レプリカの AUTOMATIC を指定できます。

注意

  • SQL Server 2016 (13.x) より前は、プライマリ レプリカを含む 2 つの自動フェールオーバー レプリカに制限されています。
  • SQL Server フェールオーバー クラスター インスタンス (FCI) は可用性グループによる自動フェールオーバーをサポートしないため、FCI ホストが手動フェールオーバー用にのみ構成できる可用性レプリカ。

手動

データベース管理者による手動フェールオーバーまたは強制手動フェールオーバー (強制フェールオーバー) を有効にします。

ADD REPLICA ON句でFAILOVER_MODEを指定する必要があります。 必要に応じて、 MODIFY REPLICA ON 句で指定できます。 手動フェールオーバーには、データ損失のない手動フェールオーバーと強制フェールオーバー (データ損失の可能性あり) の 2 種類があります。 これらの型は、さまざまな条件でサポートされます。 詳しくは、「フェールオーバーとフェールオーバー モード (Always On 可用性グループ)」をご覧ください。

SEEDING_MODE = { 自動 |マニュアル }

セカンダリ レプリカの初回シード処理方法を指定します。

自動

直接シード処理を有効にします。 この方法では、ネットワーク上でセカンダリ レプリカがシード処理されます。 この方法では、レプリカ上のプライマリ データベースのコピーをバックアップおよび復元する必要はありません。

注意

直接シード処理を行うには、GRANT CREATE ANY DATABASE オプションを使用してALTER AVAILABILITY GROUPを呼び出して、各セカンダリ レプリカでのデータベースの作成を許可する必要があります。

手動

手動シード処理を指定します (既定)。 この方法では、プライマリ レプリカでデータベースのバックアップを作成し、セカンダリ レプリカでそのバックアップを手動で復元する必要があります。

BACKUP_PRIORITY = n

同じ可用性グループ内の他のレプリカと比較して、このレプリカでバックアップを実行する優先順位を指定します。 値は 0 ～ 100 の範囲の整数です。 これらの値には次の意味があります。

  • 1..100 は、バックアップを実行するために可用性レプリカを選択できることを示します。 1 は最も低い優先順位を示し、100 は最も高い優先順位を示します。 BACKUP_PRIORITY = 1場合、可用性レプリカは、現在使用可能な優先順位の高い可用性レプリカがない場合にのみ、バックアップを実行するために選択されます。

  • 0 は、バックアップを実行するためにこの可用性レプリカが選択されないことを示します。 このオプションは、たとえば、バックアップをフェールオーバーしないリモート可用性レプリカに役立ちます。

詳細については、「可用性グループのセカンダリ レプリカにサポートされているバックアップをオフロードする」を参照してください。

SECONDARY_ROLE ( ...)

この可用性レプリカが現在セカンダリ ロールを所有している場合に有効なロール固有の設定を指定します (セカンダリ レプリカの場合)。 かっこの中では、いずれか一方または両方のセカンダリ ロール オプションを指定します。 両方を指定する場合は、コンマ区切りのリストを使用します。

セカンダリ ロール オプションは次のとおりです。

ALLOW_CONNECTIONS = { NO |READ_ONLY |すべて }

(セカンダリ レプリカとして機能する) セカンダリ ロールを実行している特定の可用性レプリカのデータベースが、次のいずれかのクライアントからの接続を受け入れるかどうかを指定します。

いいえ

このレプリカのセカンダリ データベースに対するユーザー接続は禁止されます。 読み取りアクセスには使用できません。 これは既定の動作です。

読み取り専用

Application Intent プロパティが ReadOnly に設定されているセカンダリ レプリカ内のデータベースへの接続のみが許可されます。 このプロパティの詳細については、「 Using Connection String Keywords with SQL Server Native Client」を参照してください。

全て

読み取り専用アクセスに限り、セカンダリ レプリカのデータベースに対するすべての接続が許可されます。

詳細については、「Always On 可用性グループのセカンダリ レプリカに読み取り専用の負荷を移す」を参照してください。

READ_ONLY_ROUTING_URL = { '*TCP:// system-address:*port' |NONE }

読み取りインテント接続要求をこの可用性レプリカにルーティングするために使用する URL を指定します。 この URL は、SQL Server データベース エンジンがリッスンする場所です。 通常、SQL Server データベース エンジンの既定のインスタンスは、TCP ポート 1433 でリッスンします。

SQL Server 2025(17.x)以降は、 NONE を READ_ONLY_ROUTING_URL 目的地として指定し、可用性レプリカの指定された読み取り専用ルーティングを元に戻し、デフォルトの動作に基づいてトラフィックをルーティングできます。

名前付きインスタンスの場合は、sys.dm_tcp_listener_states動的管理ビューのport列とtype_desc列に対してクエリを実行して、ポート番号を取得します。 サーバー インスタンスは、Transact-SQL リスナー (type_desc='TSQL') を使用します。

可用性レプリカの読み取り専用ルーティングの URL の計算の詳細については、「AlwaysOn の read_only_routing_url の計算」を参照してください。

注意

SQL Server の名前付きインスタンスの場合は、特定のポートを使用するように Transact-SQL リスナーを構成します。 詳しくは、「特定の TCP ポートでリッスンするように SQL Server を構成する」を参照してください。

PRIMARY_ROLE ( ...)

この可用性レプリカが現在プライマリ ロールを所有している場合に有効なロール固有の設定を指定します (プライマリ レプリカの場合)。 かっこの中では、いずれか一方または両方のプライマリ ロール オプションを指定します。 両方を指定する場合は、コンマ区切りのリストを使用します。

プライマリ ロール オプションは次のとおりです。

ALLOW_CONNECTIONS = { READ_WRITE |すべて }

(プライマリ レプリカとして機能する) プライマリ ロールを実行している特定の可用性レプリカのデータベースがクライアントから受け入れることができる接続の種類を指定します。次のいずれかです。

読み書き

Application Intent 接続プロパティが ReadOnly に設定されている接続は許可されません。 Application Intent プロパティが ReadWrite に設定されている場合、または Application Intent 接続プロパティが設定されていない場合、接続は許可されます。 "アプリケーションの目的" 接続プロパティの詳細については、「 Using Connection String Keywords with SQL Server Native Client」を参照してください。

全て

プライマリ レプリカのデータベースに対するすべての接続が許可されます。 これは既定の動作です。

READ_ONLY_ROUTING_LIST = { ('<server_instance>' [ , ...n ] ) |NONE }

セカンダリ ロールの下で実行するときに次の要件を満たす、この可用性グループの可用性レプリカをホストするサーバー インスタンスのコンマ区切りリストを指定します。

  • すべての接続または読み取り専用接続を許可するように構成する (この記事で前述した SECONDARY_ROLE オプションのALLOW_CONNECTIONS引数を参照)。

  • 読み取り専用ルーティング URL を定義します (この記事で前述したSECONDARY_ROLE オプションのREAD_ONLY_ROUTING_URL引数を参照してください)。

READ_ONLY_ROUTING_LIST値は次のとおりです。

<server_instance>

セカンダリ ロールで実行しているときに読み取り可能なセカンダリ レプリカである可用性レプリカのホストである SQL Server のインスタンスのアドレスを指定します。

読み取り可能なセカンダリ レプリカをホストする可能性があるすべてのサーバー インスタンスを指定するには、コンマ区切りのリストを使用します。 読み取り専用のルーティングは、リストで指定されているサーバー インスタンスの順序に従います。 レプリカの読み取り専用ルーティング リストにレプリカのホスト サーバー インスタンスを含める場合、通常は一覧の最後にこのサーバー インスタンスを配置することをお勧めします。読み取りを目的とした接続が使用できる場合に、これがセカンダリ レプリカに移動するためです。

SQL Server 2016 (13.x) 以降では、読み取り可能なセカンダリ レプリカ間で読み取りを目的とした要求の負荷を分散することができます。 読み取り専用ルーティング リスト内のかっこの入れ子になったセットにレプリカを配置することで、これを指定します。 詳細と例については、「読み取り専用レプリカ間の負荷分散の構成」を参照してください。

なし

この可用性レプリカがプライマリ レプリカの場合、読み取り専用ルーティングがサポートされないように指定します。 これは既定の動作です。 MODIFY REPLICA ONと共に使用する場合、この値は既存のリスト (存在する場合) を無効にします。

{ READ_WRITE_ROUTING_URL = '*TCP:// system-address:*port' |NONE }

適用対象: SQL Server 2019 (15.x) 以降のバージョン

プライマリ ロールの下で実行するときに次の要件を満たす、この可用性グループの可用性レプリカをホストするサーバー インスタンスを指定します。

  • レプリカ スペック PRIMARY_ROLE には、 READ_WRITE_ROUTING_URLが含まれています。
  • 接続文字列は ReadWrite です (ApplicationIntent を ReadWrite として定義するか、ApplicationIntent を設定せずに既定値 (ReadWrite) を有効にします)。

SQL Server 2025(17.x)以降は、 NONE を READ_WRITE_ROUTING_URL 宛先として指定し、可用性レプリカの指定された読み書きルーティングをリバートし、デフォルトの動作に基づいてトラフィックをルーティングできます。

詳しくは、「セカンダリからプライマリ レプリカへの読み取り/書き込み接続のリダイレクト (Always On 可用性グループ)」をご覧ください。

SESSION_TIMEOUT = 秒

セッション タイムアウト期間を秒単位で指定します。 このオプションを指定しない場合、既定の期間は 10 秒です。 最小値は 5 秒です。

重要

タイムアウト期間は 10 秒以上にしてください。

セッション タイムアウト期間の詳細については、「Always On 可用性グループとは」を参照してください。

レプリカの変更オン

可用性グループの任意のレプリカを変更します。 変更するレプリカの一覧には、各レプリカのサーバー インスタンス アドレスと WITH (...) 句が含まれています。

プライマリ レプリカでのみサポートされます。

レプリカの削除がオン

指定したセカンダリ レプリカを可用性グループから削除します。 可用性グループから現在のプライマリ レプリカを削除することはできません。 レプリカを削除すると、データの受信が停止します。 レプリカのセカンダリ データベースは可用性グループから削除され、 RESTORING 状態になります。

プライマリ レプリカでのみサポートされます。

注意

使用できないか失敗している間にレプリカを削除すると、オンラインに戻ると、可用性グループに属しなくなったことが検出されます。

参加する

ローカル サーバー インスタンスにより、指定した可用性グループ内のセカンダリ レプリカがホストされるようになります。

可用性グループにまだ参加していないセカンダリ レプリカでのみサポートされます。

詳細については、「 Always On 可用性グループへのセカンダリ レプリカの参加」を参照してください。

フェールオーバー

接続先のセカンダリ レプリカへのデータ損失なしで、可用性グループの手動フェールオーバーを開始します。 プライマリ レプリカをホストするレプリカが フェールオーバー ターゲットです。 フェールオーバー ターゲットはプライマリ ロールを引き継ぎ、各データベースのコピーを復旧し、新しいプライマリ データベースとしてオンラインにします。 元のプライマリ レプリカは同時にセカンダリ ロールに移行し、そのデータベースがセカンダリ データベースになって、直ちに中断されます。 これらのロールは、一連の障害によって前後に切り替わる可能性があります。

フェールオーバーは、現在プライマリ レプリカと同期されている同期コミット セカンダリ レプリカでのみサポートされます。 セカンダリ レプリカを同期するには、プライマリ レプリカも同期コミット モードで実行されている必要があります。

可用性グループ内の 2 つの SQL Server インスタンスの場合、プライマリ レプリカまたはセカンダリ レプリカで failover コマンドを発行できます。 Managed Instance リンクを介してレプリケートされたインスタンスの場合は、プライマリ レプリカでフェールオーバー コマンドを発行する必要があります。

注意

  • 可用性グループの場合、フェールオーバー ターゲットがコマンドを受け入れるとすぐにフェールオーバー コマンドが返されます。 ただし、可用性グループのフェールオーバーが完了した後、データベースの復旧は非同期的に行われます。
  • Managed Instance リンク フェールオーバーの場合、フェールオーバー コマンドは、ソースとターゲットのスイッチロールが正常にフェールオーバーされた後、またはフェールオーバーの前提条件チェックが失敗した後にフェールオーバー コマンドが失敗した場合に戻ります。
  • 2 つの SQL Server インスタンス間の 分散型可用性グループ の計画されたフェールオーバーには、フェールオーバー コマンドを使用できません。

計画的な手動フェールオーバーを実行するための制限事項、前提条件、および推奨事項については、「 Always On 可用性グループ (SQL Server) の計画された手動フェールオーバーの実行」を参照してください。

FORCE_FAILOVER_ALLOW_DATA_LOSS

注意事項

データが失われる可能性があるため、ディザスター リカバリー対策として強制フェールオーバーのみを開始します。 強制フェールオーバーは、プライマリ レプリカが使用できない場合にのみ実行し、データ損失の可能性を受け入れる準備が整い、サービスをすぐに可用性グループに復元する必要があります。

ロールが SECONDARY または RESOLVING 状態のレプリカでのみサポートされます。 フェールオーバー コマンドを入力するレプリカが フェールオーバー ターゲットです。

フェールオーバー ターゲットへの可用性グループのフェールオーバーを強制します (データ損失の可能性あり)。 フェールオーバー ターゲットはプライマリ ロールを引き継ぎ、各データベースのコピーを復旧し、新しいプライマリ データベースとしてオンラインにします。 残りのセカンダリ レプリカのすべてのセカンダリ データベースは手動で再開するまで中断されます。 以前のプライマリ レプリカが使用可能になると、セカンダリ ロールに切り替えられ、そのデータベースはセカンダリ データベースが中断されます。

Managed Instance リンクを介してレプリケートされたインスタンスの場合は、セカンダリ レプリカ (フェールオーバー ターゲット) で FORCE_FAILOVER_ALLOW_DATA_LOSS コマンドを発行する必要があります。

注意

フェールオーバー ターゲットがコマンドを受け入れるとすぐに、フェールオーバー コマンドが返されます。 ただし、可用性グループのフェールオーバーが完了した後、データベースの復旧は非同期的に行われます。

フェールオーバーを強制するための制限事項、前提条件、推奨事項、および可用性グループ内の以前のプライマリ データベースに対する強制フェールオーバーの影響については、「 Always On 可用性グループ (SQL Server) の強制手動フェールオーバーの実行」を参照してください。

ADD LISTENER 'dns_name' ( <add_listener_option> )

この可用性グループの新しい可用性グループ リスナーを定義します。 プライマリ レプリカでのみサポートされます。

重要

最初のリスナーを作成する前に、「 Always On 可用性グループのリスナーを構成する」を参照してください。

特定の可用性グループのリスナーを作成したら、次の手順を実行します。

  • リスナーの IP アドレスが排他的に使用されるように確保することを、ネットワーク管理者に依頼します。
  • この可用性グループへのクライアント接続を要求するときの接続文字列で使用できるよう、リスナーの DNS ホスト名をアプリケーション開発者に通知します。

dns_name

可用性グループ リスナーの DNS ホスト名を指定します。 リスナーの DNS 名が、ドメインおよび NetBIOS 内で一意である必要があります。

dns_name は文字列値です。 この名前には、英数字、ダッシュ (-)、およびハイフン (_) のみを任意の順序で含めることができます。 DNS ホスト名では大文字と小文字は区別されません。 最大長は 63 文字です。

意味のある文字列を指定します。 たとえば、可用性グループの名前が AG1の場合は、 ag1-listenerのような意味のある DNS ホスト名にします。

重要

NetBIOS は、 dns_name内の最初の 15 文字のみを認識します。 同じ Active Directory によって制御される 2 つの WSFC クラスターがあり、15 文字を超える名前と同じ 15 文字のプレフィックスを持つ名前を使用して両方のクラスターに可用性グループ リスナーを作成しようとすると、仮想ネットワーク名リソースをオンラインにできないことを報告するエラーが表示されます。 DNS 名のプレフィックスに対する名前付け規則の詳細については、「 ドメイン名を割り当てる」を参照してください。

可用性グループへの参加

分散可用性グループに参加します。 分散型可用性グループを作成すると、作成するクラスター上の可用性グループがプライマリ可用性グループになります。 分散可用性グループに参加する可用性グループがセカンダリ可用性グループになります。

<ag_name>

分散可用性グループの半分を占める可用性グループの名前を指定します。

LISTENER = '*TCP:// system-address:*port'

可用性グループに関連付けられているリスナーの URL パスを指定します。

LISTENER句が必要です。

'*TCP:// system-address:*port'

可用性グループに関連付けられているリスナーの URL を指定します。 URL のパラメーターは次のとおりです。

system-address

リスナーを明確に識別する文字列 (システム名、完全修飾ドメイン名、IP アドレスなど)。

ポート

可用性グループのミラーリング エンドポイントに関連付けられているポート番号。 これはリスナーのポートではありません。

AVAILABILITY_MODE = { SYNCHRONOUS_COMMIT |ASYNCHRONOUS_COMMIT }

プライマリ レプリカが特定のプライマリ データベースでトランザクションをコミットできるようになる前に、セカンダリ可用性グループがログ レコードのディスクへの書き込みを確認するまで、プライマリ レプリカが待機するかどうかを指定します。

SYNCHRONOUS_COMMIT

プライマリ レプリカがトランザクションのコミットを待機し、セカンダリ可用性グループでトランザクションが強化されたことを確認します。 プライマリ可用性グループを含め、最大 2 つの可用性グループに対して SYNCHRONOUS_COMMIT を指定できます。

ASYNCHRONOUS_COMMIT

このセカンダリ可用性グループがログを書き込むのを待たず、プライマリ レプリカがトランザクションをコミットするように指定します。 プライマリ可用性グループを含め、最大 2 つの可用性グループに対して ASYNCHRONOUS_COMMIT を指定できます。

AVAILABILITY_MODE句が必要です。

FAILOVER_MODE = { マニュアル }

分散型可用性グループのフェールオーバー モードを指定します。

手動

データベース管理者による計画的な手動フェールオーバーまたは強制手動フェールオーバー (通常は強制フェールオーバーと呼ばれる) を有効にします。

セカンダリ可用性グループへの自動フェールオーバーはサポートされていません。

SEEDING_MODE = { 自動 |マニュアル }

セカンダリ可用性グループの初回シード処理方法を指定します。

自動

自動シード処理を有効にします。 この方法では、ネットワーク上でセカンダリ可用性グループがシード処理されます。 この方法では、セカンダリ可用性グループのレプリカでプライマリ データベースのコピーをバックアップおよび復元する必要はありません。

手動

手動シード処理を指定します。 この方法では、プライマリ レプリカにデータベースのバックアップを作成し、セカンダリ可用性グループのレプリカでそのバックアップを手動で復元する必要があります。

可用性グループの変更

分散可用性グループの可用性グループ設定を変更します。 変更する可用性グループの一覧には、可用性グループ名と、各可用性グループの WITH (...) 句が含まれています。

重要

このコマンドは、プライマリ可用性グループインスタンスとセカンダリ可用性グループ インスタンスの両方で実行する必要があります。

GRANT 任意のデータベースの作成

可用性グループがプライマリ レプリカに代わってデータベースを作成することを許可します。これは、直接シード処理 (SEEDING_MODE = AUTOMATIC) をサポートします。 このパラメーターは、そのセカンダリが可用性グループに参加した後に直接シード処理をサポートするすべてのセカンダリ レプリカで実行します。 CREATE ANY DATABASE アクセス許可が必要です。

データベースの作成を拒否する

プライマリ レプリカの代わりにデータベースを作成する可用性グループの機能を削除します。

<add_listener_option>

ADD LISTENER は、次のいずれかのオプションを使用します。

DHCP付き [ on { ('four_part_ipv4_address','four_part_ipv4_mask') } ]

可用性グループ リスナーが動的ホスト構成プロトコル (DHCP) を使用することを指定します。 必要に応じて、 ON 句を使用して、このリスナーが作成されるネットワークを識別します。 DHCP は、可用性グループ内の可用性レプリカをホストするすべてのサーバー インスタンスに使用される 1 つのサブネットに制限されます。

重要

DHCP は、運用環境では使用しないでください。 ダウンタイムが発生し、DHCP IP リースの有効期限が切れた場合は、リスナーの DNS 名に関連付けられている新しい DHCP ネットワーク IP アドレスを登録し、クライアント接続に影響を与える余分な時間が必要です。 ただし、開発環境とテスト環境を設定して可用性グループの基本機能を確認する場合や、アプリケーションとの統合の場合には DHCP が適しています。

次に例を示します。

WITH DHCP ON ('10.120.19.0','255.255.254.0')

WITH IP ( { ('four_part_ipv4_address','four_part_ipv4_mask') |('ipv6_address') }[ , ...n ] ) [ , PORT = listener_port ]

可用性グループ リスナーは、DHCP を使用する代わりに、1 つ以上の静的 IP アドレスを使用します。 複数のサブネットにわたる可用性グループを作成するには、各サブネットのリスナー構成に静的 IP アドレスが 1 つ必要です。 サブネットの静的 IP アドレスには、IPv4 アドレスまたは IPv6 アドレスを使用できます。 新しい可用性グループの可用性レプリカをホストする各サブネットの静的 IP アドレスを取得するには、ネットワーク管理者に問い合わせてください。

次に例を示します。

WITH IP ( ('10.120.19.155','255.255.254.0') )

ipv4_address

可用性グループ リスナーの IPv4 4 部構成のアドレス。 たとえば、「 10.120.19.155 」のように入力します。

ipv4_mask

可用性グループ リスナーの IPv4 4 部構成マスク。 たとえば、「 255.255.254.0 」のように入力します。

ipv6_address

可用性グループ リスナーの IPv6 アドレス。 たとえば、「 2001::4898:23:1002:20f:1fff:feff:b3a3 」のように入力します。

ポート = listener_port

WITH IP句が指定する可用性グループ リスナーによって使用されるポート番号 (listener_port)。 PORT は省略可能です。

既定のポート番号 ( 1433) がサポートされています。 ただし、別のポート番号を選択することもできます。

例: WITH IP ( ('2001::4898:23:1002:20f:1fff:feff:b3a3') ) , PORT = 7777

MODIFY LISTENER 'dns_name' ( <modify_listener_option> )

この可用性グループに対する既存の可用性グループ リスナーを変更します。 プライマリ レプリカでのみサポートされます。

<modify_listener_option>

MODIFY LISTENER は、次のいずれかのオプションを使用します。

ADD IP { ('four_part_ipv4_address','four_part_ipv4_mask') |('ipv6_address') }

指定した IP アドレスを dns_name で指定されている可用性グループ リスナーに追加します。

ポート = listener_port

このセクションで既に説明したこの引数に関する説明を参照してください。

REMOVE IP { ('four_part_ipv4_address') |('ipv6_address') }

対象:SQL Server 2025(17.x)以降のバージョン

指定した可用性グループ リスナーから、指定した IP アドレスを削除します。

リスナー 'dns_name' を再起動する

指定した DNS 名に関連付けられているリスナーを再起動します。 プライマリ レプリカでのみサポートされます。

リスナー 'dns_name' を削除する

指定した DNS 名に関連付けられているリスナーを削除します。 プライマリ レプリカでのみサポートされます。

オフライン

オンラインの可用性グループをオフラインにする 同期コミット データベースのデータ損失はありません。

可用性グループがオフラインになると、そのデータベースはクライアントで使用できなくなり、可用性グループをオンラインに戻すことはできません。 そのため、可用性グループ リソースを新しい WSFC クラスターに移行する場合は、Always On 可用性グループのクラスター間移行中にのみ、 OFFLINE オプションを使用します。

詳細については、「可用性グループをオフラインにする (SQL Server)」を参照してください。

前提条件と制限

可用性レプリカとそのホスト サーバー インスタンスとコンピューターの前提条件と制限については、「 Always On 可用性グループの前提条件、制限事項、および推奨事項」を参照してください。

AVAILABILITY GROUP Transact-SQL ステートメントの制限については、Always On 可用性グループのTransact-SQL ステートメントを参照してください。

アクセス許可

可用性グループ、CONTROL AVAILABILITY GROUPアクセス許可、ALTER ANY AVAILABILITY GROUPアクセス許可、またはCONTROL SERVERアクセス許可に対するALTER AVAILABILITY GROUPアクセス許可が必要です。 また、 ALTER ANY DATABASE アクセス許可も必要です。

例

Ａ。 可用性グループへのセカンダリ レプリカの参加

次の例では、 AccountsAG 可用性グループに接続しているセカンダリ レプリカを結合します。

ALTER AVAILABILITY GROUP AccountsAG JOIN;
GO

B. 可用性グループの強制フェールオーバー

次の例では、 AccountsAG 可用性グループが、接続先のセカンダリ レプリカに強制的にフェールオーバーされます。

ALTER AVAILABILITY GROUP AccountsAG FORCE_FAILOVER_ALLOW_DATA_LOSS;
GO

C. 可用性グループへの接続で暗号化を強制する

このセクションの例では、AccountsAG可用性グループへの接続で暗号化を強制します。

いずれかの 方法で定義されている各証明書にサーバー名が表示される場合は、 HostNameInCertificate オプションを省略できます。

ALTER AVAILABILITY GROUP [AccountsAG]
   SET (
   CLUSTER_CONNECTION_OPTIONS = 'Encrypt=Strict')

方法 1 に従っても、証明書のサブジェクトの別名としてサーバー名を一覧表示しなかった場合は、HostNameInCertificate オプションの [サブジェクトの別名] に表示される値を指定する必要があります。

ALTER AVAILABILITY GROUP [AccountsAG]
   SET (
   CLUSTER_CONNECTION_OPTIONS = 'Encrypt=Strict;HostNameInCertificate=<Subject Alternative Name>')

メソッド 1 に従い、HostNameInCertificateの値を指定する代わりに ServerCertificate プロパティを使用する場合:

ALTER AVAILABILITY GROUP [AccountsAG]
   SET (
   CLUSTER_CONNECTION_OPTIONS = 'Encrypt=Strict;ServerCertificate=C:\Users\admin\SqlAGCertificate.cer')

関連コンテンツ

  • Last updated on