可用性グループの強制手動フェールオーバーの実行 (SQLServer)

[アーティクル]
03/04/2014

このトピックでは、SQL Server Management Studio、Transact-SQL、または SQL Server 2012 の PowerShell を使用して、AlwaysOn 可用性グループに対する強制フェールオーバー (データ損失の可能性あり) を実行する方法について説明します。強制フェールオーバーは、計画的な手動フェールオーバーを実行できない場合に、災害復旧のみを目的として実行する手動フェールオーバーです。非同期のセカンダリレプリカに対して強制フェールオーバーを実行した場合、データ損失の可能性があります。したがって、強制フェールオーバーは、データ損失のリスクを引き受けたうえで、可用性グループに対するサービスを直ちに復旧する必要がある場合のみ実行することを強くお勧めします。

強制フェールオーバーの実行後、可用性グループのフェールオーバー先であるフェールオーバーターゲットが新しいプライマリレプリカになります。残りのセカンダリレプリカ内のセカンダリデータベースは中断され、手動で再開する必要があります。元のプライマリレプリカは、使用可能になったときにセカンダリロールに移行し、元のプライマリデータベースがセカンダリデータベースになり、SUSPENDED 状態に移行します。特定のセカンダリデータベースを再開する前に、そのデータベースから失われたデータを復元できる場合があります。ただし、特定のプライマリデータベースでは、いずれかのセカンダリデータベースが中断している間は、トランザクションログの切り捨てが遅延されることに注意してください。

重要
プライマリデータベースとのデータ同期は、セカンダリデータベースが再開されるまで実行されません。セカンダリデータベースの再開の詳細については、この記事の「補足情報: 強制フェールオーバー後の必須タスク」を参照してください。

強制フェールオーバーは、次のような緊急事態が発生した場合に実行する必要があります。

WSFC クラスターに対して強制クォーラムを実行した後 (強制クォーラム)、各可用性グループに対して強制フェールオーバー (データ損失の可能性あり) を実行する必要があります。強制フェールオーバーが必要なのは、WSFC クラスター値の実際の状態が失われている可能性があるためです。ただし、強制クォーラムを実行する前にプライマリレプリカであったレプリカをホストしていたサーバーインスタンスで強制フェールオーバーを実行できる場合、または強制クォーラムを実行する前に同期されていたセカンダリレプリカに対してフェールオーバーを実行できる場合は、データ損失を回避できます。詳細については、このトピックの「クォーラム強制後のデータ損失を回避できる方法」を参照してください。

重要
クォーラムが強制ではなく通常の方法で再取得される場合、可用性レプリカは通常の方法で復元されます。クォーラムの再取得後にプライマリレプリカがまだ使用できない場合は、同期セカンダリレプリカに対して計画的な手動フェールオーバーを実行できます。

クォーラムの強制の詳細については、「WSFC の強制クォーラムによる災害復旧 (SQL Server)」を参照してください。クォーラムの強制後に強制フェールオーバーが必要な理由の詳細については、「フェールオーバーとフェールオーバーモード (AlwaysOn 可用性グループ)」を参照してください。

WSFC クラスターに正常なクォーラムがあるときにプライマリレプリカが使用不能になった場合は、そのロールが SECONDARY または RESOLVING 状態にある任意のレプリカに強制フェールオーバー (データ損失の可能性あり) を実行できます。可能であれば、プライマリレプリカが失われたときに同期されていた、同期コミットセカンダリレプリカへの強制フェールオーバーを実行します。

ヒント
WSFC クラスターに正常なクォーラムがあるときに、同期セカンダリレプリカで強制フェールオーバーコマンドを発行した場合、レプリカが実際に実行するのは、計画的な手動フェールオーバーです。

注
強制フェールオーバーを実行するための前提条件と推奨事項の詳細、および強制フェールオーバーを使用して重大なエラーから復旧するサンプルシナリオについては、このトピックの「サンプルシナリオ: 重大なエラーから復旧するための強制フェールオーバーの使用」を参照してください。

作業を開始する準備:

制限事項と制約事項

前提条件

推奨事項

クォーラム強制後のデータ損失を回避できる方法

セキュリティ
次のものを使用して強制フェールオーバー (データ損失の可能性あり) を実行するには:

SQL Server Management Studio

Transact-SQL

