ALTER AVAILABILITY GROUP (Transact-SQL)

[アーティクル]
04/17/2023

適用対象: 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
  
<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 = { ( '<server_instance>' ) ] 
     } )  
     | 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'   
          } )  
     | PRIMARY_ROLE ( {   
          ALLOW_CONNECTIONS = { READ_WRITE | ALL }   
        | READ_ONLY_ROUTING_LIST = { ( '<server_instance>' [ ,...n ] ) | 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  
    }

引数

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

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

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

値は次のとおりです。

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

重要

ログ配布を使用して可用性グループのセカンダリデータベースを準備する場合は、すべてのセカンダリデータベースの準備が完了し、それらを可用性グループに参加させるまで、自動バックアップ設定を [プライマリ] に設定します。

SECONDARY_ONLY
バックアップをプライマリレプリカでは実行しないことを指定します。オンラインのレプリカがプライマリレプリカだけの場合、バックアップは実行されません。

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

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

重要

AUTOMATED_BACKUP_PREFERENCE 設定の適用はありません。この優先設定の解釈は、特定の可用性グループのデータベースに対するバックアップジョブのスクリプトでのロジックに依存します (ある場合)。自動バックアップ設定はアドホックバックアップには影響しません。詳細については、「可用性レプリカでのバックアップの構成 (SQL Server)」を参照してください。

注意

既存の可用性グループの自動バックアップ設定を確認するには、sys.availability_groups カタログビューの automated_backup_preference 列または automated_backup_preference_desc 列を選択します。さらに、sys.fn_hadr_backup_is_preferred_replica (Transact-SQL) を使用して、優先されるバックアップレプリカを決定することができます。 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 が含まれます。以下同様です。次の表では、各レベルに対応するエラー状態について説明します。

Level	エラー状態
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 値は、特定のグループに対する柔軟なフェールオーバーポリシーを定義します。この柔軟なフェールオーバーポリシーを使用すると、自動フェールオーバーを引き起こす条件をきめ細かく制御できます。詳細については、「可用性グループの自動フェールオーバーのための柔軟なフェールオーバーポリシー (SQL Server)」を参照してください。

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

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

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

重要

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

DB_FAILOVER = { ON | OFF }
プライマリレプリカ上のデータベースがオフラインのときに実行する応答を指定します。 ON に設定すると、可用性グループ内のデータベースがオンライン以外のすべての状態で、自動フェールオーバーがトリガーされます。このオプションが OFF に設定されている場合は、インスタンスの正常性だけが自動フェールオーバーのトリガーに使用されます。

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

DTC_SUPPORT = { PER_DB | NONE }
この可用性グループの分散トランザクションが有効かどうかを指定します。分散トランザクションは SQL Server 2016 (13.x) 以降の可用性グループデータベースに対してのみサポートされ、複数データベースにまたがるトランザクションは SQL Server 2016 (13.x) SP2 以降に対してのみサポートされます。 PER_DB では、これらのトランザクションをサポートする可用性グループが作成され、可用性グループ内のデータベースを含む複数データベースにまたがるトランザクションが分散トランザクションに自動的に昇格されます。 NONE では、複数データベースにまたがるトランザクションは分散トランザクションに自動昇格されず、データベースは DTC の安定した RMID に登録されません。 NONE の設定を使用しても分散トランザクションは妨げられませんが、状況によってはデータベースのフェールオーバーと自動復旧が失敗する場合があります。詳細については、Always On 可用性グループとデータベースミラーリングでのデータベース間のトランザクションと分散トランザクション (SQL Server) に関するページを参照してください。

Note

可用性グループの設定 DTC_SUPPORT の変更のサポートは、SQL Server 2016 (13.x) Service Pack 2 で導入されました。それより前のバージョンでは、このオプションは使用できません。 SQL Server の以前のバージョンでこの設定を変更するには、可用性グループをいったん削除してから、再度作成する必要があります。

重要

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 はそのセカンダリレプリカを同期未実行としてマークし、続行します。応答のないデータベースがオンラインに復帰すると、"未同期" 状態になります。プライマリが再度同期可能になるまで、レプリカに異常のマークが付きます。この設定により、レプリカの最小数で各トランザクションがコミットされるまで、プライマリレプリカは続行しません。レプリカの最小数が使用できない場合、プライマリのコミットは失敗します。クラスタータイプ 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>);

ROLE
有効なパラメーターは 'SECONDARY' のみです。この SET オプションは分散型可用性グループでのみ有効です。これは、ALTER AVAILABILITY GROUP に関する記事で説明されているように、分散型可用性グループをフェールオーバーするために使用されます。

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

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

Note

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

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

可用性グループから可用性データベースを削除した後の推奨するフォローアップの詳細については、「可用性グループからのプライマリデータベースの削除 (SQL Server)」を参照してください。

ADD REPLICA 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]' という文字列全体 (完全なレプリカ名) が返されます。

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

