データベース ミラーリング セッションのコンテキスト内では、プリンシパル ロールとミラー ロールは、通常、 ロールの切り替えと呼ばれるプロセスで交換可能です。 ロールの切り替えでは、ミラー サーバーはプリンシパル サーバーの フェールオーバー パートナー として機能し、プリンシパル ロールを引き継ぎ、データベースのコピーを回復し、新しいプリンシパル データベースとしてオンラインにします。 以前のプリンシパル サーバーは、使用可能な場合はミラー ロールを引き受け、そのデータベースは新しいミラー データベースになります。 場合によっては、複数の障害に対応するか、管理目的でロールを切り替えることができます。
注
このトピックでは、データベース ミラーリングの動作モードについて理解していることを前提としています。 詳細については、「 データベース ミラーリングの動作モード」を参照してください。
次の図は、ミラーリング パートナー、 Partner_A 、 Partner_B、プリンシパルロールとミラー ロールを一連の自動フェールオーバーまたは手動フェールオーバーに切り替える方法を示しています。
重要
ロールの切り替え後、以前のプリンシパル データベースで実行されたジョブは、新しいプリンシパル サーバーで再作成してそこで実行する必要があります。 詳細については、「 ロールの切り替え後のログインとジョブの管理 (SQL Server)」を参照してください。
ロールの切り替えには、自動フェールオーバー、手動フェールオーバー、強制サービス (データ損失の可能性あり) の 3 種類があります。 各フォームのサポートは、セッションの動作モードによって異なります。
注
これらの動作モードに慣れていない場合は、「 データベース ミラーリングの動作モード」を参照してください。
手動フェールオーバー
高い安全性モードでは、手動フェールオーバーがサポートされます。 データベースが同期されるたびに、データベース所有者は手動フェールオーバーを開始できます。
手動フェールオーバーは管理目的で提供されます。 詳細については、このトピックで後述する 「手動フェールオーバー」を参照してください。
自動フェールオーバー
証人が存在する場合、高安全性モードでは自動フェールオーバーがサポートされます。 自動フェールオーバーは、プリンシパルサーバーが障害を起こし、監視サーバーとミラーサーバーがまだ相互に接続されていて、データベースが既に同期されている場合にのみ発生します。 詳細については、このトピックの「 自動フェールオーバー」を参照してください。
強制サービス (データ損失の可能性あり)
ミラーリング監視サーバーが設定されていない場合および高パフォーマンスモードでは、強制サービスが高い安全性を保ちながらサポートされます。 プリンシパル サーバーが失われた場合、データベース所有者は、サービスをミラー サーバーに強制することでデータベースを使用できるようになります (データ損失の可能性があります)。
注
高パフォーマンス モードでは、WITNESS プロパティを OFF に設定することをお勧めします。 それ以外の場合、データベースをオンラインにするには、ミラーサーバーが監視サーバーに接続されている必要があります。
詳細については、このトピックで後述する強制 サービス (データ損失の可能性あり) を参照してください。
次の表は、各動作モードでサポートされているフェールオーバーの形式をまとめたものです。
| 高パフォーマンス | 監視なしの高い安全性モード | 証人を伴う高安全モード | |
|---|---|---|---|
| 自動フェールオーバー | いいえ | いいえ | イエス |
| 手動フェールオーバー | いいえ | イエス | イエス |
| 強制サービス | イエス | イエス | いいえ |
ロールの切り替え後、すべてのデータベース ユーザーが新しいプリンシパル データベースにアクセスできるように、両方のパートナーに特定のメタデータが存在する必要があります。 さらに、データベースが定期的なスケジュールに従ってバックアップされるように、バックアップ ジョブを新しいプリンシパル サーバーに作成する必要があります。 詳細については、「 ロールの切り替え後のログインとジョブの管理 (SQL Server)」を参照してください。
ロールの切り替え中に、データベース ミラーリングがサービスから外される時間は、ロールの切り替えの種類と原因によって異なります。 詳細については、「 ロールの切り替え中のサービスの中断の見積もり (データベース ミラーリング)」を参照してください。
手動フェールオーバー
手動フェールオーバーでは、クライアントがデータベースから切断され、パートナーのロールが逆になります。 手動フェールオーバーは、高い安全性モードでのみサポートされます。
アップグレード中の可用性の維持
データベース管理者は、可用性を損なうことなく、ハードウェアまたはソフトウェアのアップグレードに手動フェールオーバーを使用できます。 ソフトウェアのアップグレードにデータベース ミラーリングを使用するには、ミラー サーバーまたはシステムが既にアップグレードを受け取っている必要があります。
注
データベース ミラーリングではローリング アップグレードを実行できる必要がありますが、将来の変更は不明であるため、これは保証されません。 詳細については、「 サーバー インスタンスをアップグレードするときのミラー化されたデータベースのダウンタイムを最小限に抑える」を参照してください。
次の図は、データベース サーバー インスタンスをアップグレードするときに、手動フェールオーバーを使用してデータベースの可用性を維持するインスタンスを示しています。 アップグレードが完了すると、管理者は必要に応じて元のサーバー インスタンスにフェールオーバーできます。 これは、管理者がミラーリング セッションを停止し、他の場所でミラー サーバーを使用する場合に便利です。 この方法では、一連のデータベース サーバー インスタンスを更新するときに、1 つのサーバー インスタンスを繰り返し使用できます。
手動フェールオーバーに必要な条件
手動フェールオーバーでは、トランザクションの安全性を FULL (つまり、高い安全性モード) に設定する必要があります。 パートナーが接続されていて、データベースが既に同期されている場合は、手動フェールオーバーがサポートされます。
手動フェールオーバーのしくみ
手動フェールオーバーでは、次の一連のアクションが開始されます。
プリンシパル サーバーは、プリンシパル データベースからクライアントを切断し、ログの末尾をミラー サーバーに送信し、ミラー ロールに切り替える準備として、ミラーリング状態を SYNCHRONIZING に設定します。
ミラー サーバーは、フェールオーバー LSN としてプリンシパルから受信した最後のログ レコードのログ シーケンス番号 (LSN) を記録します。
注
この LSN を表示するには、 sys.database_mirroring(Transact-SQL) からmirroring_failover_lsn列を選択します。
再実行キューで待機しているログがある場合、ミラー サーバーはミラー データベースのロール フォワードを完了します。 必要な時間は、システムの速度、最近のワークロード、再実行キュー内のログの量によって異なります。 同期動作モードの場合、再実行キューのサイズを制限することで、フェールオーバー時間を調整できます。 ただし、これにより、プリンシパル サーバーの速度が低下して、ミラー サーバーが追いつく可能性があります。
注
再実行キューの現在のサイズについては、データベース ミラーリング パフォーマンス オブジェクトの Redo Queue パフォーマンス カウンターを使用します (詳細については、 データベース ミラーリングの監視 (SQL Server) を参照してください)。
ミラー サーバーが新しいプリンシパル サーバーになり、前のプリンシパル サーバーが新しいミラー サーバーになります。
新しいプリンシパル サーバーは、コミットされていないトランザクションをロールバックし、データベースのコピーをプリンシパル データベースとしてオンラインにします。
前者のプリンシパルがミラー の役割を担い、前のプリンシパル データベースがミラー データベースになります。 新しいミラー サーバーは、新しいミラー データベースと新しいプリンシパル データベースをすばやく再同期します。
注
新しいミラー サーバーがデータベースを再同期するとすぐに、フェールオーバーは再び可能になりますが、逆方向になります。
フェールオーバー後、クライアントは現在のプリンシパル データベースに再接続する必要があります。 詳細については、「 データベース ミラーリング セッションへのクライアントの接続 (SQL Server)」を参照してください。
手動フェールオーバーを開始するには
自動フェールオーバー
自動フェールオーバーは、高い安全性モード (自動フェールオーバーを使用した高い安全性モード) でミラーリング監視サーバーを使用して実行されているデータベース ミラーリング セッションでのみサポートされます。 自動フェールオーバーを使用する高い安全性モードでは、データベースが同期されると、プリンシパル データベースが使用できなくなった場合、自動フェールオーバーが発生します。 自動フェールオーバーにより、ミラー サーバーはプリンシパル サーバーの役割を引き継ぎ、データベースのコピーをプリンシパル データベースとしてオンラインにします。 プリンシパル データベースでコミットされたすべてのトランザクションはミラー データベースでもコミットされるため、データベースの同期を要求すると、フェールオーバー中にデータが失われるのを防ぐことができます。
重要
自動フェールオーバーを使用して信頼性を向上させるには、ミラー データベースとプリンシパル データベースが異なるコンピューター上に存在する必要があります。
自動フェールオーバーに必要な条件
自動フェールオーバーには、次の条件が必要です。
データベース ミラーリング セッションは、高安全性モードで実行される必要があり、ミラーリングの証人を持っている必要があります。 詳細については、「 データベース ミラーリングの動作モード」を参照してください。
ミラー データベースは既に同期されている必要があります。 これにより、ミラー サーバーに送信されたすべてのログがディスクに書き込まれることが保証されます。
プリンシパルサーバーは他のデータベースミラーリング構成との通信を失いましたが、ミラーと証人サーバーはクォーラムを維持しています。 ただし、すべてのサーバー インスタンスが通信を失い、証人サーバーとミラーサーバーが後で通信を回復した場合、自動フェールオーバーは発生しません。
注
詳細については、「クォーラム: 監視サーバーがデータベース可用性に与える影響（データベースミラーリング）」を参照してください。
ミラー サーバーがプリンシパル サーバーの損失を検出しました。
ミラー サーバーがプリンシパル サーバーの障害を検出する方法は、それがハード障害かソフト 障害かによって異なります。 詳細については、「 データベース ミラーリング中に発生する可能性のあるエラー」を参照してください。
自動フェールオーバーの動作
上記の条件では、自動フェールオーバーによって次の一連のアクションが開始されます。
プリンシパル サーバーがまだ実行されている場合は、プリンシパル データベースの状態が DISCONNECTED に変更され、プリンシパル データベースからすべてのクライアントが切断されます。
ミラーリング監視サーバーとミラー サーバーは、プリンシパル サーバーが使用できないことを登録します。
再実行キューで待機しているログがある場合、ミラー サーバーはミラー データベースのロール フォワードを完了します。
注
ログの適用に必要な時間は、システムの速度、最近の作業負荷、再実行キュー内のログの量によって異なります。
以前のミラー データベースは新しいプリンシパル データベースとしてオンラインに移行し、復旧では、コミットされていないすべてのトランザクションをできるだけ早くロールバックすることでクリーンアップします。 ロックによって、これらのトランザクションが分離されます。
以前のプリンシパル サーバーがセッションに再び参加すると、フェールオーバー パートナーがプリンシパル ロールを所有していることを認識します。 前者のプリンシパル サーバーはミラーの役割を担い、そのデータベースをミラー データベースにします。 新しいミラー サーバーは、新しいミラー データベースを可能な限り迅速にプリンシパル データベースと同期します。 新しいミラー サーバーがデータベースを再同期するとすぐに、フェールオーバーは再び可能になりますが、逆方向になります。
次の図は、自動フェールオーバーの 1 つのインスタンスを示しています。
最初は、3 つのサーバーすべてが接続されています (セッションには完全なクォーラムがあります)。 Partner_A はプリンシパル サーバーであり、 Partner_B はミラー サーバーです。 Partner_A (または Partner_A 上のプリンシパル データベース) が使用できなくなります。 目撃者とPartner_Bは、プリンシパルが不在となり、セッションが依然として定足数を維持していることを認識しています。 Partner_B がプリンシパル サーバーになり、データベースのコピーが新しいプリンシパル データベースとして使用できるようになります。 最終的に、 Partner_A セッションに再接続し、 Partner_B がプリンシパル ロールを所有していることを検出します。 Partner_A ミラーの役割を担います。
フェールオーバー後、クライアントは現在のプリンシパル データベースに再接続する必要があります。 詳細については、「 データベース ミラーリング セッションへのクライアントの接続 (SQL Server)」を参照してください。
注
Microsoft 分散トランザクション コーディネーターを使用して準備されたが、フェールオーバーが発生してもコミットされないトランザクションは、データベースのフェールオーバー後に中止されたと見なされます。
自動フェールオーバーを無効にするには (SQL Server Management Studio)
[データベースのプロパティ] ページを開き、次のいずれかのオプションを選択して操作モードを変更します。
[自動フェールオーバーを伴わない高い安全性 (同期)]
このモードでは、データベースは引き続き同期され、手動フェールオーバーは引き続き可能です。
[高パフォーマンス (非同期)]
このモードでは、ミラー データベースがプリンシパル データベースより多少遅れる可能性があり、手動フェールオーバーはできなくなります。
自動フェールオーバーを無効にするには (Transact-SQLを使用)
データベース ミラーリング セッションの任意の時点で、データベース所有者はミラーリング監視サーバーをオフにすることで、自動フェールオーバーを無効にすることができます。
ミラーリング監視サーバーをオフにするには
データベース ミラーリング セッションからのWitnessの削除 (SQL Server)
注
完全なトランザクションの安全性を維持しながらミラーリング監視サーバーをオフにすると、自動フェールオーバーなしでセッションが高い安全性モードになります。
強制サービス (データ損失の可能性あり)
データベース ミラーリングは、ミラー サーバーをウォーム スタンバイ サーバーとして使用できるようにするためのディザスター リカバリー方法として、強制サービス (データ損失の可能性あり) を提供します。 サービスの強制は、プリンシパル サーバーがミラーリング セッションでミラー サーバーから切断されている場合にのみ可能です。 サービスを強制するとデータが失われる可能性があるため、慎重かつ控えめに使用する必要があります。
強制サービスのサポートは、次のように、動作モードとセッションの状態によって異なります。
通常、ハイ パフォーマンス モードでは、プリンシパル サーバーが切断されるたびにサービスの強制がサポートされます。 しかし、不必要であるにもかかわらず、高性能モードのセッションに証人が存在する可能性があります。 この場合、サービスを強制するには、ミラー サーバーとミラーリング監視サーバーが相互に接続されている必要があります。
自動フェールオーバーのない高い安全性モードでは、プリンシパル サーバーが切断されるたびにサービスの強制がサポートされます。
高安全性モードでは、ミラーサーバーと監視サーバーが相互に接続され、どちらもプリンシパルサーバーに接続されていない場合に、自動フェールオーバーによるサービスの強制がサポートされます（ミラーサーバーが最後にプリンシパルサーバーに接続された際にミラーデータベースをロールバック中でなければ）。
サービスを強制するのは、サービスをデータベースに直ちに復元する必要があり、データが失われるリスクを負う可能性がある場合のみです。 サービスを強制する効果はミラーリングの削除に似ていますが、ミラーリングを再開すると、データが失われる可能性があるリスクで、サービスの強制によってデータベースの再同期が容易になる点が異なります。 サービスを強制すると、プリンシパル ロールからミラー データベースへのスムーズな移行が開始されます。 ミラー サーバーはプリンシパル サーバーの役割を引き受け、データベースのコピーをクライアントに直ちに提供します。 新しいプリンシパル データベースは、ミラーなしで実行されます (つまり、公開されている状態で実行されます)。
重要
プリンシパル サーバーがデータベース ミラーリング セッションから切断されただけで、まだ実行されている場合、一部のクライアントは元のプリンシパル データベースに引き続きアクセスする可能性があります。 サービスを強制する前に、クライアントが元のプリンシパル サーバーにアクセスできないようにすることが重要です。 それ以外の場合、サービスが強制された後、元のプリンシパル データベースと現在のプリンシパル データベースは、他のプリンシパル データベースとは別に更新される可能性があります。
強制サービスの一般的なケース
次の図は、強制サービスの一般的なケースを示しています (データ損失の可能性があります)。
図では、元のプリンシパルサーバーPartner_AがミラーサーバーPartner_Bに対して使用できなくなり、ミラーデータベースが切断されます。 Partner_Aがクライアントで使用できないことを確認した後、データベース管理者は、データ損失の可能性があるサービスをPartner_Bに強制します。 Partner_B がプリンシパル サーバーになり、データベースが 公開された 状態で実行されます (つまり、ミラー化されていません)。 この時点で、クライアントは Partner_Bに再接続できます。
Partner_A使用可能になると、新しいプリンシパル サーバーに再接続し、セッションに再び参加し、ミラー ロールを引き受けます。 ミラーリング セッションはすぐに中断され、新しいミラー データベースは同期されません。 セッションを中断すると、データベース管理者はセッションを再開するか、極端な場合はミラーリングを削除し、以前のプリンシパル データベースからデータをサルベージするかを決定できます。 この場合、データベース管理者はミラーリングの再開を選択します。 その時点で、 Partner_A はミラー サーバーの役割を引き継ぎ、前回正常に同期されたトランザクションの時点まで前のプリンシパル データベースをロールバックします。コミットされたトランザクションが、サービスが強制される前にミラー サーバー上のディスクに書き込まれなかった場合、トランザクションは失われます。 Partner_A 、新しいミラー サーバーが新しいプリンシパル サーバーになった後に新しいプリンシパル データベースに加えられた変更を適用して、新しいミラー データベースをロールフォワードします。
注
高パフォーマンス モードではミラーリング監視サーバーは必要ありませんが、ミラーリング監視サーバーが構成されている場合は、ミラーリング監視サーバーが現在接続されている場合にのみサービスの強制が可能です。
サービスを強制するリスク
サービスを強制するとデータが失われる可能性があることを理解することが不可欠です。 ミラー サーバーがプリンシパル サーバーと通信できないため、データ損失が発生する可能性があります。そのため、2 つのデータベースが同期されることを保証できません。 サービスを再起動すると、新しいリカバリフォークが生成されます。 元のプリンシパル データベースとミラー データベースは異なる復旧フォーク上にあるため、各データベースには、他のデータベースにはないデータが含まれるようになりました。元のプリンシパル データベースには、送信キューから以前のミラー データベース (未送信ログ) にまだ送信されなかった変更が含まれています。以前のミラー データベースには、サービスが強制された後に発生した変更が含まれます。
プリンシパル サーバーが失敗したためにサービスが強制された場合、潜在的なデータ損失は、障害が発生する前にトランザクション ログがミラー サーバーに送信されなかったかどうかによって異なります。 高い安全性モードでは、これはミラー データベースが同期されるまで可能です。 ハイパフォーマンスモードでは、蓄積された未送信ログが常に生じる恐れがあります。
サービスを強制することの影響は、セッションに証人サーバーがあるかどうかによって一部異なります。
証人がいない場合、例えばネットワーク接続が切断されたためにパートナーが切断された場合、サービスを強制することができます。 元のプリンシパル サーバーがまだ実行されている場合は、両方のパートナーがプリンシパル ロールを所有します。 新しいプリンシパル サーバーに接続しているクライアントはデータベースの現在のバージョンにアクセスしますが、元のプリンシパル サーバーに接続しているクライアントは元のプリンシパル データベースにアクセスします。 この状況により、データ損失の可能性が高くなります。 パートナーが再接続を許可されている場合、元のプリンシパル サーバーはミラーの役割を引き受け、ミラーリングが中断される前にデータベースの状態を "回復" に変更します。 セッションが再開されると、最新の切断の時点でログが送信キューにあった元のプリンシパル データベース上のトランザクションが失われます。 さらに、サービスが強制された後に発生したトランザクションも失われます。
監視サーバーが存在する場合、ミラーサーバーがプリンシパルサーバーと監視サーバーの両方から切断されていても、後者の2つが互いに接続されている限り、プリンシパルサーバーは単独で稼働します。 プリンシパル サーバーがミラーリング監視サーバーから切断されると、データベースの提供が停止します。 その後、ミラーサーバーが証人サーバーに再接続すると、強制サービスが可能になります。 サービスが強制された場合、元のプリンシパル サーバーが再接続されると、元のプリンシパル サーバーの実行中に行われたすべての変更が失われます。
詳細については、このトピックで後述 する「潜在的なデータ損失の管理」を参照してください。
データ損失の可能性への対処
サービスが強制された後、以前のプリンシパル サーバーが使用可能になると、データベースが破損していないと仮定して、潜在的なデータ損失の管理を試みることができます。 データ損失の可能性を管理するために使用できる方法は、元のプリンシパル サーバーがパートナーに再接続し、ミラーリング セッションに再び参加したかどうかによって異なります。 元のプリンシパル サーバーが新しいプリンシパル インスタンスにアクセスできる場合、再接続は自動的かつ透過的に行われます。
元のプリンシパル サーバーが再接続されました
通常、障害が発生した後、元のプリンシパル サーバーが再起動すると、パートナーにすばやく再接続します。 再接続すると、元のプリンシパル サーバーがミラー サーバーになります。 そのデータベースはミラー データベースになり、セッションが中断される前に復旧状態になります。 ミラーリングを再開しない限り、ミラー データベースはロールバックされません。
ただし、復旧データベースにはアクセスできません。そのため、ミラーリングを再開する場合に失われるデータを評価するために検査することはできません。 したがって、ミラーリングを再開または削除するかどうかの決定は、データ損失を受け入れるかどうかによって異なります。
データを失っても許容できない場合は、ミラーリングを削除して復旧する必要があります。
ミラーリングを削除すると、データベース管理者は元のプリンシパル データベースを回復し、失われたデータの復旧を試みられます。 ただし、元のミラー データベースがオンラインになると、元のパートナーは同じ名前の異なるデータベースにサービスを提供することになります。 データベース管理者は、データベースの相違を回避し、クライアントとフェールオーバーの問題を防ぐために、いずれかのデータベースにクライアントがアクセスできないようにする必要があります。
データを失っても問題ない場合は、ミラーリングを再開できます。
ミラーリングを再開すると、データベースの同期の最初の手順として新しいミラー データベースがロールバックされます。 障害発生時にログ レコードが送信キューで待機していた場合、対応するトランザクションはコミットされていた場合でも失われます。
元のプリンシパル サーバーが再接続されていない
元のプリンシパル サーバーがネットワーク経由で新しいプリンシパル サーバーに再接続するのを一時的に防止できる場合は、元のプリンシパル データベースを調べて、ミラーリングが再開された場合に失われるデータを評価できます。
データ損失が許容される場合
元のプリンシパル サーバーがパートナーに再接続できるようにします。 再接続すると、ミラーリングが中断されます。 ミラーリングを続行するには、セッションを再開するだけです。 前者のプリンシパル サーバーは、ミラーの役割を引き受けます。 新しいミラー サーバーは元の回復フォークを削除し、以前のミラー サーバーとの間で送受信されなかったトランザクションは失われます。
データ損失が許容されない場合
セッションを再開した場合に失われる重大なデータが元のプリンシパル データベースに含まれている場合は、ミラーリングを削除することで、元のプリンシパル サーバー上のデータを保持できます。 この時点で、プリンシパルのログの末尾をバックアップすることをお勧めします。 次に、元のプリンシパル データベースからサルベージするデータをエクスポートし、それを現在のプリンシパル データベースにインポートすることで、現在のプリンシパル (以前のミラー データベース) を更新できます。 更新されたデータベースの完全なデータベース バックアップをできるだけ早く作成することをお勧めします。
更新されたデータベースを初期プリンシパル データベースとしてミラーリングを再確立するには、このバックアップ (および 1 つ以上の後続のログ バックアップ) を使用して新しいミラー データベースを作成します。 ミラーリングが削除された後に実行されるすべてのログ バックアップを適用する必要があります。 そのため、新しいミラーリング セッションが開始されるまで、プリンシパル データベースの追加のログ バックアップを遅延することをお勧めします。
強制フェールオーバーを管理するための関連タスク
サービスを強制する
データベース ミラーリングを再開するには
新しいミラー データベースを作成するには
ミラーリングのためのミラー データベースの準備 (SQL Server)
データベース ミラーリングを開始するには
こちらもご覧ください
ロールの切り替え中のサービス中断の見積もり (データベース ミラーリング)
データベース ミラーリング中に発生する可能性のあるエラー
データベース ミラーリング セッションへのクライアントの接続 (SQL Server)
データベース ミラーリング監視サーバー
データベースの完全復元 (完全復旧モデル)
データベース ミラーリングの動作モード
ミラーリング状態 (SQL Server)