PowerShell
補足情報: 強制フェールオーバー後の必須タスク
サンプルシナリオ: 重大なエラーから復旧するための強制フェールオーバーの使用
関連タスク
関連コンテンツ

作業を開始する準備

制限事項と制約事項

強制フェールオーバーは、Windows server フェールオーバークラスタリング (WSFC) にクォーラムが存在しない場合のみ実行できません。
可用性グループの強制フェールオーバー中にはデータ損失の可能性があります。さらに、強制フェールオーバーを開始したときにプライマリレプリカが実行されている場合は、クライアントがまだ元のプライマリデータベースに接続している可能性があります。したがって、プライマリレプリカが動作しておらず、データ損失のリスクを許容できる場合にのみ、可用性グループのデータベースへのアクセスを復旧するために強制フェールオーバーを実行することを強くお勧めします。
セカンダリデータベースが REVERTING または INITIALIZING 状態の場合、強制フェールオーバーを実行すると、そのデータベースはプライマリデータベースとして起動できなくなります。データベースが INTIAILIZGING 状態だった場合は、欠落しているログレコードをデータベースバックアップから適用するか、データベースを最初から完全に復元する必要があります。データベースが REVERTING 状態だった場合は、データベースをバックアップから完全に復元する必要があります。
フェールオーバーコマンドは、フェールオーバーターゲットがコマンドを受け入れた直後に戻ります。ただし、データベースの復旧は、可用性グループがフェールオーバーを完了した後に非同期で行われます。

フェールオーバー時に、可用性グループ内のデータベース間の一貫性は維持されません。

注
複数のデータベースにまたがるトランザクションおよび分散トランザクションは、AlwaysOn 可用性グループではサポートされません。詳細については、「データベースミラーリングまたは AlwaysOn 可用性グループではサポートされない複数データベースにまたがるトランザクション (SQL Server)」を参照してください。

複数のデータベースにまたがるトランザクションおよび分散トランザクションは、AlwaysOn 可用性グループではサポートされません。詳細については、「データベースミラーリングまたは AlwaysOn 可用性グループではサポートされない複数データベースにまたがるトランザクション (SQL Server)」を参照してください。

前提条件

WSFC クラスターにクォーラムがあること。クラスターにクォーラムが存在しない場合は、「WSFC の強制クォーラムによる災害復旧 (SQL Server)」を参照してください。
そのロールが SECONDARY または RESOLVING 状態であるレプリカをホストするサーバーインスタンスに接続できる必要があります。

推奨事項

プライマリレプリカが実行中である間は、強制フェールオーバーを実行しないでください。
可能な場合は、セカンダリデータベースが NOT SYNCHRONIZED、SYNCHRONIZED、SYNCHRONIZING のいずれかの状態であるセカンダリレプリカにのみ、強制フェールオーバーを実行します。セカンダリデータベースが INTIAILIZGING または REVERTING 状態の場合の強制フェールオーバーの影響については、このトピックの「制限事項と制約事項」を参照してください。

通常は、特定のセカンダリデータベースの待機時間は、プライマリデータベースに比べて、別の非同期コミットセカンダリレプリカでも同じくらいになります。ただし、強制フェールオーバーを行う場合は、データ損失が重要な問題になります。そのため、異なるセカンダリレプリカ上でのデータベースのコピーに関する相対的な待機時間を検討するようにしてください。特定のセカンダリデータベースのどのコピーが最小の待機時間かを判断するには、ログの最後の LSN を比較します。ログの最後の LSN の値が大きいほど、待機時間が少ないことになります。

ヒント
ログの最後の LSN を比較するには、それぞれのオンラインセカンダリレプリカに接続し、sys.dm_hadr_database_replica_states に対して各ローカルセカンダリデータベースの end_of_log_lsn の値のクエリを実行します。次に、各データベースの異なるコピーで、ログの最後の LSN を比較します。異なるセカンダリレプリカ上では、最大の LSN を持つデータベースも異なる場合があることに注意してください。この場合、最も適切なフェールオーバーターゲットは、各データベース内のデータの相対的な重要度によって決まります。つまり、どのデータベースでのデータ損失の可能性を最小限に抑えたいか、という問題になります。

