フェールオーバーとフェールオーバー モード (AlwaysOn 可用性グループ)Failover and Failover Modes (Always On Availability Groups)

適用対象: ○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

一般的に、可用性グループのコンテキスト内で、可用性レプリカのプライマリ ロールとセカンダリ ロールが フェールオーバーと呼ばれるプロセスで交換されることがあります。Within the context of an availability group, the primary role and secondary role of availability replicas are typically interchangeable in a process known as failover. フェールオーバーには、自動フェールオーバー (データ損失なし)、計画的な手動フェールオーバー (データ損失なし)、および " 強制フェールオーバー" と通常呼ばれる強制手動フェールオーバー (データ損失の可能性あり) の 3 つの形式があります。Three forms of failover exist: automatic failover (without data loss), planned manual failover (without data loss), and forced manual failover (with possible data loss), typically called forced failover. 自動フェールオーバーと計画的な手動フェールオーバーでは、すべてのデータが保持されます。Automatic and planned manual failover preserve all your data. 可用性グループは、可用性レプリカのレベルでフェールオーバーします。An availability group fails over at the availability-replica level. つまり、可用性グループはセカンダリ レプリカのいずれか (現在の " フェールオーバー ターゲット") にフェールオーバーされます。That is, an availability group fails over to one of its secondary replicas (the current failover target).

注意

データベース レベルの問題 (データ ファイルの損失、データベースの削除、トランザクション ログの破損による障害が疑われる場合など) が発生しても、可用性グループのフェールオーバーは行われません。Issues at the database level, such as a database becoming suspect due to the loss of a data file, deletion of a database, or corruption of a transaction log, do not cause an availability group to failover.

フェールオーバーによってフェールオーバー ターゲットがプライマリ ロールを引き継ぎ、そのデータベースを復旧し、新しいプライマリ データベースとしてオンラインにします。During the failover, the failover target takes over the primary role, recovers its databases, and brings them online as the new primary databases. 元のプライマリ レプリカは使用可能になるとセカンダリ ロールに切り替わり、そのデータベースがセカンダリ データベースになります。The former primary replica, when available, switches to the secondary role, and its databases become secondary databases. 場合によっては、複数のエラーに対する対応として、または管理目的のために、これらのロールを何度も交代できます (または、別のフェールオーバー ターゲットに切り替えることができます)。Potentially, these roles can switch back and forth (or to a different failover target) in response to multiple failures or for administrative purposes.

特定の可用性レプリカがサポートするフェールオーバーの形式は、" フェールオーバー モード " プロパティで指定されます。The form(s) of failover that a given availability replica supports is specified by the failover mode property. 可用性レプリカの有効なフェールオーバー モードは、次のようにそのレプリカの 可用性モード によって異なります。For a given availability replica, the possible failover modes depends on the availability mode of the replica, as follows:

  • 同期コミット レプリカ: 自動と手動の 2 つの設定をサポートします。Synchronous-commit replicas support two settings-automatic or manual. "自動" 設定では、自動フェールオーバーと手動フェールオーバーの両方をサポートしています。The "automatic" setting supports both automatic failover and manual failover. データの損失を回避するために、自動フェールオーバーおよび計画的なフェールオーバーでは、フェールオーバー ターゲットが正常な同期状態を持つセカンダリ レプリカを同期コミットします (これは、フェールオーバー ターゲット上のすべてのセカンダリ データベースが対応するプライマリ データベースと同期されることを表します)。To prevent data loss, automatic failover and planned failover require that the failover target be a synchronous-commit secondary replica with a healthy synchronization state (this indicates that every secondary database on the failover target is synchronized with its corresponding primary database). セカンダリ レプリカがどちらの条件も満たさない場合は、強制フェールオーバーのみがサポートされます。Whenever a secondary replica does not meet both of these conditions, it supports only forced failover. ロールが RESOLVING 状態であるレプリカでも強制フェールオーバーがサポートされていることに注意してください。Note that forced failover is also supported a replicas whose role is in the RESOLVING state.

  • 非同期コミット レプリカ: 手動フェールオーバー モードのみをサポートします。Asynchronous-commit replicas support only the manual failover mode. また、同期されないため、強制フェールオーバーのみをサポートします。Moreover, because they are never synchronized, they support only forced failover.

注意

フェールオーバー後、プライマリ データベースにアクセスする必要があるクライアント アプリケーションは、新しいプライマリ レプリカに接続する必要があります。After a failover, client applications that need to access the primary databases must connect to the new primary replica. また、新しいセカンダリ レプリカが読み取り専用アクセスを許可するように構成されている場合は、読み取り専用クライアント アプリケーションから接続できます。Also, if the new secondary replica is configured to allow read-only access, read-only client applications can connect to it. 可用性グループ リスナーの詳細については、「可用性グループ リスナー、クライアント接続、およびアプリケーションのフェールオーバー (SQL Server)」をご覧ください。For information about how clients connect to an availability group, see Availability Group Listeners, Client Connectivity, and Application Failover (SQL Server).

このトピックのセクション:Sections in This Topic:

用語と定義Terms and Definitions

自動フェールオーバー (automatic failover)Automatic failover
プライマリ レプリカの喪失によって自動的に発生するフェールオーバー。A failover that occurs automatically on the loss of the primary replica. 自動フェールオーバーは、現在のプライマリ レプリカと 1 つのセカンダリ レプリカのフェールオーバー モードがどちらも AUTOMATIC に設定され、セカンダリ レプリカが現在同期されている場合のみサポートされます。Automatic failover is supported only when the current primary and one secondary replica are both configured with failover mode set to AUTOMATIC and the secondary replica currently synchronized. プライマリ レプリカまたはセカンダリ レプリカのフェールオーバー モードが MANUAL に設定されている場合、自動フェールオーバーは実行されません。If the failover mode of either the primary or secondary replica is MANUAL, automatic failover cannot occur.

計画的な手動フェールオーバー (データ損失なし)Planned manual failover (without data loss)
計画的な手動フェールオーバーまたは " 手動フェールオーバー" は、一般的に管理目的でデータベース管理者によって開始されるフェールオーバーです。Planned manual failover, or manual failover, is a failover that is initiated by a database administrator, typically, for administrative purposes. 計画的な手動フェールオーバーは、プライマリ レプリカおよびセカンダリ レプリカに同期コミット モードが構成され、セカンダリ レプリカが現在プライマリ レプリカと同期されている (SYNCHRONIZED 状態になっている) 場合にのみサポートされます。A planned manual failover is supported only if both the primary replica and secondary replica are configured for synchronous-commit mode and the secondary replica is currently synchronized (in the SYNCHRONIZED state). 対象のセカンダリ レプリカが同期されているときは、セカンダリ データベースでフェールオーバーの準備が整っているため、プライマリ レプリカがクラッシュした場合でも手動フェールオーバー (データ損失なし) を実行できます。When the target secondary replica is synchronized, manual failover (without data loss) is possible even if the primary replica has crashed because the secondary databases are ready for failover. データベース管理者は手動フェールオーバーを手動で開始します。A database administrator manually initiates a manual failover.

