次の方法で共有

  • [アーティクル]

強制的なサービスの起動 (データ損失の可能性あり)

データベース ミラーリングには、災害復旧方法としてサービスの強制 (データ損失の可能性あり) を利用でき、ミラー サーバーをウォーム スタンバイ サーバーとして使用できます。サービスを強制できるのは、プリンシパル サーバーが、ミラーリング セッションでミラー サーバーから切断された場合だけです。サービスを強制するとデータを損失する可能性があるので、サービスの強制は注意深く慎重に使用してください。

強制的なサービスの起動がサポートされるかどうかは、次に示すように、動作モードとセッションの状態によって異なります。

  • 通常、高パフォーマンス モードでは、プリンシパル サーバーが切断されていれば、サービスの強制がサポートされます。しかし、不要な場合でも、ミラーリング監視サーバーが高パフォーマンス モードのセッション向けに存在する場合があります。この場合、サービスを強制するには、ミラー サーバーとミラーリング監視サーバーが相互に接続されている必要があります。

  • 自動フェールオーバーを伴わない高い安全性モードでは、プリンシパル サーバーが切断されていれば、サービスの強制がサポートされます。

  • 自動フェールオーバーを伴う高い安全性モードでは、ミラー サーバーとミラーリング監視サーバーが相互に接続されていて、どちらもプリンシパル サーバーに接続されていなければ、サービスの強制がサポートされます (ただし、ミラー サーバーがプリンシパル サーバーに最後に接続したときに、ミラー サーバーがミラー データベースのロールバック処理中だった場合は除きます)。

データベースにサービスをすぐに復元する必要があり、データが失われてもかまわない場合に限り、サービスを強制することをお勧めします。サービスの強制による効果はミラーリングを削除した場合と似ています。異なる点は、サービスの強制では、データ損失の可能性はありますが、ミラーリングの再開時にデータベースを再同期することが容易になることです。サービスの強制は、ミラー データベースにプリンシパルの役割をスムーズに移行するための機能です。ミラー サーバーはプリンシパル サーバーの役割を担うと、データベースのコピーをクライアントにすぐに提供します。新しいプリンシパル データベースはミラーなしで実行されます (つまり、データベースは公開された状態で実行されます)。

重要な注意事項重要

プリンシパル サーバーがデータベース ミラーリング セッションから切断されただけで、サーバー自体は実行されている場合、一部のクライアントが元のプリンシパル データベースにアクセスし続けることがあります。サービスを強制する前に、クライアントが元のプリンシパル サーバーにアクセスできないようにすることが重要です。そうしないと、サービスが強制された後、元のプリンシパル データベースと現在のプリンシパル データベースがそれぞれ、他方とは無関係に更新されることがあります。

強制的なサービスの起動の一般的な事例

次の図は、強制的なサービスの起動 (データ損失の可能性あり) の一般的な事例を示しています。

データ損失の可能性があるサービス強制

図では、ミラー サーバー Partner_B から元のプリンシパル サーバー Partner_A を利用できなくなり、ミラー データベースが切断されます。クライアントが Partner_A を利用できないことを確認した後、データベース管理者は、データを失う可能性がありますが Partner_B でサービスを強制します。Partner_B がプリンシパル サーバーになり、データベースが公開された状態で (つまり、ミラー化されずに) 実行されます。この時点で、クライアントは Partner_B に再接続できます。

Partner_A は利用可能になると、新しいプリンシパル サーバーに再接続し、セッションにもう一度参加してミラーの役割を担います。ミラーリング セッションは直ちに中断され、新しいミラー データベースは同期されません。セッションの中断によって、データベース管理者はセッションを再開するかどうか、極端な場合はミラーリングを削除して以前のプリンシパル データベースからデータ復旧を試行するかどうかを決定できます。ここでは、データベース管理者はミラーリングを再開することにしました。その時点で、Partner_A がミラー サーバーの役割を継承し、以前のプリンシパル データベースを、同期トランザクションが最後に正常に完了した時点にロールバックします。コミットされたトランザクションが、サービスが強制される前にミラー サーバー上のディスクに書き込まれていなかった場合、それらのトランザクションは失われます。その後、Partner_A は、以前のミラー サーバーが新しいプリンシパル サーバーになった後で新しいプリンシパル データベースに加えられた変更を適用することによって、新しいミラー データベースをロールフォワードします。