\
system_name または FCI_network_name と区別するために、instance_name を指定するときにのみ使用される区切り記号です。

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

ENDPOINT_URL ='TCP://system-address:port'
追加または変更している可用性レプリカをホストする SQL Server のインスタンス上のデータベースミラーリングエンドポイントの URL パスを指定します。

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

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

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

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

AVAILABILITY_MODE = { SYNCHRONOUS_COMMIT | ASYNCHRONOUS_COMMIT | CONFIGURATION_ONLY }
プライマリレプリカによって特定のプライマリデータベースでのトランザクションがコミットされる前に、セカンダリレプリカによるディスクへのログレコードの固定 (書き込み) の確認応答を待機する必要があるかどうかを指定します。同じプライマリレプリカに対する異なるデータベースでのトランザクションは個別にコミットできます。

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

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

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 | MANUAL }
定義している可用性レプリカのフェールオーバーモードを指定します。

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

Note

SQL Server 2016 より前は、プライマリレプリカを含めて 2 つの自動フェールオーバーレプリカに制限されていました

Note

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

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

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

SEEDING_MODE = { AUTOMATIC | MANUAL }
セカンダリレプリカの初回シード処理方法を指定します。

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

Note

直接シード処理の場合、セカンダリレプリカごとにデータベース作成を許可する必要があります。GRANT CREATE ANY DATABASE オプションを指定し、ALTER AVAILABILITY GROUP を呼び出してください。

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

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

1 から 100 は、その可用性レプリカがバックアップの実行に向けて選択される可能性があることを示します。 1 は最も低い優先順位を示し、100 は最も高い優先順位を示します。 BACKUP_PRIORITY = 1 の場合、現在使用可能な可用性レプリカにそれより高い優先順位のものがない場合にのみ、その可用性レプリカがバックアップの実行に向けて選択されます。
0 は、その可用性レプリカがバックアップの実行に対して選択されないことを示します。これは、たとえば、バックアップをフェールオーバーすることがないリモート可用性レプリカのような場合に便利です。

詳細については、「アクティブなセカンダリ: セカンダリレプリカでのバックアップ (Always On 可用性グループ)」を参照してください。

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

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

ALLOW_CONNECTIONS = { NO | READ_ONLY | ALL }
セカンダリロールを実行している (つまりセカンダリレプリカとして機能している) 特定の可用性レプリカのデータベースがクライアントから接続を受け入れることができるかどうかを指定します。以下のいずれかになります。

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

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

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

詳細については、「アクティブなセカンダリ: 読み取り可能なセカンダリレプリカ (Always On 可用性グループ)」を参照してください。

READ_ONLY_ROUTING_URL =' TCP ://system-address:port'
読み取りを目的とした接続要求をこの可用性レプリカにルーティングするために使用する URL を指定します。これは、SQL Server データベースエンジンがリッスンしている URL です。通常、SQL Server データベースエンジンの既定のインスタンスは、TCP ポート 1433 でリッスンします。

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

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

Note

SQL Server の名前付きインスタンスの場合は、特定のポートを使用するように Transact-SQL リスナーを構成する必要があります。詳細については、「特定の TCP ポートで受信待ちするようにサーバーを構成する方法 (SQL Server 構成マネージャー)」を参照してください。

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

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

ALLOW_CONNECTIONS = { READ_WRITE | ALL }
プライマリロールを実行している (つまりプライマリレプリカとして機能している) 特定の可用性レプリカのデータベースが受け入れることのできるクライアントからの接続の種類を指定します。以下のいずれかになります。

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

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

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

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

READ_WRITE_ROUTING_URL = { ('<server_instance>') }
適用対象:SQL Server (SQL Server 2019 (15.x) 以降)

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

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

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

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

重要

タイムアウト期間を 10 秒以上にしておくことをお勧めします。

セッションタイムアウト期間の詳細については、「AlwaysOn 可用性グループの概要 (SQL Server)」を参照してください。

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

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

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

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

Note

使用不可中または障害発生中のレプリカを削除した場合、オンラインに戻ったレプリカでは、可用性グループに属していないことが検出されます。

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

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

詳細については、可用性グループへのセカンダリレプリカの参加 (SQL Server) に関するページを参照してください。

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

現在プライマリレプリカと同期されている同期コミットモードのセカンダリレプリカでのみサポートされます。セカンダリレプリカを同期する場合、プライマリレプリカも同期コミット可用性モードで実行されている必要があります。

Note

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

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

FORCE_FAILOVER_ALLOW_DATA_LOSS

注意事項