強制フェールオーバー (データ損失の可能性あり)Forced failover (with possible data loss)
プライマリ レプリカに同期されている (SYNCHRONIZED 状態の) セカンダリ レプリカがない場合、またはプライマリ レプリカが実行されていないためにセカンダリ レプリカでフェールオーバーの準備が整っていない場合に、データベース管理者が開始できるフェールオーバー。A failover that can be initiated by a database administrator when no secondary replica is SYNCHRONIZED with the primary replica or the primary replica is not running and no secondary replica is failover ready. 強制フェールオーバーはデータを損失する可能性があるため、障害復旧にのみ使用することをお勧めします。Forced failover risks possible data loss and is recommended strictly for disaster recovery. 強制フェールオーバーは、手動のみで開始できるため、強制手動フェールオーバーとも呼ばれます。Forced failover is also known as forced manual failover because it can only be initiated manually. これは、非同期コミット可用性モードでサポートされているフェールオーバーの唯一の形式です。This is the only form of failover supported by in asynchronous-commit availability mode.

自動フェールオーバー セットAutomatic failover set

指定された可用性グループ内で、自動フェールオーバーが指定された同期コミット モード (存在する場合) が構成されている、(現在のプライマリ レプリカを含む) 可用性レプリカのペア。Within a given availability group, a pair of availability replicas (including the current primary replica) that are configured for synchronous-commit mode with automatic failover, if any. 自動フェールオーバー セットautomatic failover set は、セカンダリ レプリカがプライマリ レプリカとの間で現在 SYNCHRONIZED 状態にある場合のみ有効です。An 自動フェールオーバー セットautomatic failover settakes effect only if the secondary replica is currently SYNCHRONIZED with the primary replica.

同期コミット フェールオーバー セットSynchronous-commit failover set

指定された可用性グループ内で、同期コミット モード (存在する場合) が構成されている、(現在のプライマリ レプリカを含む) 2 つまたは 3 つの可用性レプリカのセット。Within a given availability group, a set of two or three availability replicas (including the current primary replica) that are configured for synchronous-commit mode, if any. 同期コミット フェールオーバー セットsynchronous-commit failover setは、セカンダリ レプリカに手動フェールオーバー モードが構成され、1 つ以上のセカンダリ レプリカとプライマリ レプリカが現在 SYNCHRONIZED 状態にある場合のみ有効です。A 同期コミット フェールオーバー セットsynchronous-commit failover settakes effect only if the secondary replicas are configured for manual failover mode and at least one secondary replica is currently SYNCHRONIZED with the primary replica.

全フェールオーバー セットEntire failover set

指定された可用性グループ内で、可用性モードおよびフェールオーバー モードに関係なく、現在の操作状態が ONLINE であるすべての可用性レプリカのセット。Within a given availability group, the set of all availability replicas whose operational state is currently ONLINE, regardless of availability mode and of failover mode. 全フェールオーバー セットentire failover setは、現在プライマリ レプリカと SYNCHRONIZED 状態になっているセカンダリ レプリカがない場合に有効です。The 全フェールオーバー セットentire failover setbecomes relevant when no secondary replica is currently SYNCHRONIZED with the primary replica.

フェールオーバーの概要Overview of Failover

次の表に、各種の可用性モードおよびフェールオーバー モードでサポートされるフェールオーバーの形式をまとめます。The following table summarizes which forms of failover are supported under different availability and failover modes. それぞれの組み合わせについて、プライマリ レプリカのモードと 1 つまたは複数のセカンダリ レプリカのモードとが交差する部分から、有効な可用性モードおよびフェールオーバー モードを判定できます。For each pairing, the effective availability mode and failover mode is determined by the intersection of the modes of the primary replica plus the modes of one or more secondary replicas.

非同期コミット モードAsynchronous-commit mode 手動フェールオーバー モードを指定した同期コミット モードSynchronous-commit mode with manual-failover mode 自動フェールオーバーを指定した同期コミット モードSynchronous-commit mode with automatic-failover mode
自動フェールオーバー (automatic failover)Automatic failover いいえNo いいえNo Yes
計画的な手動フェールオーバーPlanned manual failover いいえNo はいYes Yes
強制フェールオーバーForced failover Yes Yes *Yes *

* 同期されたセカンダリ レプリカ上で強制フェールオーバー コマンドを実行した場合、セカンダリ レプリカは手動フェールオーバーの場合と同様に動作します。* If you issue a forced failover command on a synchronized secondary replica, the secondary replica behaves the same as for a manual failover.

フェールオーバー中にデータベースが使用できなくなる時間の長さは、フェールオーバーの種類および原因によって異なります。The amount of time that the database is unavailable during a failover depends on the type of failover and its cause.

重要

フェールオーバー後もクライアント接続をサポートするには、これまでのすべてのプライマリ データベースで定義されたログインおよびジョブを新しいプライマリ データベースに手動で再作成する必要があります (ただし、包含データベースは例外)。To support client connections after failover, except for contained databases, logins and jobs defined on any of the former primary databases must be manually recreated on the new primary database. 詳細については、「 可用性グループのデータベースのためのログインとジョブの管理 (SQL Server)と呼ばれるプロセスで交換されることがあります。For more information, see Management of Logins and Jobs for the Databases of an Availability Group (SQL Server).

フェールオーバー セットFailover Sets

特定の可用性グループで可能なフェールオーバーの形式は、フェールオーバー セットの観点から理解できます。The forms of failover that are possible for a given availability group can be understood in terms of failover sets. フェールオーバー セットは、次のようにフェールオーバーの特定の形式をサポートするプライマリ レプリカとセカンダリ レプリカで構成されています。A failover set consists of the primary replica and secondary replicas that support a given form of failover, as follows:

  • 自動フェールオーバー セットAutomatic failover set (省略可能): 指定された可用性グループ内で、自動フェールオーバーが指定された同期コミット モード (存在する場合) が構成されている、(現在のプライマリ レプリカを含む) 可用性レプリカのペア。自動フェールオーバー セットAutomatic failover set (optional): Within a given availability group, a pair of availability replicas (including the current primary replica) that are configured for synchronous-commit mode with automatic failover, if any. 自動フェールオーバー セットは、セカンダリ レプリカがプライマリ レプリカとの間で現在 SYNCHRONIZED 状態にある場合のみ有効です。An automatic failover set takes effect only if the secondary replica is currently SYNCHRONIZED with the primary replica.

  • 同期コミット フェールオーバー セットSynchronous-commit failover set (省略可能): 指定された可用性グループ内で、同期コミット モード (存在する場合) が構成されている、(現在のプライマリ レプリカを含む) 2 つまたは 3 つの可用性レプリカのセット。同期コミット フェールオーバー セットSynchronous-commit failover set (optional): Within a given availability group, a set of two or three availability replicas (including the current primary replica) that are configured for synchronous-commit mode, if any. 同期コミット フェールオーバー セットは、セカンダリ レプリカに手動フェールオーバー モードが構成され、1 つ以上のセカンダリ レプリカとプライマリ レプリカが現在 SYNCHRONIZED 状態にある場合のみ有効です。A synchronous-commit failover set takes effect only if the secondary replicas are configured for manual failover mode and at least one secondary replica is currently SYNCHRONIZED with the primary replica.

  • 全フェールオーバー セットEntire failover set : 指定された可用性グループ内で、可用性モードおよびフェールオーバー モードに関係なく、現在の操作状態が ONLINE であるすべての可用性レプリカのセット。全フェールオーバー セットEntire failover set : Within a given availability group, the set of all availability replicas whose operational state is currently ONLINE, regardless of availability mode and of failover mode. 全フェールオーバー セットは、現在プライマリ レプリカと SYNCHRONIZED 状態になっているセカンダリ レプリカがない場合に有効です。The entire failover set becomes relevant when no secondary replica is currently SYNCHRONIZED with the primary replica.