注意注

高パフォーマンス モードにはミラーリング監視サーバーは必要ありませんが、構成されている場合は、ミラーリング監視サーバーが現在ミラー サーバーに接続されている場合のみサービスの強制が可能です。

サービスの強制のリスク

サービスの強制によってデータが失われる可能性があることを理解しておく必要があります。ミラー サーバーがプリンシパル サーバーと通信できなくなり、そのために 2 つのデータベースが必ずしも同期されなくなることが原因で、データが失われる可能性があります。サービスを強制すると、新しい復旧分岐が始まります。元のプリンシパル データベースとミラー データベースは別の復旧分岐に存在するので、それぞれのデータベースにはもう一方のデータベースには含まれていないデータが含まれることになります。つまり元のプリンシパル データベースには、その送信キューから以前のミラー データベースに送信されなかったすべての変更 (未送信ログ) が含まれ、以前のミラー データベースには、サービスの強制後に行われたすべての変更が含まれます。

注意注

復旧分岐の詳細については、「復旧パス」を参照してください。

プリンシパル サーバーで障害が発生したためにサービスが強制された場合、データが損失するかどうかは、障害発生前にミラー サーバーに送信されなかったトランザクション ログがあるかどうかによって異なります。高い安全性モードの場合、データが損失するのは、ミラー データベースが同期された状態になるまでの間だけです。高パフォーマンス モードの場合、蓄積された未送信ログがある場合は常にデータ損失の可能性があります。

サービスの強制による影響は、セッションにミラーリング監視サーバーが設定されているかどうかによって多少異なります。

  • ミラーリング監視サーバーが存在しない場合、ネットワーク接続が切断されるなどの原因によってパートナーが切断されると、サービスを強制できます。元のプリンシパル サーバーが実行されている場合、両方のパートナーがプリンシパルの役割を担います。新しいプリンシパル サーバーに接続しているクライアントは、現在のバージョンのデータベースにアクセスし、元のプリンシパル サーバーに接続しているクライアントは元のプリンシパル データベースにアクセスします。この状況により、データ損失の可能性が大きくなります。パートナーが再接続を許可されたら、元のプリンシパル サーバーはミラーの役割を担い、ミラーリングが中断される前にデータベースの状態を "復旧しています" の状態に変更します。セッションが再開されると、前回切断されたときに送信キューにあったログを所有する元のプリンシパル データベースのトランザクションが失われます。また、サービスの強制後に発生したトランザクションも失われます。

  • ミラーリング監視サーバーが存在する場合、ミラー サーバーがプリンシパル サーバーとミラーリング監視サーバーの両方から切断されると、プリンシパル サーバーとミラーリング監視サーバーが相互に接続されている限り、プリンシパルが公開された状態で実行されます。その後、プリンシパル サーバーがミラーリング監視サーバーから切断されると、データベースとして機能しなくなります。そのため、ミラー サーバーがミラーリング監視サーバーに再接続した後、サービスの強制が可能になります。サービスが強制されると、元のプリンシパル サーバーが再接続されたときに、元のプリンシパル サーバーが公開された状態で実行されていたときに行われたすべての変更が失われます。

詳細については、このトピックの「データ損失の可能性への対処」を参照してください。

データ損失の可能性への対処

