Always On 可用性グループの強制手動フェールオーバーの実行 (SQL Server)Perform a Forced Manual Failover of an Always On Availability Group (SQL Server)

適用対象: ○SQL Server XAzure SQL Database XAzure SQL Data Warehouse XParallel Data WarehouseAPPLIES TO: yesSQL Server noAzure SQL Database noAzure SQL Data Warehouse noParallel Data Warehouse

このトピックでは、 SQL Server Management StudioSQL Server Management StudioTransact-SQLTransact-SQL、または SQL Server 2017SQL Server 2017の PowerShell を使用して、AlwaysOn 可用性グループに対する強制フェールオーバー (データ損失の可能性あり) を実行する方法について説明します。This topic describes how to perform a forced failover (with possible data loss) on an Always On availability group by using SQL Server Management StudioSQL Server Management Studio, Transact-SQLTransact-SQL, or PowerShell in SQL Server 2017SQL Server 2017. 強制フェールオーバーは、計画的な手動フェールオーバーを実行できない場合に、ディザスター リカバリーのみを目的として実行する手動フェールオーバーです。A forced failover is a form of manual failover that is intended strictly for disaster recovery, when a planned manual failover is not possible. 非同期のセカンダリ レプリカに対して強制フェールオーバーを実行した場合、データ損失の可能性があります。If you force failover to an unsynchronized secondary replica, some data loss is possible. したがって、強制フェールオーバーは、データ損失のリスクを引き受けたうえで、可用性グループに対するサービスを直ちに復旧する必要がある場合のみ実行することを強くお勧めします。Therefore, we strongly recommend that you force failover only if you must restore service to the availability group immediately and you are willing to risk losing data.

強制フェールオーバーの実行後、可用性グループのフェールオーバー先であるフェールオーバー ターゲットが新しいプライマリ レプリカになります。After a forced failover, the failover target to which the availability group was failed over becomes the new primary replica. 残りのセカンダリ レプリカ内のセカンダリ データベースは中断され、手動で再開する必要があります。The secondary databases in the remaining secondary replicas are suspended and must be manually resumed. 元のプライマリ レプリカは、使用可能になったときにセカンダリ ロールに移行し、元のプライマリ データベースがセカンダリ データベースになり、SUSPENDED 状態に移行します。When the former primary replica becomes available, it transitions to the secondary role, causing the former primary databases to become secondary databases and transition into the SUSPENDED state. 特定のセカンダリ データベースを再開する前に、そのデータベースから失われたデータを復元できる場合があります。Before you resume a given secondary database, you might be able to recover lost data from it. ただし、プライマリ データベースでは、いずれかのセカンダリ データベースが中断している間、トランザクション ログの切り捨てが遅延されることに注意してください。However, notice that transaction log truncation is delayed on a given primary database while any of its secondary databases is suspended.

重要

セカンダリ データベースが再開されるまでは、プライマリ データベースとのデータ同期は実行されません。Data synchronization with the primary database will not occur until the secondary database is resumed. セカンダリ データベースの再開の詳細については、この記事の後半にある「補足情報: 強制フェールオーバー後の必須タスク」を参照してください。For information about resuming a secondary database, see Follow Up: Essential Tasks After a Forced Failover later in this article.

強制フェールオーバーは、次のような緊急事態が発生した場合に実行する必要があります。Performing a forced failover is necessary in the following emergency situations:

  • WSFC クラスターに対してクォーラムを強制した後 ("強制クォーラム")、各可用性グループに対して強制フェールオーバーを実行する必要があります (このとき、データ損失の可能性もあります)。After forcing quorum on the WSFC cluster (forced quorum), you need to force failover each availability group (with possible data loss). 強制フェールオーバーが必要なのは、WSFC クラスター値の実際の状態が失われている可能性があるためです。Forcing failover is required because the real state of the WSFC cluster values might have been lost. ただし、強制クォーラムを実行する前にプライマリ レプリカであったレプリカをホストしていたサーバー インスタンスで強制フェールオーバーを実行できる場合、または強制クォーラムを実行する前に同期されていたセカンダリ レプリカに対してフェールオーバーを実行できる場合は、データ損失を回避できます。However, you can avoid data loss, if are able to force failover on the server instance that was hosting the replica that was the primary replica before you forced quorum or to a secondary replica that was synchronized before you forced quorum. 詳細については、このトピックの「 クォーラム強制後のデータ損失を回避できる方法」を参照してください。For more information, see Potential Ways to Avoid Data Loss After Quorum is Forced, later in this topic.

    重要

    クォーラムが強制ではなく通常の方法で再取得される場合、可用性レプリカは通常の方法で復元されます。If quorum is regained by natural means instead of being forced, the availability replicas will go through normal recovery. クォーラムの再取得後にプライマリ レプリカがまだ使用できない場合は、同期セカンダリ レプリカに対して計画的な手動フェールオーバーを実行できます。If the primary replica is still unavailable after quorum is regained, you can perform a planned manual failover to a synchronized secondary replica.

    強制フォーラムの詳細については、「 WSFC の強制クォーラムによる災害復旧 (SQL Server)の PowerShell を使用して、AlwaysOn 可用性グループに対する強制フェールオーバー (データ損失の可能性あり) を実行する方法について説明します。For information about forcing quorum, see WSFC Disaster Recovery through Forced Quorum (SQL Server). 強制フォーラム後に強制フェールオーバーが必要な理由については、「 フェールオーバーとフェールオーバー モード (AlwaysOn 可用性グループ)の PowerShell を使用して、AlwaysOn 可用性グループに対する強制フェールオーバー (データ損失の可能性あり) を実行する方法について説明します。For information about why forcing failover is required after forcing quorum, see Failover and Failover Modes (Always On Availability Groups).

  • WSFC クラスターに正常なクォーラムがあるときにプライマリ レプリカが使用不能になった場合は、ロールが SECONDARY または RESOLVING 状態である任意のレプリカに、強制フェールオーバー (データ損失の可能性あり) を実行できます。If the primary replica becomes unavailable when the WSFC cluster has a healthy quorum, you can force failover (with possible data loss), to any replica whose role is in the SECONDARY or RESOLVING state. 可能であれば、プライマリ レプリカが失われたときに同期されていた、同期コミット セカンダリ レプリカへの強制フェールオーバーを実行します。If possible, force failover to a synchronous-commit secondary replica that was synchronized when the primary replica was lost.

    ヒント

    WSFC クラスターに正常なクォーラムがあるときに、同期セカンダリ レプリカで強制フェールオーバー コマンドを発行した場合、レプリカが実際に実行するのは、計画的な手動フェールオーバーです。When the WSFC cluster has a healthy quorum, if you issue a force failover command on a synchronized secondary replica, the replica actually performs a planned manual failover.