可用性レプリカに、自動フェールオーバーが指定された同期コミット モードを構成した場合、可用性レプリカは 自動フェールオーバー セットautomatic failover setの一部になります。When you configure an availability replica as synchronous commit with automatic failover, the availability replica becomes part of the 自動フェールオーバー セットautomatic failover set. ただし、セットが有効になるかどうかは、現在のプライマリに依存します。However whether the set takes effect depends the current primary. 指定された時刻に実際に可能なフェールオーバーの形式は、現在有効なフェールオーバー セットによって決まります。The forms of failover that are actually possible at a given time depends on what failover sets are currently in effect.

たとえば、次に示す 4 つの可用性レプリカを持つ可用性グループについて考えてみましょう。For example, consider an availability group that has four availability replicas, as follows:

[レプリカ]Replica 可用性モードとフェールオーバー モードの設定Availability Mode and Failover Mode Settings
AA 同期コミット モードで自動フェールオーバーを指定Synchronous commit with automatic failover
BB 同期コミット モードで自動フェールオーバーを指定Synchronous commit with automatic failover
cC 同期コミット モードで計画的な手動フェールオーバーのみを指定Synchronous commit with planned manual failover only
DD 非同期コミット モード (強制フェールオーバーのみを指定)Asynchronous commit (with only forced failover)

各セカンダリ レプリカのフェールオーバーの動作は、現在どの可用性レプリカがプライマリ レプリカであるかによって異なります。The failover behavior for each secondary replica depends on which availability replica is currently the primary replica. 基本的には、特定のセカンダリ レプリカにおけるフェールオーバーの動作は、現在のプライマリ レプリカに想定される最悪のケースに対応します。Basically, for a given secondary replica, the failover behavior is the worst case given the current primary replica. 次の図は、セカンダリ レプリカのフェールオーバー動作が現在のプライマリ レプリカに応じてどのように変化するか、また、非同期コミット モード (強制フェールオーバーのみ使用) と同期コミット モード (自動フェールオーバーを使用する場合と使用しない場合があります) のどちらで構成されているかを示します。The following figure illustrates how the failover behavior of secondary replicas varies depending on the current primary replica, and whether it is configured for asynchronous-commit mode (with only forced failover) or synchronous-commit mode (with or without automatic failover).

プライマリ レプリカ構成がフェールオーバーに与える影響How primary replica configuration affects failover

Automatic FailoverAutomatic Failover

自動フェールオーバーでは、プライマリ レプリカが使用できなくなった後で、対応するセカンダリ レプリカが自動的にプライマリ ロールに移行します。An automatic failover causes a qualified secondary replica to automatically transition to the primary role after the primary replica becomes unavailable. セカンダリ レプリカをホストするノードに対して、プライマリ レプリカをホストする WSFC ノードがローカルである場合、自動フェールオーバーが最適です。Automatic failover is best suited when the WSFC node that hosts the primary replica is local to the node that hosts the secondary replica. これには、データ同期はコンピューター間のメッセージ待機時間が短いときに最も効果的であること、およびクライアント接続をローカルに保持できるという理由があります。This is because data synchronization works best with low message latency between computers and because client connections can remain local.

このセクションの内容In This Section:

自動フェールオーバーに必要な条件Conditions Required for an Automatic Failover

自動フェールオーバーは、以下の条件が満たされた場合のみ発生します。Automatic failover occurs only under the following conditions:

  • 自動フェールオーバー セットが存在する。An automatic failover set exists. このセットはプライマリ レプリカとセカンダリ レプリカ (" 自動フェールオーバー ターゲット") で構成され、プライマリ レプリカとセカンダリ レプリカは両方とも同期コミット モードで構成され、どちらも AUTOMATIC フェールオーバーに設定されています。This set consists of a primary replica and a secondary replica (the automatic failover target) that are both configured for synchronous-commit mode and set to AUTOMATIC failover. プライマリ レプリカが MANUAL フェールオーバーに設定されている場合、セカンダリ レプリカが AUTOMATIC フェールオーバーに設定されていても、自動フェールオーバーは行われません。If the primary replica is set to MANUAL failover, automatic failover cannot occur, even if a secondary replica is set to AUTOMATIC failover.

    詳細については、「 可用性モード (AlwaysOn 可用性グループ)と呼ばれるプロセスで交換されることがあります。For more information, see Availability Modes (Always On Availability Groups).

  • 自動フェールオーバー ターゲットの同期状態が正常である (これは、フェールオーバー ターゲットのすべてのセカンダリ データベースが、対応するプライマリ データベースと同期されていることを意味します)。The automatic failover target has a healthy synchronization state (this indicates that every secondary database on the failover target is synchronized with its corresponding primary database).

    ヒント

    AlwaysOn 可用性グループでは、自動フェールオーバー セットの両方のレプリカの状態を監視します。Always On Availability Groups monitors the health of both replicas in an automatic failover set. いずれかのレプリカが失敗した場合、可用性グループの正常性状態が CRITICAL に設定されます。If either replica fails, the availability group's health state is set to CRITICAL. セカンダリ レプリカが失敗した場合、自動フェールオーバー ターゲットは使用できないため、自動フェールオーバーは実行されません。If the secondary replica fails, automatic failover is not possible because the automatic failover target is unavailable. プライマリ レプリカが失敗した場合、可用性グループはセカンダリ レプリカにフェールオーバーします。If the primary replica fails, the availability group will fail over to the secondary replica. 元のプライマリ レプリカがオンラインになるまで、自動フェールオーバー ターゲットは存在しません。Until the former primary replica comes online, no automatic failover target exists. どちらの場合でも、可用性を確保し、連続して失敗する可能性が低くなるように、別のセカンダリ レプリカを自動フェールオーバー ターゲットとして構成することをお勧めします。In either case, to ensure availability in the unlikely case of a sequential failure, we recommend that you configure a different secondary replica as the automatic failover target.

    詳細については、「AlwaysOn ポリシーを使用した可用性グループの正常性の確認 (SQL Server)」と「可用性レプリカのフェールオーバー モードの変更 (SQL Server)」を参照してください。For more information, see Use Always On Policies to View the Health of an Availability Group (SQL Server) and Change the Failover Mode of an Availability Replica (SQL Server).

  • Windows Server フェールオーバー クラスタリング (WSFC) クラスターにクォーラムがある。The Windows Server Failover Clustering (WSFC) cluster has quorum. 詳細については、「WSFC クォーラム モードと投票の構成 (SQL Server)」を参照してください。For more information, see WSFC Quorum Modes and Voting Configuration (SQL Server).

  • プライマリ レプリカが使用できなくなり、柔軟なフェールオーバー ポリシーにより定義されたフェールオーバー条件レベルが満たされている。The primary replica has become unavailable, and the failover-condition levels defined by your the flexible failover policy have been met. フェールオーバー条件レベルの詳細については、「 可用性グループの自動フェールオーバーのための柔軟なフェールオーバー ポリシー (SQL Server)と呼ばれるプロセスで交換されることがあります。For information about failover-condition levels, see Flexible Failover Policy for Automatic Failover of an Availability Group (SQL Server).