ログの最後の LSN を比較するには、それぞれのオンラインセカンダリレプリカに接続し、sys.dm_hadr_database_replica_states に対して各ローカルセカンダリデータベースの end_of_log_lsn の値のクエリを実行します。次に、各データベースの異なるコピーで、ログの最後の LSN を比較します。異なるセカンダリレプリカ上では、最大の LSN を持つデータベースも異なる場合があることに注意してください。この場合、最も適切なフェールオーバーターゲットは、各データベース内のデータの相対的な重要度によって決まります。つまり、どのデータベースでのデータ損失の可能性を最小限に抑えたいか、という問題になります。

クライアントが元のプライマリに接続できる場合は、強制フェールオーバーによってスプリットブレイン動作のリスクが発生します。強制フェールオーバーを実行する前に、クライアントが元のプライマリレプリカにアクセスできないようにすることを強くお勧めします。そうしないと、強制フェールオーバーの実行後に元のプライマリデータベースと現在のプライマリデータベースがそれぞれ、他方とは無関係に更新されることがあります。

クォーラム強制後のデータ損失を回避できる方法

クォーラムが失われた後のエラー状態中は、以下に示すように、データ損失を回避できます。

元のプライマリレプリカがオンラインになる場合

クォーラムが失われ、WSFC クォーラムの強制によって可用性グループのプライマリレプリカをホストするクラスターノードが復元される場合は、その可用性グループのデータ損失を回避できます。プライマリレプリカに接続し、強制フェールオーバー (FAILOVER_ALLOW_DATA_LOSS) を実行します。これにより、プライマリレプリカがオンラインに戻ります。元のプライマリレプリカへの強制フェールオーバーを実行するため、データ損失は起こりません。

同期コミットセカンダリレプリカがオンラインになる場合

クォーラムが失われ、WSFC クォーラムの強制によって可用性グループの同期セカンダリレプリカをホストするクラスターノードが復元される場合は、その可用性グループのデータ損失を回避できます。復元されるノードが、クォーラムの消失時に起動していた場合は、sys.dm_hadr_database_replica_cluster_states 動的管理ビューの is_failover_ready 列をクエリすることで、特定のデータベースでデータ損失が発生するかどうかを確認できます。たとえば、sql108w2k8r22 という名前のサーバーインスタンスに対して、次のクエリを発行します。

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 は、プライマリレプリカがオフラインになった時点のクラスターの実際の状態を反映していない可能性があります。したがって、is_failover_ready 値は、エラー発生時のホストノードにのみ有効です。詳細については、「フェールオーバーとフェールオーバーモード (AlwaysOn 可用性グループ)」の「クォーラムの強制後に強制フェールオーバーが必要な理由」を参照してください。

復元されるノードがクォーラムの消失時に起動してなかった場合、is_failover_ready は、プライマリレプリカがオフラインになった時点のクラスターの実際の状態を反映していない可能性があります。したがって、is_failover_ready 値は、エラー発生時のホストノードにのみ有効です。詳細については、「フェールオーバーとフェールオーバーモード (AlwaysOn 可用性グループ)」の「クォーラムの強制後に強制フェールオーバーが必要な理由」を参照してください。

is_failover_ready = 1 の場合、データベースはクラスター内で同期済みとマークされ、フェールオーバーの準備ができています。特定のセカンダリレプリカのすべてのデータベースで is_failover_ready = 1 の場合は、そのセカンダリレプリカに対して、データ損失なしで強制フェールオーバー (FORCE_FAILOVER_ALLOW_DATA_LOSS) を実行できます。同期セカンダリレプリカは、すべてのデータを保持したまま、新しいプライマリレプリカとしてプライマリロールでオンラインになります。

is_failover_ready = 0 の場合、データベースはクラスター内で同期済みとマークされておらず、計画的なフェールオーバーの準備ができていません。ホストセカンダリレプリカに対して強制フェールオーバーを実行した場合、そのデータベースのデータは失われます。

注
セカンダリレプリカに対して強制フェールオーバーを実行する場合、データ損失の量は、フェールオーバーターゲットがどの程度プライマリレプリカに遅れているかによって決まります。残念ながら、WSFC クラスターにクォーラムが存在しない、またはクォーラムが強制されている場合は、失われる可能性があるデータの量を評価できません。ただし、WSFC クラスターが正常なクォーラムを再取得した後、データ損失の可能性を追跡できます。詳細については、「フェールオーバーとフェールオーバーモード (AlwaysOn 可用性グループ)」の「データ損失の可能性の追跡」を参照してください。