注意

フェールオーバーを強制する場合の前提条件と推奨事項の詳細、および強制フェールオーバーを使用して重大なエラーから復旧するシナリオの例については、この記事の後半にある「サンプル シナリオ: 重大なエラーから復旧するための強制フェールオーバーの使用」を参照してください。For more information about the prerequisites and recommendations for forcing failover and for an example scenario that uses a forced failover to recover from a catastrophic failure, see Example Scenario: Using a Forced Failover to Recover from a Catastrophic Failure, later in this topic.

制限事項と制約事項Limitations and Restrictions

  • 強制フェールオーバーは、Windows server フェールオーバー クラスタリング (WSFC) にクォーラムが存在しない場合のみ実行できません。The only time that you cannot perform a forced failover is when Windows Server Failover Clustering (WSFC) cluster lacks quorum.

  • 可用性グループの強制フェールオーバー中にはデータ損失の可能性があります。Data loss is possible during the forced failover of an availability group. さらに、強制フェールオーバーを開始したときにプライマリ レプリカが実行されている場合は、クライアントがまだ元のプライマリ データベースに接続している可能性があります。In addition, if the primary replica is running when you initiate a forced failover, clients might still be connected to former primary databases. したがって、プライマリ レプリカが動作しておらず、データ損失のリスクを許容できる場合にのみ、可用性グループのデータベースへのアクセスを復旧するために強制フェールオーバーを実行することを強くお勧めします。Therefore, we strongly recommend that you force failover only if the primary replica is no longer running and if you are willing to risk losing data in order to restore access to databases in the availability group.

  • セカンダリ データベースが REVERTING または INITIALIZING 状態の場合、強制フェールオーバーを実行すると、そのデータベースはプライマリ データベースとして起動できなくなります。When a secondary database in the REVERTING or INITIALIZING state, forcing failover would cause the database to fail to start as a primary database. データベースが INTIAILIZGING 状態だった場合は、欠落しているログ レコードをデータベース バックアップから適用するか、データベースを最初から完全に復元する必要があります。If the database was in the INTIAILIZGING state the you will need to apply the missing log records from a database backup or fully restore the database from scratch. データベースが REVERTING 状態だった場合は、データベースをバックアップから完全に復元する必要があります。If the database was in the REVERTING state you will need to fully restore the database from backups.

  • フェールオーバー コマンドは、フェールオーバー ターゲットがコマンドを受け入れた直後に戻ります。A failover command returns as soon as the failover target has accepted the command. ただし、データベースの復旧は、可用性グループがフェールオーバーを完了した後に非同期で行われます。However, database recovery occurs asynchronously after the availability group has finished failing over.

  • フェールオーバー時に、可用性グループ内のデータベース間の一貫性が維持されない場合があります。Cross-database consistency across databases within the availability group might not be maintained on failover.

    注意

    複数のデータベースにまたがるトランザクションと分散トランザクションのサポートは、SQL Server とオペレーティング システムのバージョンによって異なります。Support for cross-database and distributed transactions vary by SQL Server and operating system versions. 詳細については、「Always On 可用性グループとデータベース ミラーリングでの複数データベースにまたがるトランザクションと分散トランザクション (SQL Server)」を参照してください。For more information, see Cross-Database Transactions and Distributed Transactions for Always On Availability Groups and Database Mirroring (SQL Server).

前提条件Prerequisites

  • WSFC クラスターにクォーラムがあること。The WSFC cluster has quorum. クラスターにクォーラムが存在しない場合は、「 WSFC の強制クォーラムによる災害復旧 (SQL Server)の PowerShell を使用して、AlwaysOn 可用性グループに対する強制フェールオーバー (データ損失の可能性あり) を実行する方法について説明します。If the cluster lacks quorum, see WSFC Disaster Recovery through Forced Quorum (SQL Server).

  • ロールが SECONDARY または RESOLVING 状態であるレプリカをホストするサーバー インスタンスに接続できる必要があります。You must be able to connect to a server instance that hosts a replica whose role is in the SECONDARY or RESOLVING state.

