手動フェールオーバー

アップグレード中の可用性の維持

データベース管理者は、可用性を損なうことなくハードウェアやソフトウェアをアップグレードするために、手動フェールオーバーを行うことができます。ソフトウェアをアップグレードするためにデータベース ミラーリングを使用する場合、ミラー サーバーのソフトウェア、ハードウェアのアップグレードを先に行う必要があります。

注
データベース ミラーリングではローリング アップグレードを実行できることになっていますが、将来の変更については不明であるため、この動作は保証されていません。詳細については、「サーバー インスタンスのアップグレード時に、ミラー化されたデータベースのダウンタイムを最小化する方法」を参照してください。

次の図は、データベース サーバー インスタンスをアップグレードするときに、データベースの可用性を保持するために手動フェールオーバーを使用している例を示しています。アップグレードが完了すると、管理者は必要に応じて元のサーバー インスタンスにフェールオーバーを行うことができます。これは、管理者がミラーリング セッションを停止し、他の場所にあるミラー サーバーを使用する場合に役に立ちます。この方法により、一連のデータベース サーバー インスタンスを更新するときに、1 つのサーバー インスタンスを繰り返し使用できます。

手動フェールオーバーに必要な条件

手動フェールオーバーでは、トランザクションの安全性が FULL (高い安全性モード) に設定されている必要があります。パートナーが接続され、データベースが既に同期されている場合、手動フェールオーバーがサポートされます。

手動フェールオーバーの動作

手動フェールオーバーにより、次の一連の操作が開始されます。

1. プリンシパル サーバーでは、プリンシパル データベースからクライアントが切断され、ログの末尾がミラー サーバーに送信されます。また、ミラー ロールへの切り替えの準備として、ミラーリングの状態が SYNCHRONIZING に設定されます。

2. フェールオーバーのログ シーケンス番号 (LSN) としてプリンシパルから受信した、最後のログ レコードの LSN が、ミラー サーバーに記録されます。

   注
   この LSN を表示するには、sys.database_mirroring (Transact-SQL) から mirroring_failover_lsn 列を選択します。

3. 再実行キューで待機しているログがある場合は、ミラー サーバーがミラー データベースのロールフォワードを完了します。必要な時間は、システムの処理速度、最近の作業負荷、および再実行キューのログの量によって異なります。同期動作モードの場合、再実行キューのサイズを制限することでフェールオーバーの時間を調節できます。ただし、同期動作モードでは、ミラー サーバーの遅れを取り戻すためにプリンシパル サーバーの処理速度が低下する場合があります。

   注
   再実行キューの現在のサイズを調べるには、データベース ミラーリング パフォーマンス オブジェクトの Redo Queue パフォーマンス カウンターを使用します (詳細については、「データベース ミラーリングの監視」を参照してください)。

4. ミラー サーバーが新たにプリンシパル サーバーになり、前のプリンシパル サーバーが新たにミラー サーバーになります。

5. 新しいプリンシパル サーバーでは、コミットされていないトランザクションがロールバックされ、データベースのコピーがプリンシパル データベースとしてオンラインになります。

6. 前のプリンシパルがミラーの役割を引き継ぎ、前のプリンシパル データベースがミラー データベースになります。新しいミラー サーバーでは、新しいミラー データベースと新しいプリンシパル データベースとの再同期が迅速に実行されます。

   注
   新しいミラー サーバーによってデータベースの再同期が完了すると、再度フェールオーバーが可能になりますが、今度は反対方向にフェールオーバーされることになります。

フェールオーバー後は、クライアントから現在のプリンシパル データベースに再接続する必要があります。詳細については、「ミラー化されたデータベースへのクライアント接続」を参照してください。

手動フェールオーバーを開始するには

• データベース ミラーリング セッションを手動でフェールオーバーする方法 (SQL Server Management Studio)

• データベース ミラーリング セッションを手動でフェールオーバーする方法 (Transact-SQL)

関連項目

概念