自動フェールオーバーの動作How Automatic Failover Works

自動フェールオーバーにより、次の一連の操作が開始されます。An automatic failover initiates the following sequence of actions:

  1. 現在のプライマリ レプリカをホストするサーバー インスタンスがまだ実行中の場合は、プライマリ データベースの状態が DISCONNECTED に変更され、すべてのクライアントが切断されます。If the server instance that is hosting the current primary replica is still running, it changes the state of the primary databases to DISCONNECTED and disconnects all clients.

  2. 対象のセカンダリ レプリカの復旧キューで待機中のログ レコードがある場合、セカンダリ レプリカはそのログ レコードを適用してセカンダリ データベースのロールフォワードを終了します。If any log records are waiting in recovery queues on the target secondary replica, the secondary replica applies the remaining log records to finish rolling forward the secondary databases.

    注意

    特定のデータベースにログを適用するために必要な時間は、システムの処理速度、直近の作業負荷、および復旧キュー内のログの量によって異なります。The amount of time required to apply the log to a given database depends on the speed of the system, the recent work load, and the amount of log in the recovery queue.

  3. 元のセカンダリ レプリカはプライマリ ロールに移行します。The former secondary replica transitions to the primary role. そのデータベースがプライマリ データベースになります。Its databases become the primary databases. 新しいプライマリ レプリカによって、コミットされていないすべてのトランザクションが迅速にロールバックされます (復旧の元に戻すフェーズ)。The new primary replica rolls back any uncommitted transactions (the undo phase of recovery) as quickly as possible. これらのコミットされていないトランザクションがロックによって分離されるため、クライアントがデータベースを使用している間にバック グラウンドでロールバックを行うことができます。Locks isolate these uncommitted transactions, allowing roll back to occur in the background while clients use the database. このプロセスでは、コミット済みのトランザクションはロールバックされません。This process does not roll back any committed transactions.

    特定のセカンダリ データベースが接続されるまでの短い間、NOT_SYNCHRONIZED としてマークされます。Until a given secondary database is connected, it is briefly marked as NOT_SYNCHRONIZED. ロールバックの復旧が開始される前、セカンダリ データベースは、新しいプライマリ データベースに接続し、即座に SYNCHRONIZED 状態に移行できます。Before the rollback recovery starts, secondary databases can connect to the new primary databases and quickly transition to the SYNCHRONIZED state. 一番問題のないケースは、フェールオーバー後もセカンダリ ロールを維持する 3 番目の同期コミット レプリカです。The best case is usually for a third synchronous-commit replica that remains in the secondary role after the failover.

  4. 元のプライマリ レプリカをホストしているサーバー インスタンスが後で再起動されると、別の可用性レプリカが新たにプライマリ ロールを所有していることが認識されます。Later, when the server instance that is hosting the former primary replica restarts, it recognizes that another availability replica now owns the primary role. 元のプライマリ レプリカはセカンダリ ロールに移行し、そのデータベースがセカンダリ データベースになります。The former primary replica transitions to the secondary role, and its databases become secondary databases. 新しいセカンダリ レプリカは現在のプライマリ レプリカに接続し、可能な限り早期にそのデータベースを現在のプライマリ データベースに同期します。The new secondary replica connects to the current primary replica and catches its database up to the current primary databases as quickly as possible. 新しいセカンダリ レプリカのデータベースの再同期が完了すると、その時点から、反対方向のフェールオーバーを実行できるようになります。As soon as the new secondary replica has resynchronized its databases, failover is again possible, in the reverse direction.

自動フェールオーバーを設定するにはTo Configure Automatic Failover

任意の時点で、可用性レプリカが自動フェールオーバーをサポートするように構成できます。An availability replica can be configured to support automatic failover at any point.

To configure automatic failoverTo configure automatic failover

  1. セカンダリ レプリカが、同期コミット可用性モードを使用するように構成されていることを確認します。Ensure that the secondary replica is configured to use the synchronous-commit availability mode. 詳細については、「 可用性レプリカの可用性モードの変更 (SQL Server)と呼ばれるプロセスで交換されることがあります。For more information, see Change the Availability Mode of an Availability Replica (SQL Server).

  2. フェールオーバー モードを自動に設定します。Set the failover mode to automatic. 詳細については、「 可用性レプリカのフェールオーバー モードの変更 (SQL Server)と呼ばれるプロセスで交換されることがあります。For more information, see Change the Failover Mode of an Availability Replica (SQL Server).

  3. 必要に応じて、可用性グループの柔軟なフェールオーバー ポリシーを変更して、自動フェールオーバーを発生させる障害の種類を指定します。Optionally, change the flexible failover policy of the availability group to specify the sorts of failures that can cause an automatic failover to occur. 詳細については、「 自動フェールオーバーの条件を制御する柔軟なフェールオーバー ポリシーの構成 (Always On Availability Groups) 」と「 フェールオーバー クラスター インスタンスのフェールオーバー ポリシーと呼ばれるプロセスで交換されることがあります。For more information, see Configure the Flexible Failover Policy to Control Conditions for Automatic Failover (Always On Availability Groups) and Failover Policy for Failover Cluster Instances.

計画的な手動フェールオーバー (データ損失なし)Planned Manual Failover (Without Data Loss)

対象のセカンダリ レプリカがホストされているサーバー インスタンスでデータベース管理者が手動フェールオーバー コマンドを発行すると、同期済みのセカンダリ レプリカがプライマリ ロールに移行します。A manual failover causes a synchronized secondary replica to transition to the primary role after a database administrator issues a manual-failover command on the server instance that hosts the target secondary replica. 手動フェールオーバーをサポートするには、セカンダリ レプリカと現在のプライマリ レプリカの両方に同期コミット モード (存在する場合) が構成されている必要があります。To support manual failover, the secondary replica and the current primary replica must both be configured for synchronous-commit mode, if any. 可用性レプリカのすべてのセカンダリ データベースが可用性グループに参加し、その対応するプライマリ データベースに同期されている必要があります (つまり、セカンダリ レプリカを同期する必要があります)。Every secondary database on the availability replica must be joined to the availability group and synchronized with its corresponding primary database (that is, the secondary replica must be synchronized). これにより、元のプライマリ データベースでコミットされていたトランザクションもすべて新しいプライマリ データベースに確実にコミットされます。This guarantees that every transaction that was committed on a former primary database has also been committed on the new primary database. したがって、新しいプライマリ データベースは、古いプライマリ データベースと同じです。Therefore, the new primary databases are identical to the old primary databases.