推奨事項Recommendations

  • プライマリ レプリカが実行中である間は、強制フェールオーバーを実行しないでください。Do not force failover while the primary replica is still running.

  • 可能な場合は、セカンダリ データベースが NOT SYNCHRONIZED、SYNCHRONIZED、SYNCHRONIZING のいずれかの状態であるセカンダリ レプリカにのみ、強制フェールオーバーを実行します。If possible, force failover only to a failover target whose secondary databases are either in the NOT SYNCHRONIZED, SYNCHRONIZED, or SYNCHRONIZING state. セカンダリ データベースが INTIAILIZGING または REVERTING 状態の場合の強制フェールオーバーの影響については、このトピックの「 制限事項と制約事項」を参照してください。For information about the implications of forcing failover when a secondary database is in the INTIAILIZGING or REVERTING state, see Limitations and Restrictions, earlier in this topic.

  • 通常は、特定のセカンダリ データベースの待機時間は、プライマリ データベースに比べて、別の非同期コミット セカンダリ レプリカでも同じくらいになります。Typically, the latency of a given secondary database, relative to the primary database, should be similar on different asynchronous-commit secondary replicas. ただし、強制フェールオーバーを行う場合は、データ損失が重要な問題になります。However, when forcing failover, data loss can be a significant concern. そのため、異なるセカンダリ レプリカ上でのデータベースのコピーに関する相対的な待機時間を検討するようにしてください。Therefore, consider taking time to determine the relative latency of the copies of the databases on different secondary replicas. 特定のセカンダリ データベースのどのコピーが最小の待機時間かを判断するには、ログの最後の LSN を比較します。To determine which copy of a given secondary database has the least latency, compare their end-of-log LSNs. ログの最後の LSN の値が大きいほど、待機時間が小さいことを示します。A higher the end-of-log LSN indicates less latency.

    ヒント

    ログの最後の LSN の値を比較するには、それぞれのオンライン セカンダリ レプリカに接続し、 sys.dm_hadr_database_replica_states に対して各ローカル セカンダリ データベースの end_of_log_lsn 値を照会します。To compare end-of-log LSNs, connect to each online secondary replica, in turn, and query sys.dm_hadr_database_replica_states for the end_of_log_lsn value of each local secondary database. 次に、各データベースの異なるコピーで、ログの最後の LSN を比較します。Then, compare the end-of-log LSNs of the different copies of each database. データベースによって、LSN の値が最も大きいセカンダリ レプリカが異なる場合もあることに注意してください。Note that different databases might have their highest LSNs on different secondary replicas. この場合、最も適切なフェールオーバー ターゲットは、各データベース内のデータの相対的な重要度によって決まります。In this case, the most appropriate failover target depends on the relative importance that you place on the data in the different databases. つまり、どのデータベースでのデータ損失の可能性を最小限に抑えたいか、という問題になります。That is, for which of these databases would you most want to minimize possible data loss?

  • クライアントが元のプライマリに接続できる場合は、強制フェールオーバーによってスプリット ブレイン動作のリスクが発生します。If clients are able to connect to the original primary, a forced failover incurs some risk of split brain behavior. 強制フェールオーバーを実行する前に、クライアントが元のプライマリ レプリカにアクセスできないようにすることを強くお勧めします。Before you force failover, we strongly recommend that you prevent clients from accessing the original primary replica. そうしないと、強制フェールオーバーの実行後に元のプライマリ データベースと現在のプライマリ データベースがそれぞれ、他方とは無関係に更新されることがあります。Otherwise, after failover is forced, the original primary databases and the current primary databases could be updated independently of the other.

クォーラム強制後のデータ損失を回避できる方法Potential Ways to Avoid Data Loss After Quorum is Forced

クォーラムが失われた後のエラー状態中は、以下に示すように、データ損失を回避できます。Under some failure conditions after quorum is lost, you can avoid prevent data loss, as follows:

  • 元のプライマリ レプリカがオンラインになる場合If the original primary replica comes online

    クォーラムが失われ、WSFC クォーラムの強制によって可用性グループのプライマリ レプリカをホストするクラスター ノードが復元される場合は、その可用性グループのデータ損失を回避できます。If quorum is lost and forcing WSFC quorum restores the cluster node that hosts the primary replica of an availability group, you can prevent data loss for this availability group. プライマリ レプリカに接続し、強制フェールオーバー (FAILOVER_ALLOW_DATA_LOSS) を実行します。Connect to the primary replica and perform a forced failover (FAILOVER_ALLOW_DATA_LOSS). これにより、プライマリ レプリカがオンラインに戻ります。This brings the primary replica back online. 元のプライマリ レプリカへの強制フェールオーバーを実行するため、データ損失は起こりません。Because you perform the forced failover to the original primary replica, there is no data loss.

  • 同期コミット セカンダリ レプリカがオンラインになる場合If a synchronized synchronous-commit secondary replica comes online

    クォーラムが失われ、WSFC クォーラムの強制によって可用性グループの同期セカンダリ レプリカをホストするクラスター ノードが復元される場合は、その可用性グループのデータ損失を回避できます。If quorum is lost and forcing WSFC quorum restores a cluster node that hosts a synchronized secondary replica for an availability group, you should be able to prevent data loss for this availability group. 復元されるノードが、クォーラムの消失時に起動していた場合は、 sys.dm_hadr_database_replica_cluster_states 動的管理ビューの is_failover_ready 列を照会することで、特定のデータベースでデータ損失が発生した可能性があるかどうかを確認できます。If the restored node was up at the time that quorum was lost, you can determine whether data loss could occur on a given database by querying the is_failover_ready column of the sys.dm_hadr_database_replica_cluster_states dynamic management view. たとえば、 sql108w2k8r22という名前のサーバー インスタンスに対して、次のクエリを発行します。For example, for a server instance named sql108w2k8r22, issue the following query:

    SELECT * FROM sys.dm_hadr_database_replica_cluster_states  
       WHERE replica_id=(SELECT replica_id FROM sys.availability_replicas   
          WHERE replica_server_name ='sql108w2k8r22')  
    

    注意事項

    復元されるノードがクォーラムの消失時に起動していなかった場合、 is_failover_ready は、プライマリ レプリカがオフラインになった時点のクラスターの実際の状態を反映していない可能性があります。If the restored node was not up at the time quorum was lost, is_failover_ready may not reflect the cluster's actual state at the time the primary replica went offline. したがって、 is_failover_ready 値は、エラー発生時のホスト ノードにのみ有効です。Therefore, the is_failover_ready value is only good if the host node at the time of the failure. 詳細については、「 フェールオーバーとフェールオーバー モード (AlwaysOn 可用性グループ)の PowerShell を使用して、AlwaysOn 可用性グループに対する強制フェールオーバー (データ損失の可能性あり) を実行する方法について説明します。For more information, see "Why Forced Failover is Required After Forcing Quorum" in Failover and Failover Modes (Always On Availability Groups).

    is_failover_ready = 1 の場合、データベースはクラスター内で同期済みとマークされ、フェールオーバーの準備ができています。If is_failover_ready = 1, the database is marked as synchronized in the cluster and is ready for a failover. 特定のセカンダリ レプリカのすべてのデータベースで is_failover_ready = 1 の場合は、そのセカンダリ レプリカに対して、データ損失なしで強制フェールオーバー (FORCE_FAILOVER_ALLOW_DATA_LOSS) を実行できます。If is_failover_ready = 1 on every database on a given secondary replica, you can perform a forced failover (FORCE_FAILOVER_ALLOW_DATA_LOSS) without data loss on this secondary replica. 同期セカンダリ レプリカは、すべてのデータを保持したまま、新しいプライマリ レプリカとしてプライマリ ロールでオンラインになります。The synchronized secondary replica comes online in the primary role, that is, as the new primary replica, with all the data intact.

    is_failover_ready = 0 の場合、データベースはクラスター内で同期済みとマークされておらず、計画的な手動フェールオーバーの準備が "できていません"If is_failover_ready = 0, the database is not marked as synchronized in the cluster and is not ready for a planned manual failover. ホスト セカンダリ レプリカに対して強制フェールオーバーを実行した場合、そのデータベースのデータは失われます。If you force failover to the host secondary replica, data will be lost on this database.

    注意

    セカンダリ レプリカに対して強制フェールオーバーを実行する場合、データ損失の量は、フェールオーバー ターゲットがどの程度プライマリ レプリカより遅れているかによって決まります。When you force failover to a secondary replica, the amount of data loss will depend on how far the failover target is lagging behind the primary replica. 残念ながら、WSFC クラスターにクォーラムが存在しない、またはクォーラムが強制されている場合は、失われる可能性があるデータの量を評価できません。Unfortunately, when the WSFC cluster lacks quorum or quorum has been forced, you cannot assess the amount of potential data loss. ただし、WSFC クラスターが正常なクォーラムを再取得した後、データ損失の可能性を追跡できます。Note, however, that once the WSFC cluster regains a healthy quorum, you could begin to track potential data loss. 詳細については、「 フェールオーバーとフェールオーバー モード (AlwaysOn 可用性グループ)の PowerShell を使用して、AlwaysOn 可用性グループに対する強制フェールオーバー (データ損失の可能性あり) を実行する方法について説明します。For more information, see "Tracking Potential Data Loss" in Failover and Failover Modes (Always On Availability Groups).