サービスの強制後、以前のプリンシパル サーバーが使用可能になると、そのデータベースは破損していないと想定されるので、データ損失の可能性に対処できます。データ損失の可能性に対処するために使用できる方法は、元のプリンシパル サーバーがそのパートナーに再接続され、ミラーリング セッションにもう一度参加したかどうかによって異なります。元のプリンシパル サーバーが新しいプリンシパル インスタンスにアクセスできる場合、自動的に再接続されます。

元のプリンシパル サーバーが再接続された場合

通常、障害発生後は、元のプリンシパル サーバーは再起動するとすぐに、パートナーに再接続します。再接続されると、元のプリンシパル サーバーがミラー サーバーになります。そのデータベースはミラー データベースになり、セッションが中断されるまで復旧中の状態になります。ミラー データベースは、ミラーリングを再開しない限り、ロールバックされません。

ただし、復旧中のデータベースにはアクセスできないので、データベースを調査し、ミラーリングを再開したときにどのデータが失われるのかを評価することができません。そのため、ミラーリングを再開するか削除するかは、データの損失を許容できるかどうかによって決まります。

  • データの損失を許容できない場合は、ミラーリングを削除して、データを復旧する必要があります。

    ミラーリングを削除すると、データベース管理者は元のプリンシパル データベースを復旧し、失われる可能性のあるデータの復旧を試みることができます。ただし、以前のミラー データベースがオンラインになると、以前のパートナーは同じ名前の異なるデータベースとして機能するようになります。データベース管理者はそれらのデータベースのいずれかをクライアントからアクセスできないようにして、さらに別のデータベースが作成されたり、クライアントのフェールオーバー問題が発生することを防ぐ必要があります。

  • データの損失を許容できる場合は、ミラーリングを再開できます。

    ミラーリングを再開すると、新しいミラー データベースがデータベース同期の最初のステップとしてロールバックされます。障害発生時にログ レコードが送信キューで待機していた場合、対応するトランザクションはコミットされていた場合でも失われます。

元のプリンシパル サーバーが再接続されなかった場合

元のプリンシパル サーバーが新しいプリンシパル サーバーにネットワーク経由で再接続するのを一時的に防ぐことができる場合、元のプリンシパル データベースを調査して、ミラーリングが再開されたらどのデータが失われるのかを評価できます。

  • データ損失が許容される場合

    元のプリンシパル サーバーがそのパートナーに再接続できます。再接続を行うと、ミラーリングが中断されます。ミラーリングを続行するには、セッションを再開するだけです。以前のプリンシパル サーバーがミラーの役割を担います。新しいミラー サーバーが元の復旧分岐を削除し、以前のミラー サーバーに送信されなかったか以前のミラー サーバーによって受信されなかったすべてのトランザクションが失われます。

  • データ損失が許容されない場合

    セッションを再開したら失われる重要なデータが元のプリンシパル サーバーに含まれている場合、ミラーリングを削除することにより元のプリンシパル サーバー上のデータを保持できます。この時点で、プリンシパルのログの末尾をバックアップしておくことをお勧めします。その後、復旧したいデータを最初のプリンシパル データベースからエクスポートして、そのデータを現在のプリンシパル データベースにインポートすることにより、現在のプリンシパル (以前のミラー データベース) を更新できます。更新されたデータベースの完全バックアップを、できるだけ早く実行することをお勧めします。

    更新されたデータベースを最初のプリンシパル データベースとするミラーリングを再確立するには、このバックアップ (およびそれ以降のログ バックアップ 1 つ以上) を使用して、新しいミラー データベースを作成します。ミラーリングの削除後に実行したログ バックアップをすべて適用する必要があります。そのため、新しいミラーリング セッションが開始されるまで、プリンシパル データベースで追加のログ バックアップを作成しないことをお勧めします。

データベース ミラーリングの関連リソース

サービスを強制するには

データベース ミラーリングを再開するには

新しいミラー データベースを作成するには

ミラーリング用のミラー データベースを準備する方法 (Transact-SQL)

データベース ミラーリングを開始するには