次の図に、計画的なフェールオーバーの段階を示します。The following figure illustrates the stages of a planned failover:

  1. フェールオーバーの前、プライマリ レプリカは Node01のサーバー インスタンスによってホストされています。Before the failover, the primary replica is hosted by the server instance on Node01.

  2. データベース管理者によって計画的なフェールオーバーが開始されます。A database administrator initiates a planned failover. フェールオーバー ターゲットは、 Node02のサーバー インスタンスによってホストされている可用性レプリカです。The failover target is the availability replica hosted by the server instance on Node02.

  3. ( Node02上の) フェールオーバー ターゲットが新しいプライマリ レプリカになります。The failover target (on Node02) becomes the new primary replica. これは計画的なフェールオーバーであるため、フェールオーバー中に元のプライマリ レプリカはセカンダリ ロールに切り替わり、そのデータベースをセカンダリ データベースとして即座にオンラインにします。Because this is a planned failover, the former primary replica switches to the secondary role during the failover and brings its databases online as secondary databases immediately.

計画的な手動フェールオーバーの図Illustation of a planned manual failover

このセクションの内容In This Section:

手動フェールオーバーに必要な条件Conditions Required for a Manual Failover

手動フェールオーバーをサポートするには、現在のプライマリ レプリカに同期コミット モードが設定され、セカンダリ レプリカが次の条件を満たす必要があります。To support a manual failover, the current primary replica must be set to synchronous-commit mode and a secondary replica must be:

  • 同期コミット モードが構成されている。Configured for synchronous-commit mode.

  • 現在、プライマリ レプリカと同期されている。Currently synchronized with the primary replica.

可用性グループのフェールオーバーを手動で実行するには、新しいプライマリ レプリカになるセカンダリ レプリカに接続する必要があります。To manually fail over an availability group, you must be connected to the secondary replica that is to become the new primary replica.

計画的な手動フェールオーバーの動作How a Planned Manual Failover Works

計画的な手動フェールオーバーは、対象のセカンダリ レプリカで開始する必要があります。計画的な手動フェールオーバーによって次の処理シーケンスが開始されます。A planned manual failover, which must be initiated on the target secondary replica, initiates the following sequence of actions:

  1. 新しいユーザー トランザクションが元のプライマリ データベースで発生しないようにするために、WSFC クラスターがプライマリ レプリカをオフラインにする要求をプライマリ レプリカに送信します。To ensure that no new user transactions occur on the original primary databases, the WSFC cluster sends a request to the primary replica to go offline.

  2. セカンダリ データベースの復旧キューで待機中のログがある場合は、セカンダリ レプリカで、そのセカンダリ データベースのロールフォワードが終了されます。If any log is waiting in the recovery queue of any secondary database, the secondary replica finishes rolling forward that secondary database. 必要な時間は、システムの処理速度、最近の作業負荷、および復旧キューのログの量によって異なります。The amount of time required depends on the speed of the system, the recent workload, and the amount of log in the recovery queue. 復旧キューの現在のサイズを調べるには、 Recovery Queue パフォーマンス カウンターを使用します。To learn the current size of the recovery queue, use the Recovery Queue performance counter. 詳細については、「 SQL Server、Database Replica」を参照してください。For more information, see SQL Server, Database Replica.

    注意

    復旧キューのサイズを制限することでフェールオーバーの時間を調節できます。The failover time can be regulated by limiting the size of the recovery queue. ただし、セカンダリ レプリカの遅れを取り戻すためにプライマリ レプリカの処理速度が低下する場合があります。However, this can cause the primary replica to slow down to allow the secondary replica to keep up.

  3. セカンダリ レプリカは新しいプライマリ レプリカになり、元のプライマリ レプリカは新しいセカンダリ レプリカになります。The secondary replica becomes the new primary replica, and the former primary replica becomes the new secondary replica.

  4. 新しいプライマリ レプリカでは、コミットされていないトランザクションがすべてロールバックされ、そのデータベースがプライマリ データベースとしてオンラインになります。すべてのセカンダリ データベースは、新しいプライマリ データベースに接続されて再同期されるまでの短い間、NOT SYNCHRONIZED としてマークされます。The new primary replica rolls back any uncommitted transactions and brings its databases online as the primary databases.All secondary databases are briefly marked as NOT SYNCHRONIZED until they connect and resynchronize to the new primary databases. このプロセスでは、コミット済みのトランザクションはロールバックされません。This process does not roll back any committed transactions.

  5. 元のプライマリ レプリカはオンラインになるとセカンダリ ロールを引き継ぎ、元のプライマリ データベースがセカンダリ データベースになります。When the former primary replica comes back online, it takes on the secondary role, and the former primary database becomes the secondary database. 新しいセカンダリ レプリカによって、新しいセカンダリ データベースが対応するプライマリ データベースと迅速に再同期されます。The new secondary replica quickly resynchronizes the new secondary databases with the corresponding primary databases.

    注意

    新しいセカンダリ レプリカのデータベースの再同期が完了すると、その時点から、反対方向のフェールオーバーを実行できるようになります。As soon as the new secondary replica has resynchronized the databases, failover is again possible, but in the reverse direction.

フェールオーバー後は、クライアントから現在のプライマリ データベースに再接続する必要があります。After failover, clients must reconnect to the current primary database. 詳細については、「 可用性グループ リスナー、クライアント接続、およびアプリケーションのフェールオーバー (SQL Server)での 1 つ以上の可用性グループの構成と管理において重要です。For more information, see Availability Group Listeners, Client Connectivity, and Application Failover (SQL Server).

アップグレード中の可用性の維持Maintaining Availability During Upgrades

可用性グループのデータベース管理者は、手動フェールオーバーを使用することにより、ハードウェアまたはソフトウェアのアップグレード時にデータベースの可用性を維持できます。The database administrator for your availability groups can use manual failovers to maintain database availability when you upgrade hardware or software. ソフトウェア アップグレードのために可用性グループを使用するには、対象のセカンダリ レプリカがホストされているサーバー インスタンスまたはコンピューター ノードでアップグレードが受信済みである必要があります。To use an availability group for software upgrades, the server instance and/or computer node that hosts the target secondary replica must have already received the upgrades. 詳細については、「 AlwaysOn 可用性グループのレプリカ インスタンスのアップグレード」を参照してください。For more information, see Upgrading Always On Availability Group Replica Instances.

強制フェールオーバー (データ損失の可能性あり)Forced Failover (with Possible Data Loss)