PermissionsPermissions

可用性グループの ALTER AVAILABILITY GROUP 権限、CONTROL AVAILABILITY GROUP 権限、ALTER ANY AVAILABILITY GROUP 権限、または CONTROL SERVER 権限が必要です。Requires ALTER AVAILABILITY GROUP permission on the availability group, CONTROL AVAILABILITY GROUP permission, ALTER ANY AVAILABILITY GROUP permission, or CONTROL SERVER permission.

SQL Server Management Studio の使用Using SQL Server Management Studio

強制フェールオーバー (データ損失の可能性あり) を実行するにはTo force failover (with possible data loss)

  1. オブジェクト エクスプローラーで、フェールオーバーを行う必要がある可用性グループでロールが SECONDARY または RESOLVING 状態であるレプリカをホストするサーバー インスタンスに接続し、サーバー ツリーを展開します。In Object Explorer, connect to a server instance that hosts a replica whose role is in the SECONDARY or RESOLVING state in the availability group that needs to be failed over, and expand the server tree.

  2. [AlwaysOn 高可用性] ノードと [可用性グループ] ノードを展開します。Expand the Always On High Availability node and the Availability Groups node.

  3. フェールオーバーする [可用性グループ] ノードを右クリックし、 [フェールオーバー] を選択します。Right-click the availability group to be failed over, and select the Failover command.

  4. 可用性グループのフェールオーバー ウィザードが起動します。This launches the Failover Availability Group Wizard. 詳細については、このトピックの「 可用性グループのフェールオーバー ウィザードの使用 (SQL Server Management Studio)の PowerShell を使用して、AlwaysOn 可用性グループに対する強制フェールオーバー (データ損失の可能性あり) を実行する方法について説明します。For more information, see Use the Fail Over Availability Group Wizard (SQL Server Management Studio).

  5. 可用性グループを強制的にフェールオーバーした後で、必要なフォローアップ手順を実行します。After forcing an availability group to fail over, complete the necessary follow-up steps. 詳細については、このトピックで後述する「補足情報:強制フェールオーバー後の必須タスク」を参照してください。For more information, see Follow Up: Essential Tasks After a Forced Failover, later in this topic.

Transact-SQL の使用Using Transact-SQL

強制フェールオーバー (データ損失の可能性あり) を実行するにはTo force failover (with possible data loss)

  1. フェールオーバーを行う必要がある可用性グループでロールが SECONDARY または RESOLVING 状態であるレプリカをホストするサーバー インスタンスに接続し、サーバー ツリーを展開します。Connect to a server instance that hosts a replica whose role is in the SECONDARY or RESOLVING state in the availability group that needs to be failed over.

  2. ALTER AVAILABILITY GROUP ステートメントを使用します。次にその例を示します。Use the ALTER AVAILABILITY GROUP statement, as follows:

    ALTER AVAILABILITY GROUP group_name FORCE_FAILOVER_ALLOW_DATA_LOSSALTER AVAILABILITY GROUP group_name FORCE_FAILOVER_ALLOW_DATA_LOSS

    group_name は可用性グループの名前です。where group_name is the name of the availability group.

    次の例では、 AccountsAG 可用性グループのローカル セカンダリ レプリカへのフェールオーバーを強制的に実行します。The following example forces the AccountsAG availability group to fail over to the local secondary replica.

    ALTER AVAILABILITY GROUP AccountsAG FORCE_FAILOVER_ALLOW_DATA_LOSS;  
    
  3. 可用性グループを強制的にフェールオーバーした後で、必要なフォローアップ手順を実行します。After forcing an availability group to fail over, complete the necessary follow-up steps. 詳細については、このトピックで後述する「補足情報:強制フェールオーバー後の必須タスク」を参照してください。For more information, see Follow Up: Essential Tasks After a Forced Failover, later in this topic.

