次の方法で共有

ALTER AVAILABILITY GROUP (Transact-SQL)

  • [アーティクル]

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

適用対象: SQL Server (SQL Server 2012 から現在のバージョンまで)

トピック リンク アイコン 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
   | 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 

<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 },
       FAILOVER_MODE = { AUTOMATIC | MANUAL }
       [ , <add_replica_option> [ ,...n ] ]
    ) 

  <add_replica_option>::=
       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 


<modify_replica_spec>::=
  <server_instance> WITH
    (  
       ENDPOINT_URL = 'TCP://system-address:port' 
     | AVAILABILITY_MODE = { SYNCHRONOUS_COMMIT | ASYNCHRONOUS_COMMIT } 
     | FAILOVER_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_listener_option> ::=
   {
      WITH DHCP [ ON ( <network_subnet_option> ) ]
    | WITH IP ( { ( <ip_address_option> ) } [ , ...n ] ) [ , PORT = listener_port ]
   }

  <network_subnet_option> ::=
     ‘four_part_ipv4_address’, ‘four_part_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 設定の適用はありません。この優先設定の解釈は、特定の可用性グループのデータベースに対するバックアップ ジョブのスクリプトでのロジックに依存します (ある場合)。自動バックアップ設定はアドホック バックアップには影響しません。詳細については、「可用性レプリカでのバックアップの構成 (SQLServer)」を参照してください。

    注意

    既存の可用性グループの自動バックアップ設定を確認するには、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 はグループ レベルで設定されますが、同期コミット可用性モードが構成されている (AVAILIBILITY_MODE = SYNCHRONOUS_COMMIT) 可用性レプリカにのみ適用されます。 さらに、エラー状態が自動フェールオーバーをトリガーできるのは、プライマリとセカンダリの両方のレプリカが自動フェールオーバー モードに構成されていて (FAILOVER_MODE = AUTOMATIC)、セカンダリ レプリカが現在プライマリ レプリカと同期されている場合だけです。

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

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

    レベル

    エラー状態

    1

    次のいずれかが発生した場合に自動フェールオーバーを開始する必要があることを指定します。

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

    • WSFC クラスターに接続するための可用性グループのリースが、サーバー インスタンスから ACK を受信しないために期限切れになった。 詳細については、「動作方法: SQL Server AlwaysOn のリースのタイムアウト」を参照してください。

    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 はグループ レベルで設定されますが、自動フェールオーバーで同期コミット可用性モードが構成されている (AVAILIBILITY_MODE = SYNCHRONOUS_COMMIT) 可用性レプリカにのみ適用されます。 さらに、正常性チェック タイムアウトが自動フェールオーバーをトリガーできるのは、プライマリとセカンダリの両方のレプリカが自動フェールオーバー モードに構成されていて (FAILOVER_MODE = AUTOMATIC)、セカンダリ レプリカが現在プライマリ レプリカと同期されている場合だけです。

    HEALTH_CHECK_TIMEOUT の既定値は 30000 ミリ秒 (30 秒) です。 最小値は 15000 ミリ秒 (15 秒)、最大値は 4294967295 ミリ秒です。

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

    重要

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

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

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

    注意

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

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

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

  • ADD REPLICA ON
    可用性グループのセカンダリ レプリカをホストする 1 ～ 4 個の 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 でホストされ、AlwaysOn が有効化されている SQL Server インスタンスの名前です。 既定のサーバー インスタンスの場合、instance_name は省略可能です。 インスタンス名では大文字と小文字が区別されません。 スタンドアロン サーバー インスタンスでは、この名前の値は SELECT @@SERVERNAME を実行したときに返される値と同じです。

    • \
      instance_name を指定するときに、system_name または FCI_network_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 }
    プライマリ レプリカが特定のプライマリ データベースでトランザクションをコミットする前に、セカンダリ レプリカによるディスクへのログ レコードの固定 (書き込み) の確認応答を待機する必要があるかどうかを指定します。 同じプライマリ レプリカに対する異なるデータベースでのトランザクションは個別にコミットできます。

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

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

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

  • FAILOVER_MODE = { AUTOMATIC | MANUAL }
    定義している可用性レプリカのフェールオーバー モードを指定します。

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

      注意

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

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

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

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

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

    • 0 は、その可用性レプリカがバックアップの実行に対して選択されないことを示します。 これは、たとえば、バックアップをフェールオーバーすることがないリモート可用性レプリカのような場合に便利です。

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

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

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

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

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

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

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

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

    • 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 の計算 を参照してください。

      注意

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

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

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

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

      • READ_WRITE
        Application Intent 接続プロパティが ReadOnly に設定されている接続は許可されません。 Application Intent プロパティが ReadWrite に設定されている場合、または Application Intent 接続プロパティが設定されていない場合は、接続が許可されます。 Application Intent 接続プロパティの詳細については、「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 のインスタンスのアドレスを指定します。

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

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

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

    重要

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

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

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

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

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

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

    注意

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

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

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

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

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

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

    注意

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

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

  • FORCE_FAILOVER_ALLOW_DATA_LOSS

    注意

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

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

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

    注意

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

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

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

  • <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') )

  • four_part_ipv4_address
    可用性グループ リスナーに対する IPv4 の 4 つの部分から成るアドレスを指定します。 たとえば、10.120.19.155 のようにします。

  • four_part_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 クラスターに移行するときに、クラスター間での AlwaysOn 可用性グループの移行中に限って使用してください。

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

[トップに戻る] リンクで使用される矢印アイコン[先頭に戻る]

前提条件と制限

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

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

セキュリティ

権限

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

使用例

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)

概念

AlwaysOn 可用性グループの構成のトラブルシューティング (SQL Server)

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

可用性グループ リスナー、クライアント接続、およびアプリケーションのフェールオーバー (SQL Server)