データの損失を伴う可能性があるフェールオーバーの強制は、厳密にはディザスターリカバリー手段です。したがって、プライマリレプリカが動作しなくなった状況で、データの損失を許容でき、可用性グループに直ちにサービスを復元する必要がある場合のみ、強制フェールオーバーを実行することを強くお勧めします。

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

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

Note

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

ADD LISTENER 'dns_name'(<add_listener_option>)
この可用性グループの新しい可用性グループリスナーを定義します。プライマリレプリカでのみサポートされます。

重要

最初のリスナーを作成する前に、「可用性グループリスナーの作成または構成 (SQL Server)」をお読みになることを強くお勧めします。

可用性グループのリスナーを作成した後は、次のことを行うことを強くお勧めします。

リスナーの 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 名のプレフィックスに対する名前付け規則の詳細については、「ドメイン名を割り当てる」を参照してください。

JOIN AVAILABILITY GROUP ON
分散可用性グループに参加します。分散可用性グループを作成すると、それが作成されたクラスターの可用性グループがプライマリの可用性グループになります。分散可用性グループに参加する可用性グループがセカンダリ可用性グループになります。

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

LISTENER =' TCP ://system-address:port'
可用性グループに関連付けられているリスナーの URL パスを指定します。

LISTENER 句は必須です。

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

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

port
可用性グループのミラーリングエンドポイントに関連付けられているポート番号です。これはリスナーのポートではないことに注意してください。

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

SYNCHRONOUS_COMMIT
セカンダリ可用性グループでトランザクションが書き込まれるまで、プライマリはトランザクションのコミットを延期するように指定します。 SYNCHRONOUS_COMMIT は、プライマリ可用性グループを含む、最大 2 つの可用性グループに指定できます。

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

AVAILABILITY_MODE 句は必須です。

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

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

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

SEEDING_MODE**=** { AUTOMATIC | MANUAL }
セカンダリ可用性グループの初回シード処理方法を指定します。

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

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

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

重要

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

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

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

<add_listener_option>
ADD LISTENER には、次のいずれかのオプションを指定できます。

WITH DHCP [ ON { ('four_part_ipv4_address','four_part_ipv4_mask') } ]
可用性グループリスナーによって動的ホスト構成プロトコル (DHCP) が使用されるよう指定します。必要に応じて、ON 句を使用して、このリスナーを作成するネットワークを識別します。 DHCP は、可用性グループの可用性レプリカをホストする各サーバーインスタンスに使用される単一のサブネットに限定されます。

重要

運用環境での 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 」のように入力します。

PORT = 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') | ('dns_nameipv6_address') }
指定した IP アドレスを dns_name で指定されている可用性グループリスナーに追加します。

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

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

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

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

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

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

前提条件と制限

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

AVAILABILITY GROUP Transact-SQL ステートメントの制限については、「AlwaysOn 可用性グループの Transact-SQL ステートメントの概要 (SQL Server)」を参照してください。

セキュリティ

アクセス許可

可用性グループの ALTER AVAILABILITY GROUP 権限、CONTROL AVAILABILITY GROUP 権限、ALTER ANY AVAILABILITY GROUP 権限、または CONTROL SERVER 権限が必要です。 ALTER ANY DATABASE 権限も必要です。

例

A. セカンダリレプリカを可用性グループに参加させる

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

ALTER AVAILABILITY GROUP AccountsAG JOIN;  
GO

B. 可用性グループを強制的にフェールオーバーする

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

ALTER AVAILABILITY GROUP AccountsAG FORCE_FAILOVER_ALLOW_DATA_LOSS;  
GO

参照

CREATE AVAILABILITY GROUP (Transact-SQL)
ALTER DATABASE SET HADR (Transact-SQL)
DROP AVAILABILITY GROUP (Transact-SQL)
sys.availability_replicas (Transact-SQL)
sys.availability_groups (Transact-SQL)
Always On 可用性グループの構成のトラブルシューティング (SQL Server)
Always On 可用性グループの概要 (SQL Server)
可用性グループリスナー、クライアント接続、およびアプリケーションのフェールオーバー (SQL Server)

次の方法で共有

ALTER AVAILABILITY GROUP (Transact-SQL)

構文

引数

前提条件と制限

セキュリティ

アクセス許可

例

A. セカンダリレプリカを可用性グループに参加させる

B. 可用性グループを強制的にフェールオーバーする

参照

フィードバック

その他のリソース

次の方法で共有

ALTER AVAILABILITY GROUP (Transact-SQL)

構文

引数

前提条件と制限

セキュリティ

アクセス許可

例

A. セカンダリ レプリカを可用性グループに参加させる

B. 可用性グループを強制的にフェールオーバーする

参照

フィードバック

その他のリソース

A. セカンダリレプリカを可用性グループに参加させる