PowerShell の使用Using PowerShell

強制フェールオーバー (データ損失の可能性あり) を実行するにはTo force failover (with possible data loss)

  1. フェールオーバーを行う必要がある可用性グループでロールが SECONDARY または RESOLVING 状態であるレプリカをホストするサーバー インスタンスにディレクトリを変更 (cd) します。Change directory (cd) to a server instance that hosts a replica whose role is in the SECONDARY or RESOLVING state in the availability group that needs to be failed over.

  2. 次のいずれかの形式で AllowDataLoss パラメーターを指定して、 Switch-SqlAvailabilityGroup コマンドレットを使用します。Use the Switch-SqlAvailabilityGroup cmdlet with the AllowDataLoss parameter in one of the following forms:

    • -AllowDataLoss-AllowDataLoss

      既定では、 Switch-SqlAvailabilityGroup-AllowDataLoss パラメーターを指定した場合、強制フェールオーバーを実行するとコミットされていないトランザクションが失われる可能性があることが通知され、操作を続行するかどうかの確認を求められます。By default -AllowDataLoss parameter causes Switch-SqlAvailabilityGroup to prompt you to remind you that forcing failover might result in the loss of uncommitted transactions and to request confirmation. 続けるには「 Y」を入力し、操作をキャンセルするには「 N」を入力します。To continue, enter Y; to cancel the operation, enter N.

      次の例では、可用性グループ MyAg に対して、 SecondaryServer\InstanceNameというサーバー インスタンスのセカンダリ レプリカへの強制フェールオーバー (データ損失の可能性あり) が実行されます。The following example performs a forced failover (with possible data loss) of the availability group MyAg to the secondary replica on the server instance named SecondaryServer\InstanceName. この操作の確認を求めるメッセージが表示されます。You will be prompted to confirm this operation.

      Switch-SqlAvailabilityGroup `  
         -Path SQLSERVER:\Sql\SecondaryServer\InstanceName\AvailabilityGroups\MyAg `  
         -AllowDataLoss  
      
    • -AllowDataLoss-Force-AllowDataLoss-Force

      確認を求めずに強制フェールオーバーを実行するには、 -AllowDataLoss パラメーターと -Force パラメーターを両方とも指定します。To initiate a forced failover without confirmation, specify both the -AllowDataLoss and -Force parameters. これは、コマンドをスクリプトに組み込んで自動的に実行する場合に役立ちます。This is useful if you want to include the command in a script and run it without user interaction. ただし、強制フェールオーバーによって可用性グループに参加しているデータベースでデータ損失が発生する可能性があるため、 -Force オプションは慎重に使用する必要があります。However, use the -Force option with caution, because a forced failover might result in the loss of data from databases participating the availability group.

      次の例では、可用性グループ MyAg に対して、 SecondaryServer\InstanceNameというサーバー インスタンスへの強制フェールオーバー (データ損失の可能性あり) が実行されます。The following example performs a forced failover (with possible data loss) of the availability group MyAg to the server instance named SecondaryServer\InstanceName. -Force オプションにより、この操作の確認は表示されません。The -Force option suppresses confirmation of this operation.

      Switch-SqlAvailabilityGroup `  
         -Path SQLSERVER:\Sql\SecondaryServer\InstanceName\AvailabilityGroups\MyAg `  
         -AllowDataLoss -Force  
      

    注意

    コマンドレットの構文を表示するには、 PowerShell 環境で Get-Help SQL ServerSQL Server コマンドレットを使用します。To view the syntax of a cmdlet, use the Get-Help cmdlet in the SQL ServerSQL Server PowerShell environment. 詳細については、「 Get Help SQL Server PowerShell」を参照してください。For more information, see Get Help SQL Server PowerShell.

  3. 可用性グループを強制的にフェールオーバーした後で、必要なフォローアップ手順を実行します。After forcing an availability group to fail over, complete the necessary follow-up steps. 詳細については、このトピックで後述する「補足情報:強制フェールオーバー後の必須タスク」を参照してください。For more information, see Follow Up: Essential Tasks After a Forced Failover, later in this topic.

SQL Server PowerShell プロバイダーを設定して使用するにはTo set up and use the SQL Server PowerShell provider