可用性グループの強制フェールオーバー (データ損失の可能性あり) は、セカンダリ レプリカをウォーム スタンバイ サーバーとして使用できる災害復旧方法です。フェールオーバーを強制するとデータを損失する可能性があるので、強制フェールオーバーは注意深く慎重に使用してください。Forcing failover of an availability group (with possible data loss) is a disaster recovery method that allows you to use a secondary replica as a warm standby server.Because forcing failover risks possible data loss, it should be used cautiously and sparingly. 可用性データベースにサービスをすぐに復元する必要があり、データの損失を許容できる場合に限り、フェールオーバーを強制することをお勧めします。We recommend forcing failover only if you must restore service to your availability databases immediately and are willing to risk losing data. 強制フェールオーバーを実行するための前提条件と推奨事項の詳細、および強制フェールオーバーを使用して重大なエラーから復旧するサンプル シナリオについては、このトピックの「 可用性グループの強制手動フェールオーバーの実行 (SQL Server)と呼ばれるプロセスで交換されることがあります。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 Perform a Forced Manual Failover of an Availability Group (SQL Server).

警告

強制フェールオーバーでは、WSFC クラスターにクォーラムが必要です。Forcing failover requires that the WSFC cluster have quorum. クォーラム構成とクォーラムの強制の詳細については、「 Windows Server フェールオーバー クラスタリング (WSFC) と SQL Serverと呼ばれるプロセスで交換されることがあります。For information about configuring quorum and forcing quorum, see Windows Server Failover Clustering (WSFC) with SQL Server.

このセクションの内容In This Section:

強制フェールオーバーの動作How Forced Failover Works

フェールオーバーを強制すると、ロールが SECONDARY 状態または RESOLVING 状態であるターゲット レプリカにプライマリ ロールが移行されます。Forcing failover initiates a transition of the primary role to a target replica whose role is in the SECONDARY or RESOLVING state. フェールオーバー ターゲットは、新しいプライマリ レプリカになり、クライアントは直ちにデータベースのコピーを利用できるようになります。The failover target becomes the new primary replica and immediately serves its copies of the databases to clients. 元のプライマリ レプリカは使用可能になるとセカンダリ ロールに移行し、そのデータベースはセカンダリ データベースになります。When the former primary replica becomes available, it will transition to the secondary role and its databases will become secondary databases.

すべてのセカンダリ データベース (元のプライマリ データベースが使用可能になった場合は、そのプライマリ データベースを含む) が SUSPENDED 状態になります。All secondary databases (including the former primary databases, when they become available) are SUSPENDED. 中断状態のセカンダリ データベースの以前のデータ同期状態に応じて、そのプライマリ データベースの損失したコミット データを復旧することが適切な場合があります。Depending on the previous data synchronization state of a suspended secondary database, it might be suitable for salvaging missing committed data for that primary database. 読み取り専用アクセス用に構成されたセカンダリ レプリカで、セカンダリ データベースのクエリを実行して、損失したデータを手動で検出できます。On a secondary replica that is configured for read-only access, you can query the secondary databases to manually discover missing data. 次に、新しいプライマリ データベースで Transact-SQLTransact-SQL ステートメントを発行して、必要な変更を加えることができます。Then you can issue Transact-SQLTransact-SQL statements on the new primary databases to make any necessary changes.

強制フェールオーバーのリスクRisks of Forcing Failover

フェールオーバーの強制によってデータが失われる可能性があることを理解しておく必要があります。It is essential to understand that forcing failover can cause data loss. ターゲット レプリカがプライマリ レプリカと通信できなくなり、そのためにデータベースが必ずしも同期されなくなることが原因で、データが失われる可能性があります。Data loss is possible because the target replica cannot communicate with the primary replica and, therefore, cannot guarantee that the databases are synchronized. フェールオーバーを強制すると、新しい復旧分岐が始まります。Forcing failover starts a new recovery fork. 元のプライマリ データベースとセカンダリ データベースは別の復旧分岐に存在するので、それぞれのデータベースにはもう一方のデータベースには含まれていないデータが含まれることになります。つまり、それぞれの元のプライマリ データベースにはその送信キューから前のセカンダリ データベースに送信されなかったすべての変更 (未送信ログ) が含まれ、前のセカンダリ データベースには、フェールオーバーの強制後に行われたすべての変更が含まれます。Because the original primary databases and secondary databases are on different recovery forks, each of them now contains data that the other database does not contain: each original primary database contains whatever changes were not yet sent from its send queue to the former secondary database (the unsent log); the former secondary databases contain whatever changes occur after failover was forced.

プライマリ レプリカで障害が発生したためにフェールオーバーが強制された場合、データ損失があるかどうかは、障害発生前にセカンダリ レプリカに送信されたトランザクション ログがあるかどうかによって異なります。If failover is forced because the primary replica has failed, potential data loss depends on whether or not any transaction logs had been sent to the secondary replica before the failure. 非同期コミット モードの場合、蓄積された未送信ログがある場合は常にデータ損失の可能性があります。Under the asynchronous-commit mode, accumulated unsent log is always a possibility. 同期コミット モードの場合、この可能性があるのは、セカンダリ データベースが同期された状態になるまでの間だけです。Under synchronous-commit mode, this is possible only until the secondary databases become synchronized.

次の表に、フェールオーバーを強制するレプリカ上の特定のデータベースでのデータ損失の可能性をまとめます。The following table summarizes the possibility of data loss for a particular database on the replica to which you force failover.

セカンダリ レプリカの可用性モードAvailability mode of Secondary Replica データベースが同期しているかIs database synchronized? データが失われる可能性があるかIs data loss possible?
同期コミットSynchronous-commit Yes いいえNo
同期コミットSynchronous-commit いいえNo Yes
非同期コミットAsynchronous-commit いいえNo Yes

セカンダリ データベースは 2 つの復旧分岐のみを追跡するため、複数の強制フェールオーバーを実行した場合、前の強制フェールオーバーでデータの同期を開始しなかったセカンダリ データベースは再開できない場合があります。Secondary databases track only two recovery forks, so if you perform multiple forced failovers, any secondary database that did start data synchronization with the previous force failover might not be able to resume. この場合は、再開できないセカンダリ データベースを可用性グループから削除して、適切な時点まで復元した後で再度可用性グループに参加させる必要があります。If this occurs, any secondary databases that cannot be resumed will need to be removed from the availability group, restored to the correct point in time, and rejoined to the availability group. このシナリオでは、状態 103 のエラー 1408 が発生する可能性があります (エラー: 1408、重大度: 16、状態: 103)。Error 1408 with state 103 may be observed in this scenario (Error: 1408, Severity: 16, State: 103). 復元は複数の復旧分岐に対しては機能しないため、複数の強制フェールオーバーを実行した後に必ずログ バックアップを実行してください。A restore will not work across multiple recovery forks, therefore, be sure to perform a log backup after performing more than one forced failover.

クォーラムの強制後に強制フェールオーバーが必要な理由Why Forced Failover is Required After Forcing Quorum

WSFC クラスターでクォーラムが強制された後 ("強制クォーラム")、各可用性グループで強制フェールオーバー (データ損失の可能性あり) を実行する必要があります。After quorum is forced on the WSFC cluster (forced quorum) you need to perform a forced failover (with possible data loss) on each availability group. 強制フェールオーバーが必要なのは、WSFC クラスター値の実際の状態が失われている可能性があるためです。The forced failover is required because the real state of the WSFC cluster values might have been lost. 再構成された WSFC クラスターで非同期のセカンダリ レプリカが同期されたように見える可能性があるため、強制クォーラムの後に通常のフェールオーバーが実行されるのを防ぐ必要があります。Preventing normal failovers after a forced quorum is required because of the possibility than an unsynchronized secondary replica would appear to be synchronized on the reconfigured WSFC cluster.