セカンダリレプリカに対して強制フェールオーバーを実行する場合、データ損失の量は、フェールオーバーターゲットがどの程度プライマリレプリカに遅れているかによって決まります。残念ながら、WSFC クラスターにクォーラムが存在しない、またはクォーラムが強制されている場合は、失われる可能性があるデータの量を評価できません。ただし、WSFC クラスターが正常なクォーラムを再取得した後、データ損失の可能性を追跡できます。詳細については、「フェールオーバーとフェールオーバーモード (AlwaysOn 可用性グループ)」の「データ損失の可能性の追跡」を参照してください。

セキュリティ

権限

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

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

SQL Server Management Studio の使用

強制フェールオーバー (データ損失の可能性あり) を実行するには

オブジェクトエクスプローラーで、フェールオーバーを行う必要がある可用性グループでロールが SECONDARY または RESOLVING 状態であるレプリカをホストするサーバーインスタンスに接続し、サーバーツリーを展開します。
[AlwaysOn 高可用性] ノードと [可用性グループ] ノードを展開します。
フェールオーバーする [可用性グループ] ノードを右クリックし、[フェールオーバー] を選択します。
可用性グループのフェールオーバーウィザードが起動します。詳細については、「可用性グループのフェールオーバーウィザードの使用 (SQL Server Management Studio)」を参照してください。
可用性グループを強制的にフェールオーバーした後で、必要なフォローアップ手順を実行します。詳細については、このトピックの「補足情報: 強制フェールオーバー後の必須タスク」を参照してください。

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

Transact-SQL の使用

強制フェールオーバー (データ損失の可能性あり) を実行するには

フェールオーバーを行う必要がある可用性グループでロールが SECONDARY または RESOLVING 状態であるレプリカをホストするサーバーインスタンスに接続し、サーバーツリーを展開します。
ALTER AVAILABILITY GROUP ステートメントを使用します。次にその例を示します。

ALTER AVAILABILITY GROUP group_name FORCE_FAILOVER_ALLOW_DATA_LOSS

group_name は、可用性グループの名前です。

次の例では、AccountsAG 可用性グループのローカルセカンダリレプリカへのフェールオーバーを強制的に実行します。
```
ALTER AVAILABILITY GROUP AccountsAG FORCE_FAILOVER_ALLOW_DATA_LOSS;
```
可用性グループを強制的にフェールオーバーした後で、必要なフォローアップ手順を実行します。詳細については、このトピックの「補足情報: 強制フェールオーバー後の必須タスク」を参照してください。

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

PowerShell の使用

強制フェールオーバー (データ損失の可能性あり) を実行するには

フェールオーバーを行う必要がある可用性グループでロールが SECONDARY または RESOLVING 状態であるレプリカをホストするサーバーインスタンスにディレクトリを変更 (cd) します。

次の形式のいずれかで AllowDataLoss パラメーターを指定して Switch-SqlAvailabilityGroup コマンドレットを使用します。

-AllowDataLoss

既定では、Switch-SqlAvailabilityGroup に -AllowDataLoss パラメーターを指定した場合、強制フェールオーバーを実行するとコミットされていないトランザクションが失われる可能性があることが通知され、操作を続行するかどうかの確認を求められます。続行するには「Y」を入力し、操作をキャンセルするには「N」を入力します。

次の例では、可用性グループ MyAg に対して、SecondaryServer\InstanceName サーバーインスタンスのセカンダリレプリカへの強制フェールオーバー (データ損失の可能性あり) が実行されます。この操作の確認を求めるメッセージが表示されます。
```
Switch-SqlAvailabilityGroup `
   -Path SQLSERVER:\Sql\SecondaryServer\InstanceName\AvailabilityGroups\MyAg `
   -AllowDataLoss
```
-AllowDataLoss -Force

確認を求めずに強制フェールオーバーを実行するには、-AllowDataLoss パラメーターと -Force パラメーターを両方とも指定します。これは、コマンドをスクリプトに組み込んで自動的に実行する場合に役立ちます。ただし、強制フェールオーバーによって可用性グループに参加しているデータベースでデータ損失が発生する可能性があるため、-Force オプションは慎重に使用する必要があります。