補足情報:強制フェールオーバー後の必須タスクFollow Up: Essential Tasks After a Forced Failover

  1. 強制フェールオーバーの後で、フェールオーバー先のセカンダリ レプリカが新しいプライマリ レプリカになります。After a forced failover, the secondary replica to which you failed over becomes the new primary replica. ただし、この可用性レプリカにクライアントからアクセスできるようにするには、WSFC クォーラムの再構成または可用性グループの可用性モード構成の調整が必要な場合があります。次の手順を実行してください。However, to make that availability replica accessible to clients, you might need to reconfigure the WSFC quorum or adjust the availability-mode configuration of the availability group, as follows:

    • 自動フェールオーバー セットautomatic failover set の外側でフェールオーバーした場合: WSFC ノードのクォーラム投票を調整して新しい可用性グループの構成を反映します。If you failed over outside of the 自動フェールオーバー セットautomatic failover set: Adjust the quorum votes of the WSFC nodes to reflect your new availability group configuration. 対象のセカンダリ レプリカがホストされている WSFC ノードに WSFC クォーラム投票がない場合、強制的に WSFC クォーラムを適用することが必要な場合があります。If the WSFC node that hosts the target secondary replica does not have a WSFC quorum vote, you might need to force WSFC quorum.

      注意

      自動フェールオーバー セットautomatic failover set は、2 つの可用性レプリカ (元のプライマリ レプリカを含む) に、自動フェールオーバーが指定され、同期コミット モードが構成されている場合のみ存在します。An 自動フェールオーバー セットautomatic failover set exists only if two availability replicas (including the previous primary replica) are configured for synchronous-commit mode with automatic failover.

      クォーラム投票を調整するには:To adjust quorum votes

    • 同期コミット フェールオーバー セットsynchronous-commit failover set の外側でフェールオーバーした場合: 新しいプライマリ レプリカおよび残りのセカンダリ レプリカで、可用性モードとフェールオーバー モードを調整して、目的の同期コミット構成および自動フェールオーバー構成にすることをお勧めします。If you failed over outside of the 同期コミット フェールオーバー セットsynchronous-commit failover set: We recommend that you consider adjusting the availability mode and failover mode on the new primary replica and on remaining secondary replicas to reflect your desired synchronous-commit and automatic failover configuration.

      注意

      同期コミット フェールオーバー セットsynchronous-commit failover set は、現在のプライマリ レプリカに同期コミット モードが構成されている場合にのみ存在します。A 同期コミット フェールオーバー セットsynchronous-commit failover set exists only if the current primary replica is configured for synchronous-commit mode.

      可用性モードとフェールオーバー モードを変更するにはTo change the availability mode and failover mode

  2. 強制フェールオーバー後は、すべてのセカンダリ データベースが中断されます。After a forced failover, all secondary databases are suspended. これには、元のプライマリ データベースも含まれます (元のプライマリ レプリカは、オンラインに戻った後でセカンダリ レプリカになります)。This includes the former primary databases, after the former primary replica comes back online and discovers that it is now a secondary replica. 各セカンダリ レプリカで、中断されたデータベースをそれぞれ手動で再開する必要があります。You must manually resume each suspended database individually on each secondary replica.

    セカンダリ データベースは、再開時に、対応するプライマリ データベースとのデータ同期を開始します。When a secondary database is resumed, it initiates data synchronization with the corresponding primary database. 新しいプライマリ データベースで 1 回もコミットされなかったログ レコードは、すべてロールバックされます。The secondary database rolls back any log records that were never committed on the new primary database. そのため、フェールオーバー後のプライマリ データベースでデータ損失の可能性が懸念される場合は、同期コミットのセカンダリ データベースの 1 つで、中断されたデータベースにデータベース スナップショットの作成を試みる必要があります。Therefore, if you are concerned about possible data loss on the post-failover primary databases, you should attempt to create a database snapshot on the suspended databases on one of the synchronous-commit secondary databases.

    重要

    プライマリ データベースでは、いずれかのセカンダリ データベースが中断している間は、トランザクション ログの切り捨てが遅延されます。Transaction log truncation is delayed on a primary database while any of its secondary databases is suspended. また、同期コミット セカンダリ レプリカの同期状態は、いずれかのローカル データベースが中断している間は、HEALTHY に移行できません。Also the synchronization health of a synchronous-commit secondary replica cannot transition to HEALTHY as long as any local database remains suspended.

    データベース スナップショットを作成するにはTo create a database snapshot

    可用性データベースを再開するにはTo resume an availability database

    注意事項

    すべてのセカンダリ データベースを再開した後で、グループのフェールオーバーを再度試行する前に、次のフェールオーバー ターゲットのすべてのセカンダリ データベースが SYNCHRONIZING 状態になるまで待機します。After resuming all the secondary databases, before attempting to fail over the group again, wait for every secondary database on the next failover target to enter the SYNCHRONIZING state. どのデータベースもまだ SYNCHRONIZING 状態ではない場合、データベースをプライマリ データベースとしてオンラインにすることができません。また、データベースへのデータ同期を再確立するには、トランザクション ログの復元、データベース バックアップ全体の復元、または元のプライマリ レプリカへのフェールオーバーが必要となる場合があります。If any database is not yet SYNCHRONIZING, that database will be prevented from coming online as a primary database, and re-establishing data synchronization for the database might require restoring transaction logs, restoring a full database backup, or failing over back to the previous primary replica.

  3. 停止した可用性レプリカがその可用性レプリカに戻らないか、戻るのが遅すぎて新しいプライマリ データベースでのトランザクション ログの切り捨てを遅延できない場合、停止したレプリカを可用性グループから削除してログ ファイル用のディスク領域の不足を回避することを検討してください。If an availability replica that failed will not be returning to the availability replica or will return too late for you to delay transaction log truncation on the new primary database, consider removing the failed replica from the availability group to avoid running out of disk space for your log files.

    セカンダリ レプリカを削除するにはTo remove a secondary replica

  4. 強制フェールオーバー後、さらに追加で強制フェールオーバーを 1 回以上実行すると、連続する追加の強制フェールオーバーごとにログ バックアップが実行されます。If you follow a forced failover with one or more additional forced failovers, perform a log backup after each additional forced failover in the series. この理由については、「 フェールオーバーとフェールオーバー モード (AlwaysOn 可用性グループ)の PowerShell を使用して、AlwaysOn 可用性グループに対する強制フェールオーバー (データ損失の可能性あり) を実行する方法について説明します。For information about the reason for this, see "Risks of Forcing Failover" in the "Forced Manual Failover (with Possible Data Loss)" section of Failover and Failover Modes (Always On Availability Groups).

    ログ バックアップを実行するにはTo perform a log backup

サンプル シナリオ:重大なエラーから復旧するための強制フェールオーバーの使用Example Scenario: Using a Forced Failover to Recover from a Catastrophic Failure

プライマリ レプリカが失敗し、使用可能な同期されたセカンダリ レプリカがない場合は、可用性グループの強制フェールオーバーが適切な対応であることがあります。If the primary replica fails and no synchronized secondary replica is available, forcing the availability group to fail over might be an appropriate response. フェールオーバーの強制が適切かどうかは、(1) プライマリ レプリカがオフラインになっている時間がサービス レベル契約 (SLA) で許容される時間よりも長くなると見込まれるかどうかと、(2) プライマリ データベースをすぐに使用できるようにする目的でデータ損失の可能性のリスクを許容できるかどうかという 2 点によって決まります。The appropriateness of forcing a failover depends on: (1) whether you expect the primary replica to be offline for longer than your service level agreement (SLA) tolerates, and (2) whether you are willing to risk potential data loss in order to make primary databases available quickly. 可用性グループに強制フェールオーバーが必要だと判断したとしても、実際の強制フェールオーバーは、複数の手順から成るプロセスの中の 1 つの手順です。If you decide that an availability group requires a forced failover, the actual forced failover is but one step of a multi-step process.