たとえば、3 つのノードで可用性グループをホストする WSFC クラスターについて考えてみます。ノード A はプライマリ レプリカをホストし、ノード B とノード C はそれぞれセカンダリ レプリカをホストします。For example, consider a WSFC cluster that hosts an availability group on three nodes: Node A hosts the primary replica and Node B and Node C each hosts a secondary replica. ノード C は、ローカル セカンダリ レプリカが SYNCHRONIZED 状態の間に WSFC クラスターから切断されます。Node C gets disconnected from the WSFC cluster while the local secondary replica is SYNCHRONIZED. ただし、ノード A とノード B では正常なクォーラムが保持され、可用性グループはオンラインのままになります。But Node A and Node B retain a healthy quorum and the availability group remains online. ノード A では、プライマリ レプリカが引き続き更新を受け入れ、ノード B では、セカンダリ レプリカが引き続きプライマリ レプリカと同期されます。On Node A, the primary replica continues to accept updates, and on Node B, the secondary replica continues to synchronize with the primary replica. ノード C のセカンダリ レプリカは同期されなくなり、プライマリ レプリカからしだいに遅れが生じます。The secondary replica on Node C becomes unsynchronized and falls increasingly behind the primary replica. ただし、ノード C は切断されているため、レプリカは誤って SYNCHRONIZED 状態のままになります。However, because Node C is disconnected, the replica remains, incorrectly, in the SYNCHRONIZED state.

ノード A でクォーラムが失われた後に強制された場合は、WSFC クラスター上の可用性グループの同期の状態は正しい状態になる必要があります。つまり、ノード C のセカンダリ レプリカは UNSYNCHRONIZED 状態として示される必要があります。If quorum is lost and is then forced on Node A, the synchronization state of the availability group on the WSFC cluster should be correct-with the secondary replica on Node C shown as UNSYNCHRONIZED. ただし、ノード C でクォーラムが強制された場合、可用性グループの同期は正しくなくなります。However, if quorum is forced on Node C, the synchronization of the availability group will be incorrect. クラスターの同期の状態は、ノード C が切断された時点まで戻ります。つまり、ノード C のセカンダリ レプリカは誤って SYNCHRONIZED 状態として示されます。The synchronization state on the cluster will have reverted back to when Node C was disconnected-with the secondary replica on Node C incorrectly shown as SYNCHRONIZED. 計画的な手動フェールオーバーはデータの安全性を保証するため、クォーラムの強制後に可用性グループをオンラインに戻すために使用することはできません。Since planned manual failovers guarantee the safety of the data, they are disallowed for bring an availability group back online after quorum is forced.

データ損失の可能性の追跡Tracking Potential Data Loss

WSFC クラスターに正常なクォーラムがある場合、データベースのデータが損失する現在の可能性を推測することができます。When the WSFC cluster has a healthy quorum, you can estimate the current potential for data loss on databases. 特定のセカンダリ レプリカの場合、データ損失の現在の可能性は、ローカル セカンダリ データベースが対応するプライマリ データベースにどの程度遅れているかによって決まります。For a given secondary replica, the current potential for data loss depends on how far the local secondary databases are lagging behind the corresponding primary databases. 遅延の程度は時間の経過と共に変化するため、非同期のセカンダリ データベースについてデータ損失の可能性を定期的に追跡することをお勧めします。Because the amount of lag varies over time, we recommend that you periodically track potential data loss for your unsynchronized secondary databases. 遅延を追跡するには、次のように、各プライマリ データベースとそのセカンダリ データベースの最後にコミットした LSN および最終コミット時間を比較する必要があります。Tracking lag involves comparing the Last Commit LSN and Last Commit Time for each primary database and its secondary databases, as follows:

  1. プライマリ レプリカに接続します。Connect to the primary replica.

  2. sys.dm_hadr_database_replica_states 動的管理ビューの last_commit_lsn (最後にコミットされたトランザクションの LSN) 列および last_commit_time (最終コミット時間) 列に対してクエリを実行します。Query the last_commit_lsn (LSN of the last committed transaction) and last_commit_time (time of the last commit) columns of the sys.dm_hadr_database_replica_states dynamic management view.

  3. 各プライマリ データベースとその各セカンダリ データベースに返された値を比較します。Compare the values returned for each primary database and each of its secondary databases. 最後にコミットした LSN の差異は、遅延の程度を示します。The difference between their Last Commit LSNs indicate the amount of lag.

  4. 1 つのデータベースまたは一連のデータベースでの遅延の程度が一定期間、指定した遅延の最大値を超えた場合に、警告を表示させることができます。You can trigger an alert when the amount of lag on a database or set of databases exceeds your desired maximum lag for a given period of time. たとえば、クエリは、各プライマリ データベースで 1 分ごとに実行されるジョブによって実行できます。For example, the query can be run by a job that executes every minute on each primary database. プライマリ データベースとそのセカンダリ データベースの last_commit_time の差異が、最後にジョブが実行された後に目標復旧ポイント (RPO) (たとえば、5 分) を超えた場合、ジョブは警告を生成できます。If the difference between the last_commit_time of a primary database and any of its secondary databases has exceeded the recovery point objective (RPO) (for example, 5 minutes) since the last time the job executed, the job can raise an alert.

重要

WSFC クラスターにクォーラムが存在しない場合またはクォーラムが強制されている場合は、 last_commit_lsnlast_commit_time は NULL になります。When the WSFC cluster lacks quorum or quorum has been forced, last_commit_lsn and last_commit_time are NULL. クォーラム強制後のデータ損失を回避する方法の詳細については、「 可用性グループの強制手動フェールオーバーの実行 (SQL Server)と呼ばれるプロセスで交換されることがあります。For information about how you might be able to avoid data loss after you forced quorum, see "Potential Ways to Avoid Data Loss After Quorum is Forced" in Perform a Forced Manual Failover of an Availability Group (SQL Server).

データ損失の可能性への対処Managing the Potential Data Loss

フェールオーバーの強制後は、すべてのセカンダリ データベースが中断されます。After failover is forced, 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.

前のプライマリ レプリカが使用可能になると、そのデータベースは破損していないと想定されるので、データ損失の可能性に対処できます。Once the former primary replica is available, assuming that its databases are undamaged, you can attempt to manage the potential data loss. データ損失の可能性に対処するために使用できる方法は、元のプライマリ レプリカが新しいプライマリ レプリカに接続されたかどうかによって異なります。The available approach for managing potential data loss depends on whether the original primary replica has connected to the new primary replica. 元のプライマリ レプリカが新しいプライマリ インスタンスにアクセスできる場合、自動的かつ透過的に再接続されます。Assuming that the original primary replica can access the new primary instance, reconnecting occurs automatically and transparently.

元のプライマリ レプリカが再接続された場合The Original Primary Replica Has Reconnected