次の例では、可用性グループ MyAg に対して、SecondaryServer\InstanceName サーバーインスタンスへの強制フェールオーバー (データ損失の可能性あり) が実行されます。 -Force オプションにより、この操作の確認は表示されません。
```
Switch-SqlAvailabilityGroup `
   -Path SQLSERVER:\Sql\SecondaryServer\InstanceName\AvailabilityGroups\MyAg `
   -AllowDataLoss -Force
```

注
コマンドレットの構文を表示するには、SQL Server PowerShell 環境で Get-Help コマンドレットを使用します。詳細については、「SQL Server PowerShell のヘルプの参照」を参照してください。

可用性グループを強制的にフェールオーバーした後で、必要なフォローアップ手順を実行します。詳細については、このトピックの「補足情報: 強制フェールオーバー後の必須タスク」を参照してください。

SQL Server PowerShell プロバイダーを設定して使用するには

SQL Server PowerShell プロバイダー

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

補足情報: 強制フェールオーバー後の必須タスク

強制フェールオーバーの後で、フェールオーバー先のセカンダリレプリカが新しいプライマリレプリカになります。ただし、この可用性レプリカにクライアントからアクセスできるようにするには、WSFC クォーラムの再構成または可用性グループの可用性モード構成の調整が必要な場合があります。次の手順を実行してください。

自動フェールオーバーセットの外側でフェールオーバーした場合: WSFC ノードのクォーラム投票を調整して新しい可用性グループの構成を反映します。対象のセカンダリレプリカがホストされている WSFC ノードに WSFC クォーラム投票がない場合、強制的に WSFC クォーラムを適用することが必要な場合があります。

注
自動フェールオーバーセットは、2 つの可用性レプリカ (元のプライマリレプリカを含む) に、自動フェールオーバーが指定され、同期コミットモードが構成されている場合のみ存在します。

クォーラム投票を調整するには

同期コミットフェールオーバーセットの外側でフェールオーバーした場合: 新しいプライマリレプリカおよび残りのセカンダリレプリカで、可用性モードとフェールオーバーモードを調整して、目的の同期コミット構成および自動フェールオーバー構成にすることをお勧めします。

注
同期コミットフェールオーバーセットは、現在のプライマリレプリカに同期コミットモードが構成されている場合にのみ存在します。

可用性モードとフェールオーバーモードを変更するには

強制フェールオーバー後は、すべてのセカンダリデータベースが中断されます。これには、元のプライマリデータベースも含まれます (元のプライマリレプリカは、オンラインに戻った後でセカンダリレプリカになります)。各セカンダリレプリカで、中断されたデータベースをそれぞれ手動で再開する必要があります。

セカンダリデータベースは、再開時に、対応するプライマリデータベースとの同期を開始します。新しいプライマリデータベースで 1 回もコミットされなかったログレコードは、すべてロールバックされます。そのため、フェールオーバー後のプライマリデータベースでデータ損失の可能性が懸念される場合は、同期コミットのセカンダリデータベースの 1 つで、中断されたデータベースにデータベーススナップショットの作成を試みる必要があります。

重要
プライマリデータベースでは、いずれかのセカンダリデータベースが中断している間は、トランザクションログの切り捨てが遅延されます。また、同期コミットセカンダリレプリカの同期状態は、いずれかのローカルデータベースが中断している間は、HEALTHY に移行できません。

データベーススナップショットを作成するには

データベーススナップショットの作成 (Transact-SQL)

可用性データベースを再開するには

可用性データベースの再開 (SQL Server)

注意
すべてのセカンダリデータベースを再開した後で、グループのフェールオーバーを再度試行する前に、次のフェールオーバーターゲットのすべてのセカンダリデータベースが SYNCHRONIZING 状態になるまで待機します。どのデータベースもまだ SYNCHRONIZING 状態ではない場合、データベースをプライマリデータベースとしてオンラインにすることができません。また、データベースへのデータ同期を再確立するには、トランザクションログの復元、データベースバックアップ全体の復元、または元のプライマリレプリカへのフェールオーバーが必要となる場合があります。