重大なエラーからの強制フェールオーバーによる復旧に必要な手順を説明するために、このトピックでは 1 つの災害復旧シナリオを示します。To illustrate the steps that are required to use a forced failover to recover from a catastrophic failure, this topic presents one possible disaster recovery scenario. このサンプル シナリオで想定する可用性グループは、元のトポロジがメイン データ センターとリモート データ センターで構成されています。メイン データ センターは、3 つの同期コミット可用性レプリカをホストしており、これにはプライマリ レプリカが含まれています。リモート データ センターは、2 つの非同期コミット セカンダリ レプリカをホストしています。The example scenario considers an availability group whose original topology consists of a main data center that hosts three synchronous-commit availability replicas, including the primary replica, and a remote data center that hosts two asynchronous-commit secondary replicas. 次の図は、この例の可用性グループの元のトポロジを示しています。The following figure illustrates the original topology of this example availability group. 可用性グループは、メイン データ センターに 3 つのノード (Node 01Node 02、および Node 03) があり、リモート データ センターに 2 つのノード (Node 04Node 05) があるマルチサブネット WSFC クラスターによってホストされています。The availability group is hosted by a multi-subnet WSFC cluster with three nodes in the main data center (Node 01, Node 02, and Node 03) and two nodes in a remote data center (Node 04 and Node 05).

可用性グループの元のトポロジOriginal topology of availability group

メイン データ センターが、予期せずシャットダウンされました。The main data center shuts down unexpectedly. 3 つの可用性レプリカがオフラインになり、データベースは使用できなくなります。Its three availability replicas to go offline, and their databases become unavailable. 次の図は、可用性グループのトポロジに対するこのエラーの影響を示しています。The following figure illustrates the impact of this failure on the topology of the availability group.

メイン データ センターのエラー発生後のトポロジTopology after failure of main data center

データベース管理者 (DBA) は、リモートの非同期コミット セカンダリ レプリカのいずれかに可用性グループを強制フェールオーバーすることが最善の対応であると判断しました。The database administrator (DBA) determines that the best possible response is to force failover of the availability group to one of the remote, asynchronous-commit secondary replicas. この例では、可用性グループをリモート レプリカに強制フェールオーバーし、最終的には可用性グループを元のトポロジに戻す場合に必要な、一般的な手順について説明します。This example illustrates the typical steps involved when you force failover of the availability group to a remote replica and, eventually, return the availability group to its original topology.

ここで示されているエラー対応は、次の 2 つのフェーズで構成されています。The failure-response presented here consists of the following two phases:

Responding to the Catastrophic Failure of the Main Data CenterResponding to the Catastrophic Failure of the Main Data Center

次の図は、メイン データ センターでの重大なエラーに対応して、リモート データ センターで実行される一連の操作を示しています。The following figure illustrates the series of actions performed at the remote data center in response a catastrophic failure at the main data center.

メイン データ センターのエラーに対応する手順Steps for responding to failure of main data center

この図の手順は、次の手順を示しています。The steps in this figure indicate the following steps:

手順Step 操作Action リンクLinks
1.1. DBA またはネットワーク管理者は、WSFC クラスターに正常なクォーラムがあることを確認します。The DBA or network administrator ensures that the WSFC cluster has a healthy quorum. この例では、クォーラムが強制される必要があります。In this example, quorum needs to be forced. WSFC クォーラム モードと投票の構成 (SQL Server)WSFC Quorum Modes and Voting Configuration (SQL Server)

WSFC の強制クォーラムによる災害復旧 (SQL Server)WSFC Disaster Recovery through Forced Quorum (SQL Server)
2.2. DBA は、待機時間が最も少ないサーバー インスタンス ( Node 04) に接続し、強制手動フェールオーバーを実行します。The DBA connects to the server instance with the least latency (on Node 04) and performs a forced manual failover. 強制フェールオーバーにより、このセカンダリ レプリカがプライマリ ロールに移行され、残りのセカンダリ レプリカ ( Node 05) のセカンダリ データベースが中断されます。The forced failover transitions this secondary replica to the primary role and suspends the secondary databases on the remaining secondary replica (on Node 05). sys.dm_hadr_database_replica_states (Transact-SQL) ( end_of_log_lsn 列に対するクエリ)。sys.dm_hadr_database_replica_states (Transact-SQL) (Query the end_of_log_lsn column. 詳細については、このトピックの「 推奨事項」を参照してください。)For more information, see Recommendations, earlier in this topic.)
3.3. DBA は、残りのセカンダリ レプリカの各セカンダリ データベースを手動で再開します。The DBA manually resumes each of the secondary databases on the remaining secondary replica. 可用性データベースの再開 (SQL Server)Resume an Availability Database (SQL Server)

可用性グループの元のトポロジへの復帰Returning the Availability Group to its Original Topology

次の図は、メイン データ センターがオンラインに戻り、WSFC ノードが WSFC クラスターとの通信を再確立した後で、可用性グループを元のトポロジに復帰させる一連の操作を示しています。The following figure illustrates the series of actions that return the availability group to its original topology after the main data center comes back online and the WSFC nodes re-establish communication with the WSFC cluster.

重要