通常、障害発生後は、元のプライマリ レプリカは再起動するとすぐに、パートナーに再接続します。Typically, after a failure, when the original primary replica restarts it quickly reconnects to its partner. 再接続時に、元のプライマリ レプリカがセカンダリ レプリカになります。On reconnecting, the original primary replica becomes the secondary replica. そのデータベースはセカンダリ データベースになり、SUSPENDED 状態になります。Its databases becomes the secondary databases and enter the SUSPENDED state. 新しいセカンダリ データベースは、データベースを再開しない限り、ロールバックされません。The new secondary databases will not be not rolled back unless you resume them.

ただし、中断されたデータベースにはアクセスできないため、データベースを調査しても、指定されたデータベースを再開したときに失われるデータを評価することはできません。However, the suspended databases are inaccessible, so you cannot inspect them to evaluate what data would be lost if you were to resume a given database. そのため、セカンダリ データベースを再開するか削除するかは、次に示すようにデータの損失を許容できるかどうかによって決まります。Therefore, the decision on whether to resume or remove a secondary database depends on whether you are willing to accept any data loss, as follows:

  • データの損失を許容できない場合は、データベースを可用性グループから削除して、データベースを復旧する必要があります。If losing any data would be unacceptable, you should remove the databases from the availability group to salvage them.

    データベース管理者は元のプライマリ データベースを復旧し、失われる可能性のあるデータの復旧を試みることができるようになります。The database administrator can now recover the former primary databases and attempt to recover the data that would have been lost. ただし、元のプライマリ データベースがオンラインになったときに、そのデータベースは現在のプライマリ データベースとは一致しません。そのため、データベース間の不一致が拡大するのを防ぎ、クライアントのフェールオーバーの問題を回避するために、データベース管理者は削除されたデータベースまたは現在のプライマリ データベースにクライアントがアクセスできないようにする必要があります。However, when a former primary database comes online, it is divergent from the current primary database, so the database administrator needs to make either the removed database or the current primary database inaccessible to clients to avoid further divergence of the databases and to prevent client-failover issues.

  • ビジネス目標を考慮してもデータの損失を許容できる場合は、セカンダリ データベースを再開できます。If losing data would be acceptable to your business goals, you can resume the secondary databases.

    新しいセカンダリ データベースを再開すると、データベース同期の最初のステップとしてこのデータベースがロールバックされます。Resuming a new secondary database causes it to be rolled back as the first step in synchronizing the database. 障害発生時にログ レコードが送信キューで待機していた場合、対応するトランザクションはコミットされていた場合でも失われます。If any log records were waiting in the send queue at the time of failure, the corresponding transactions are lost, even if they were committed.

元のプライマリ レプリカが再接続されなかった場合The Original Primary Replica Has Not Reconnected

元のプライマリ レプリカが新しいプライマリ レプリカにネットワーク経由で再接続するのを一時的に防ぐことができる場合、元のプライマリ データベースを調査して、データベースが再開されたらどのデータが失われるのかを評価できます。If you can temporarily prevent the original primary replica from reconnecting over the network to the new primary replica, you can inspect the original primary databases to evaluate what data would be lost if they were resumed.

  • データ損失が許容される場合If the potential data loss is acceptable

    元のプライマリ レプリカから新しいプライマリ レプリカへの再接続を許可します。Allow the original primary replica to reconnect to the new primary replica. 再接続によって新しいセカンダリ データベースが中断されます。Reconnecting causes the new secondary databases to be suspended. データベースのデータの同期を開始するには、単にそれを再開します。To start data synchronization on a database, simply resume it. 新しいセカンダリ レプリカがそのデータベースの元の復旧分岐を削除し、以前のセカンダリ レプリカに送信されなかったか以前のセカンダリ レプリカによって受信されなかったすべてのトランザクションが失われます。The new secondary replica drops the original recovery fork for that database, losing any transactions that were never sent to or received by the former secondary replica.

  • データ損失が許容されない場合If the data loss is unacceptable

    中断されたデータベースを再開したら失われる重要なデータが元のプライマリ データベースに含まれている場合、そのデータベースを可用性グループから削除することにより元のプライマリ データベース上のデータを保持できます。If the original primary database contains critical data that would be lost if you resumed the suspended database, you can preserve the data on the original primary database by removing it from the availability group. これにより、データベースが RESTORING 状態になります。This causes the database to enter the RESTORING state. この時点で、削除されたデータベースのログの末尾をバックアップしておくことをお勧めします。At this point, we recommend that you attempt to back up the tail of the removed database's log. その後、復旧するデータを元のプライマリ データベースからエクスポートして、そのデータを現在のプライマリ データベースにインポートすることにより、現在のプライマリ データベース (前のセカンダリ データベース) を更新できます。Then, you can update the current primary (the former secondary database) by exporting the data you want to salvage from the original primary database and importing it into the current primary database. 更新されたプライマリ データベースの完全バックアップを、できるだけ早く実行することをお勧めします。We recommend taking a full database backup of the updated primary database as quickly as possible.

    その後で、RESTORE WITH NORECOVERY を使用してこのバックアップ (および 1 つ以上の後続ログ バックアップ) を復元することにより、新しいセカンダリ レプリカをホストするサーバー インスタンスで、中断されたセカンダリ データベースを削除して新しいセカンダリ データベースを作成することができます。Then, on the server instance that hosts the new secondary replica, you can delete the suspended secondary database and create a new secondary database by restoring this backup (and least one subsequent log backup) using RESTORE WITH NORECOVERY. 対応するセカンダリ データベースを再開するまで、現在のプライマリ データベースの追加のログ バックアップを遅らせることをお勧めします。We recommend delaying additional log backups of the current primary databases until the corresponding secondary databases are resumed.

警告

プライマリ データベースでは、いずれかのセカンダリ データベースが中断している間は、トランザクション ログの切り捨てが遅延されます。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.

関連タスクRelated Tasks

フェールオーバーの動作を設定するにはTo configure failover behavior

手動フェールオーバーを実行するにはTo perform a manual fail over

WSFC クォーラムの構成を設定するにはTo configure WSFC Quorum Configuration

関連コンテンツRelated Content

参照See Also

AlwaysOn 可用性グループの概要 (SQL Server) Overview of Always On Availability Groups (SQL Server)
可用性モード (AlwaysOn 可用性グループ) Availability Modes (Always On Availability Groups)
Windows Server フェールオーバー クラスタリング (WSFC) と SQL Server Windows Server Failover Clustering (WSFC) with SQL Server
AlwaysOn 可用性グループとデータベース ミラーリングでの複数データベースにまたがるトランザクションと分散トランザクション (SQL Server) Cross-Database Transactions and Distributed Transactions for Always On Availability Groups and Database Mirroring (SQL Server)
フェールオーバー クラスター インスタンスのフェールオーバー ポリシー Failover Policy for Failover Cluster Instances
可用性グループの自動フェールオーバーのための柔軟なフェールオーバー ポリシー (SQL Server)Flexible Failover Policy for Automatic Failover of an Availability Group (SQL Server)