すべてのセカンダリデータベースを再開した後で、グループのフェールオーバーを再度試行する前に、次のフェールオーバーターゲットのすべてのセカンダリデータベースが SYNCHRONIZING 状態になるまで待機します。どのデータベースもまだ SYNCHRONIZING 状態ではない場合、データベースをプライマリデータベースとしてオンラインにすることができません。また、データベースへのデータ同期を再確立するには、トランザクションログの復元、データベースバックアップ全体の復元、または元のプライマリレプリカへのフェールオーバーが必要となる場合があります。

停止した可用性レプリカがその可用性レプリカに戻らないか、戻るのが遅すぎて新しいプライマリデータベースでのトランザクションログの切り捨てを遅延できない場合、停止したレプリカを可用性グループから削除してログファイル用のディスク領域の不足を回避することを検討してください。

セカンダリレプリカを削除するには
- 可用性グループからのセカンダリレプリカの削除 (SQL Server)
強制フェールオーバー後、さらに追加で強制フェールオーバーを 1 回以上実行すると、連続する追加の強制フェールオーバーごとにログバックアップが実行されます。この理由については、「フェールオーバーとフェールオーバーモード (AlwaysOn 可用性グループ)」の「強制手動フェールオーバー (データ損失の可能性あり)」の「強制フェールオーバーのリスク」を参照してください。

ログバックアップを実行するには
- トランザクションログのバックアップ (SQL Server)

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

サンプルシナリオ: 重大なエラーから復旧するための強制フェールオーバーの使用

プライマリレプリカが失敗し、使用可能な同期されたセカンダリレプリカがない場合は、可用性グループの強制フェールオーバーが適切な対応であることがあります。フェールオーバーの強制が適切かどうかは、(1) プライマリレプリカがオフラインになっている時間がサービスレベル契約 (SLA) で許容される時間よりも長くなると見込まれるかどうかと、(2) プライマリデータベースをすぐに使用できるようにする目的でデータ損失の可能性のリスクを許容できるかどうかという 2 点によって決まります。可用性グループに強制フェールオーバーが必要だと判断したとしても、実際の強制フェールオーバーは、複数の手順から成るプロセスの中の 1 つの手順です。

重大なエラーからの強制フェールオーバーによる復旧に必要な手順を説明するために、このトピックでは 1 つの災害復旧シナリオを示します。このサンプルシナリオで想定する可用性グループは、元のトポロジがメインデータセンターとリモートデータセンターで構成されています。メインデータセンターは、3 つの同期コミット可用性レプリカをホストしており、これにはプライマリレプリカが含まれています。リモートデータセンターは、2 つの非同期コミットセカンダリレプリカをホストしています。次の図は、この例の可用性グループの元のトポロジを示しています。可用性グループは、メインデータセンターに 3 つのノード (Node 01、Node 02、および Node 03) があり、リモートデータセンターに 2 つのノード (Node 04 と Node 05) があるマルチサブネット WSFC クラスターによってホストされています。

可用性グループの元のトポロジ

メインデータセンターが、予期せずシャットダウンされました。 3 つの可用性レプリカがオフラインになり、データベースは使用できなくなります。次の図は、可用性グループのトポロジに対するこのエラーの影響を示しています。

メインデータセンターのエラー発生後のトポロジ

データベース管理者 (DBA) は、最善の対応は可用性グループをリモートの非同期コミットセカンダリレプリカのいずれかに強制フェールオーバーすることであると判断します。この例では、可用性グループをリモートレプリカに強制フェールオーバーし、最終的には可用性グループを元のトポロジに戻す場合に必要な、一般的な手順について説明します。

ここで示されているエラー対応は、次の 2 つのフェーズで構成されています。

メインデータセンターの重大なエラーへの対応
可用性グループの元のトポロジへの復帰

メインデータセンターの重大なエラーへの対応

次の図は、メインデータセンターでの重大なエラーに対応して、リモートデータセンターで実行される一連の操作を示しています。

メインデータセンターのエラーに対応する手順

この図の手順は、次の手順を示しています。