WSFC クラスター クォーラムが強制された場合、オフラインのノードは 2 つの条件が満たされれば、再開するときに新しいクォーラムを形成できます。2 つの条件とは、(a) 強制されたクォーラムのセット内のいずれのノード間にもネットワーク接続がなく、(b) 再開するノードがクラスター ノードの過半数を占めていることです。If the WSFC cluster quorum has been forced, as the offline nodes restart they could form a new quorum if the following conditions both exist: (a) there is no network connectivity between any of the nodes in the forced-quorum set, and (b) the restarting nodes are the majority of the cluster nodes. この結果として、可用性グループに 2 つの独立したプライマリ レプリカ (各データ センターに 1 つ) が含まれる、"スプリット ブレイン" 状態が発生します。This would result in a "split brain" condition in which the availability group would possess two independent primary replicas, one at each data center. クォーラムで強制的にマイノリティ クォーラム セットを作成する前に、「 WSFC の強制クォーラムによる災害復旧 (SQL Server)の PowerShell を使用して、AlwaysOn 可用性グループに対する強制フェールオーバー (データ損失の可能性あり) を実行する方法について説明します。Before forcing quorum to create a minority quorum set, see WSFC Disaster Recovery through Forced Quorum (SQL Server).

グループを元のトポロジへ復帰する手順Steps to return the group to its original topology

この図の手順は、次の手順を示しています。The steps in this figure indicate the following steps:

手順Step リンクLinks
1.1. メイン データ センターのノードがオンラインに戻り、WSFC クラスターとの通信を再確立します。The nodes in the main data center come back online and re-establish communication with the WSFC cluster. その可用性レプリカは、中断されたデータベースと共にセカンダリ レプリカとしてオンラインに戻り、DBA は直ちに手動で各データベースを再開する必要があります。Their availability replicas come online as secondary replicas with suspended databases, and the DBA will need to manually resume each of these databases soon. 可用性データベースの再開 (SQL Server)Resume an Availability Database (SQL Server)

ヒント:フェールオーバー後のプライマリ データベースでデータ損失の可能性が懸念される場合は、同期コミットのセカンダリ データベースの 1 つで、中断されたデータベースにデータベース スナップショットの作成を試みる必要があります。Tip: If you are concerned about possible data loss on the post-failover primary databases, you should attempt to create a database snapshot on the suspended databases on one the synchronous-commit secondary database. プライマリ データベースでは、いずれかのセカンダリ データベースが中断している間、トランザクション ログの切り捨てが遅延されることに注意してください。Keep in mind that the transaction log truncation is delayed on a primary database while any of its secondary databases is suspended. また、同期コミット セカンダリ レプリカの同期状態は、いずれかのローカル データベースが中断している間、HEALTHY に移行できません。Also the synchronization health of the synchronous-commit secondary replica cannot transition to HEALTHY as long as any local database remains suspended.
2.2. データベースが再開されたら、DBA は新しいプライマリ レプリカを一時的に同期コミット モードに変更します。Once the databases are resumed, the DBA changes the new primary replica to synchronous-commit mode temporarily. これには、次の 2 つの手順があります。This involves two steps:

1) 1 つのオフライン可用性レプリカを非同期コミット モードに変更する。1) Change one offline availability replica to asynchronous-commit mode.

2) 新しいプライマリ レプリカを同期コミット モードに変更する。2) Change the new primary replica to synchronous-commit mode. 注:この手順により、再開された同期コミット セカンダリ データベースを SYNCHRONIZED にすることができます。Note: This step enables resumed synchronous-commit secondary databases to become SYNCHRONIZED.
可用性レプリカの可用性モードの変更 (SQL Server)Change the Availability Mode of an Availability Replica (SQL Server)
3.3. Node 03 の同期コミット セカンダリ レプリカ (元のプライマリ レプリカ) が HEALTHY 同期状態になったら、DBA はそのレプリカに計画的な手動フェールオーバーを実行して、プライマリ レプリカに戻します。Once the synchronous-commit secondary replica on Node 03 (the original primary replica) enters the HEALTHY synchronization state, the DBA performs a planned manual failover to that replica, to make it the primary replica again. Node 04 のレプリカは、セカンダリ レプリカに戻ります。The replica on Node 04 returns to being a secondary replica. sys.dm_hadr_database_replica_states (Transact-SQL)sys.dm_hadr_database_replica_states (Transact-SQL)

AlwaysOn ポリシーを使用した可用性グループの正常性の確認 (SQL Server)Use Always On Policies to View the Health of an Availability Group (SQL Server)

可用性グループの計画的な手動フェールオーバーの実行 (SQL Server)Perform a Planned Manual Failover of an Availability Group (SQL Server)
4.4. DBA は、新しいプライマリ レプリカに接続し、次の操作を行います。The DBA connects to the new primary replica and:

1) 元のプライマリ レプリカ (リモート センター内) を非同期コミット モードに戻します。1) Changes the former primary replica (in the remote center) back to asynchronous-commit mode.

2) メイン データ センターの非同期コミット セカンダリ レプリカを同期コミット モードに戻します。2) Changes the asynchronous-commit secondary replica in the main data center back to synchronous-commit mode.
可用性レプリカの可用性モードの変更 (SQL Server)Change the Availability Mode of an Availability Replica (SQL Server)

関連タスクRelated Tasks

クォーラム投票を調整するには:To adjust quorum votes

計画的な手動フェールオーバー:Planned manual failover:

トラブルシューティングするには:To troubleshoot:

関連コンテンツRelated Content

参照See Also

AlwaysOn 可用性グループの概要 (SQL Server) Overview of Always On Availability Groups (SQL Server)
可用性モード (AlwaysOn 可用性グループ) Availability Modes (Always On Availability Groups)
フェールオーバーとフェールオーバー モード (AlwaysOn 可用性グループ) Failover and Failover Modes (Always On Availability Groups)
可用性レプリカに対するクライアント接続アクセスについて (SQL Server) About Client Connection Access to Availability Replicas (SQL Server)
可用性グループの監視 (SQL Server) Monitoring of Availability Groups (SQL Server)
Windows Server フェールオーバー クラスタリング (WSFC) と SQL ServerWindows Server Failover Clustering (WSFC) with SQL Server