手順	操作	リンク
1.	DBA またはネットワーク管理者は、WSFC クラスターに正常なクォーラムがあることを確認します。この例では、クォーラムが強制される必要があります。	WSFC クォーラムモードと投票の構成 (SQL Server) WSFC の強制クォーラムによる災害復旧 (SQL Server)
2.	DBA は、待機時間が最も少ないサーバーインスタンス (Node 04) に接続し、強制手動フェールオーバーを実行します。強制フェールオーバーは、このセカンダリレプリカをプライマリロールに遷移させ、残りのセカンダリレプリカ (Node 05) のセカンダリデータベースを中断します。	sys.dm_hadr_database_replica_states (Transact-SQL) (end_of_log_lsn 列に対するクエリ。詳細については、このトピックの「推奨事項」を参照してください。) 可用性グループの強制手動フェールオーバーの実行 (SQLServer)
3.	DBA は、残りのセカンダリレプリカの各セカンダリデータベースを手動で再開します。	可用性データベースの再開 (SQL Server)

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

可用性グループの元のトポロジへの復帰

次の図は、メインデータセンターがオンラインに戻り、WSFC ノードが WSFC クラスターとの通信を再確立した後で、可用性グループを元のトポロジに復帰させる一連の操作を示しています。

重要
WSFC クラスタークォーラムが強制された場合、オフラインのノードは 2 つの条件が満たされれば、再開するときに新しいクォーラムを形成できます。2 つの条件とは、(a) 強制されたクォーラムのセット内のいずれのノード間にもネットワーク接続がなく、(b) 再開するノードがクラスターノードの過半数を占めていることです。この結果として、可用性グループに 2 つの独立したプライマリレプリカ (各データセンターに 1 つ) が含まれる、"スプリットブレイン" 状態が発生します。クォーラムにマイノリティクォーラムセットの作成を強制する前に、「WSFC の強制クォーラムによる災害復旧 (SQL Server)」を参照してください。

WSFC クラスタークォーラムが強制された場合、オフラインのノードは 2 つの条件が満たされれば、再開するときに新しいクォーラムを形成できます。2 つの条件とは、(a) 強制されたクォーラムのセット内のいずれのノード間にもネットワーク接続がなく、(b) 再開するノードがクラスターノードの過半数を占めていることです。この結果として、可用性グループに 2 つの独立したプライマリレプリカ (各データセンターに 1 つ) が含まれる、"スプリットブレイン" 状態が発生します。クォーラムにマイノリティクォーラムセットの作成を強制する前に、「WSFC の強制クォーラムによる災害復旧 (SQL Server)」を参照してください。

グループを元のトポロジへ復帰する手順

この図の手順は、次の手順を示しています。

メインデータセンターのノードがオンラインに戻り、WSFC クラスターとの通信を再確立します。その可用性レプリカは、中断されたデータベースと共にセカンダリレプリカとしてオンラインに戻り、DBA は直ちに手動で各データベースを再開する必要があります。

可用性データベースの再開 (SQL Server)

フェールオーバー後のプライマリデータベースでデータ損失の可能性が懸念される場合は、同期コミットのセカンダリデータベースの 1 つで、中断されたデータベースにデータベーススナップショットの作成を試みる必要があります。プライマリデータベースでは、いずれかのセカンダリデータベースが中断している間は、トランザクションログの切り捨てが遅延されることに注意してください。また、同期コミットセカンダリレプリカの同期状態は、いずれかのローカルデータベースが中断している間は、"正常" に移行できません。

データベースが再開されたら、DBA は新しいプライマリレプリカを一時的に同期コミットモードに変更します。これには、次の 2 つの手順があります。

1 つのオフライン可用性レプリカを非同期コミットモードに変更する。
新しいプライマリレプリカを同期コミットモードに変更する。

注
この手順により、再開された同期コミットセカンダリデータベースを SYNCHRONIZED にすることができます。

可用性レプリカの可用性モードの変更 (SQL Server)

Node 03 の同期コミットセカンダリレプリカ (元のプライマリレプリカ) が HEALTHY 同期状態になったら、DBA はそのレプリカに計画的な手動フェールオーバーを実行して、プライマリレプリカに戻します。 Node 04 のレプリカは、セカンダリレプリカに戻ります。

DBA は、新しいプライマリレプリカに接続し、次の操作を行います。

元のプライマリレプリカ (リモートセンター内) を非同期コミットモードに戻します。
メインデータセンターの非同期コミットセカンダリレプリカを同期コミットモードに戻します。

可用性レプリカの可用性モードの変更 (SQL Server)

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

次の方法で共有

可用性グループの強制手動フェールオーバーの実行 (SQLServer)