SQL Server 2005 データベース ミラーリング

このページはアーカイブです。記載されている内容は情報提供のみを目的としており、ページ内のリンクは有効でない可能性がありますが、これらの情報についてマイクロソフトはいかなる責任も負わないものとします。

公開日: 2005年9月27日 | 最終更新日: 2008年4月3日

Ron Talmage、Solid Quality Learning

トピック

はじめに
データベース ミラーリングの概要
データベース ミラーリングのダイナミクス
データベース ミラーリングの可用性シナリオ
データベース ミラーリングの実装
データベースのミラーリングと高可用性テクノロジ
まとめ

はじめに

データベース ミラーリングは、データベースの可用性を向上させる SQL Server 2005 の新しいテクノロジです。データベース ミラーリングにより、トランザクション ログ レコードのサーバーからサーバーへの直接転送や、スタンバイ サーバーへの迅速なフェールオーバーが可能になります。また、接続情報の自動的なリダイレクトや、フェールオーバーのイベントにおいてスタンバイ サーバーとデータベースへの自動的な接続を行うように、クライアント アプリケーションをコーディングすることができます。従来、データ損失を最小限に抑える迅速なフェールオーバーを実現するためには、高額なハードウェアと複雑なソフトウェアが必要でした。しかし、データベース ミラーリングは、コミットされたデータを失うことなく、迅速なフェールオーバーを可能にし、独自仕様のハードウェアを必要とせずに、セットアップと管理を行うことができます。

データベース ミラーリングの概要

データベース ミラーリングでは、送信側の SQL Server 2005 インスタンスが、スタンバイ用の SQL Server インスタンスにデータベースのトランザクション ログ レコードを連続的に送信します。送信側のデータベースがプリンシパル サーバーを担当し、受信側のデータベースがミラー サーバーを担当します。プリンシパル サーバーとミラー サーバーは、SQL Server 2005 のインスタンスを分ける必要があります。

SQL Server データベースでは、データ変更がトランザクション ログに記録されてから、実際のデータ ページが変更されます。トランザクション ログ レコードは、最初にメモリ上のデータベースのログ バッファに格納されてから、できるだけ早くディスクに転送 (または "書き込み") されます。データベース ミラーリングでは、プリンシパル サーバーが、プリンシパル データベースのログ バッファをディスクに書き込むのと同時に、そのログ レコードのブロックをミラー インスタンスに送信します。

ミラー サーバーは、ログ レコードのブロックを受信すると、最初にログ レコードをミラー データベースのログ バッファに格納してから、できるだけ早くディスクに書き込みます。トランザクション ログ レコードは、後からミラー データベース上で再生されます。ミラー データベースがプリンシパル データベースのトランザクション ログ レコードを再生することによって、プリンシパル データベースの変更が複製されます。

プリンシパル サーバーとミラー サーバーは、それぞれ、データベース ミラーリング セッションのパートナーと見なされます。データベース ミラーリング セッションは、パートナー サーバーどうしが一方のパートナーからもう一方のパートナーにデータベースをミラーするときの関連付けから成り立ちます。所与のパートナー サーバー 1 台が、あるデータベースに対してはプリンシパルを、別のデータベースに対してはミラーを担当することができます。

データベース ミラーリング セッションには、2 台のパートナー サーバー (プリンシパルとミラー) のほかに、"ミラーリング監視" という名前の 3 番目のサーバーをオプションで追加することができます。このミラーリング監視サーバーの役割は、自動フェールオーバーを可能にすることです。高可用性を実現するためにデータベース ミラーリングを使用すると、プリンシパル サーバーに突然障害が発生しても、ミラー サーバーがミラーリング監視サーバーの確認のもとに自動的にプリンシパルを引き受け、数秒以内にデータベースを使用可能にすることができます。

データベース ミラーリングに関して注意が必要となる主な事項には、次のものがあります。

• プリンシパル データベースは、完全復旧モデルにする必要があります。一括ログ記録動作によって生成されたログ レコードは、ミラー データベースに送信することができません。

• ミラー データベースは、NORECOVERY に設定されたプリンシパル データベースの復元を元に初期化し、これに続く一連のプリンシパル トランザクション ログのバックアップの復元を反映する必要があります。

• ミラー データベースは、プリンシパル データベースと同じ名前にする必要があります。

• ミラー データベースが復旧状態にあるときは、直接アクセスすることができません。ミラー上にデータベース スナップショットを作成して、間接的にある時点のミラー データベースを読み込むことができます (後述する「データベース スナップショットとミラー データベース」を参照してください)。

メモ   データベース ミラーリングに関する用語の詳細については、SQL Server 2005 Books Online の「Overview of Database Mirroring」(英語情報) を参照してください。

動作モード

データベース ミラーリング セッションで使用可能な 3 つの動作モードがあります。動作モードは、トランザクションの安全性の設定と、ミラーリング監視サーバーがミラーリング セッションに含まれているかどうかによって異なります。

表 1   データベース ミラーリングの動作モード

動作モード	トランザクションの安全性	転送メカニズム	クォーラムの必要性	ミラーリング監視サーバー	フェールオーバー タイプ
高可用性	FULL	同期	あり	あり	自動または手動
高度な保護	FULL	同期	あり	なし	手動のみ
高パフォーマンス	OFF	非同期	なし	該当なし	強制のみ

トランザクションの安全性が FULL の場合は、同期データ転送が行われます。データベース サービスを提供するためにはクォーラム ディスクが必要です。2 台のパートナー サーバーそれぞれがどの役割 (プリンシパルとミラー) を担当するかを決定するクォーラム投票には、最低 2 台のサーバーが必要です。

この 3 種類の動作モードをさらに詳しく調べるために、まずは、トランザクションの安全性とクォーラムの役割に注目してみましょう。

トランザクションの安全性

トランザクションの安全性 (または "安全性") が FULL に設定されている場合は、プリンシパル サーバーとミラー サーバーが同期転送モードで動作します。プリンシパル サーバーは、データベース ログ レコードをディスクに書き込むと同時に、ミラー サーバーに送信します。その後で、プリンシパル サーバーはミラー サーバーからの応答を待ちます。ミラー サーバーは、受信したログ レコードをログ ディスクに書き込んでから応答を返します。安全性が OFF の場合は、プリンシパル サーバーはミラー サーバーからの応答を待ちません。そのため、プリンシパル サーバーとミラー サーバーは完全には同期しない可能性があります (つまり、ミラー サーバーがプリンシパル サーバーに追随しない可能性があります)。

同期転送によって、ミラー データベースのトランザクション ログ内のすべてのトランザクションが、プリンシパル データベースのトランザクション ログと同期するため、トランザクションが安全に転送されることが保証されます。次のコマンドを使用して、安全性を FULL に設定します。

ALTER DATABASE [<dbname>] SET SAFETY FULL;

安全性が OFF の場合は、プリンシパル サーバーとミラー サーバー間の通信が非同期になります。プリンシパル サーバーは、ミラー サーバーのトランザクション レコードのブロックを書き込んだという応答を待ちません。ミラー サーバーは、できるだけ早くトランザクションを記録することによって、プリンシパル サーバーに追随しようとしますが、突然、プリンシパル サーバーが故障して、ミラー サーバーを稼動せざるを得なくなった場合に、一部のトランザクションが失われる可能性があります (SQL Server Books Online の「Forced Service」(英語情報) を参照してください)。

クォーラムとミラーリング監視サーバー

安全性が FULL の場合は、データベースの提供を中断させないために、データベース ミラーリング セッションにクォーラムが必要です。クォーラムは、同期データベース ミラーリング セッションに接続されたすべてのサーバーでサービスを行うために必須です。クォーラムには最低 2 台のサーバーが必要なので、安全性が FULL の場合は、データベース サービスの提供を中断させないために、プリンシパル サーバーが 1 台以上の別のサーバーとクォーラムを形成する必要があります。

ミラーリング監視サーバーは、プリンシパル サーバーまたはミラー サーバーのクォーラムの形成を支援します。ミラーリング監視サーバーが存在する場合は、プリンシパル データベースとミラー データベースのどちらかがダウンしても残りの 2 台のサーバーでクォーラムを形成できます。プリンシパル サーバーは、ミラー サーバーが確認できない場合でも、ミラーリング監視サーバーとクォーラムを形成できるため、データベース サービスの提供を継続できます。同様に、ミラー サーバーとミラーリング監視サーバーがプリンシパル サーバーを確認できず、ミラー サーバーがミラーリング監視サーバーとクォーラムを形成できる場合は、ミラー サーバーが新しいプリンシパル サーバーの役割を引き受けることができます。

ミラーリング監視サーバーが故障した場合でも、プリンシパル サーバーとミラー サーバーがクォーラムの形成を継続するため、ミラーリング監視サーバーはデータベース ミラーリング セッションにおける単一障害点とは見なされません (詳細については、SQL Server Books Online の「Quorum in Database Mirroring Sessions」(英語情報) を参照してください)。

高可用性動作モード

高可用性動作モードは、プリンシパル データベースが故障した場合でもミラー データベースに自動的にフェールオーバーすることによって、最大限のデータベースの可用性をサポートします。このモードでは、安全性を FULL に設定して、ミラーリング監視サーバーをデータベース ミラーリング セッションの一部として定義する必要があります。

高可用性モードは、サーバー間に高速で非常に信頼性の高い通信経路が存在する場合や単一のデータベースに対する自動フェールオーバーが必要な場合に最適です。安全性が FULL の場合は、プリンシパル サーバーがミラー サーバーからの応答を待つ必要があるため、プリンシパル サーバーのパフォーマンスが、ミラー サーバーのパフォーマンスの影響を受ける可能性があります。1 つのデータベースの故障によって自動フェールオーバーが発生するため、複数のデータベース アプリケーションを使用している場合は、その他の動作モードを検討することをお勧めします (後述する導入に関する節の「複数データベース使用時の問題点」を参照してください)。

高可用性モードにおけるデータベース ミラーリングは自己監視です。プリンシパル データベースが突然使用不能になった場合、または、プリンシパル サーバーがダウンした場合、ミラーリング監視サーバーとミラー サーバーがクォーラムを形成し、ミラー SQL Server が自動フェールオーバーを実施します。このとき、ミラー サーバー インスタンスが、役割を変更して新しいプリンシパル サーバーになり、データベースを復旧します。ミラー サーバーは、プリンシパル サーバーのトランザクション ログを再生し、そのトランザクション ログがプリンシパル サーバーのログと同期しているため、すばやく使用可能状態になることができます。

また、SQL Server 2005 は、回復プロセスの初期段階で、ユーザーに対してデータベースを使用可能にすることができます。SQL Server のデータベース回復は、分析フェーズ、再実行フェーズ、および取り消しフェーズの 3 つのフェーズで構成されます。SQL Server 2005 では、再実行フェーズが終了後すぐに新しく復旧されたデータベースを使用可能にすることができます。したがって、データベース ミラーリングのフェールオーバーが発生した場合は、再実行フェーズが終了するとすぐに新しく復旧されたプリンシパル データベースを使用可能にすることができます。ミラー データベースは常にトランザクション ログ レコードを再生しているため、ミラー サーバーが行わなければならないことは、再実行プロセスを終了することだけです。通常、これは数秒で完了します。

高度な保護動作モード

高度な保護動作モードも、トランザクションの安全性が FULL に設定されますが、ミラーリング セッションにミラーリング監視サーバーが含まれません。プリンシパル データベースはクォーラムを形成する必要がありますが、ミラーリング監視サーバーがないため、ミラー サーバーとクォーラムを形成するしかありません。このモードでは、タイブレーカの役割を満たすミラーリング監視サーバーがないため、手動フェールオーバーしか使用することができません。プリンシパル サーバーが故障した場合は、ミラー サーバーがクォーラムを形成するためのミラーリング監視サーバーがないため、自動フェールオーバーが発生しません。

安全性が FULL の場合は、ミラー サーバーとのクォーラムを突然失ったプリンシパル サーバーは、データベース サービスの提供を中止する必要があります。高度な保護モードは、ミラーリング監視サーバーを一時的に取り除かなければならない高可用性モードへの移行途中である状態を除き、データベースのミラーリング設定としてお勧めできません。

高パフォーマンス動作モード

高パフォーマンス動作モードでは、トランザクションの安全性は OFF に設定され、ログ レコードの転送は非同期に行われます。プリンシパル サーバーは、すべてのトランザクション ログ レコードがミラー サーバーに記録されたというミラー サーバーからの応答を待ちません。ミラー サーバーは、プリンシパル サーバーにできる限り追随しますが、プリンシパル サーバーからの最新のトランザクションのすべてがミラー サーバーのトランザクション ログに書き込まれたかどうかは保証されません。

高パフォーマンス モードでは、ミラーリング監視サーバーが担当する役割はなく、クォーラムも必要ありません。そのため、高パフォーマンス モードでは、自動フェールオーバーと手動フェールオーバーを使用できません。許可されている唯一のフェールオーバーは、"強制" サービス フェールオーバーです。実行するには、次のコマンドを手動で発行します。

ALTER DATABASE <dbname> SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS

強制サービス フェールオーバーは、ミラー データベースの迅速な復旧を実現します。ただし、プリンシパル サーバーからミラー サーバーに届かないトランザクション ログ ブロックがある場合は、復旧時にミラー サーバー上でデータ損失が発生する可能性があります。高パフォーマンス モードは、離れた場所にデータを転送する場合 (たとえば、リモート サイトに対して障害回復を実施する場合)、または、ある程度のデータ損失が許される非常にアクティブなデータベースをミラーリングする場合に最適です。

データベース スナップショットとミラー データベース

ミラー データベースが復旧状態にあるときは、アクセスしたり、読み込んだりすることはできません。SQL Server 2005 の Enterprise Edition と Developer Edition を使用すると、データベース スナップショットを作成して、ある時点のミラー データベースを読み込むことができます。データベース スナップショットは、データベースの読み込み専用ビューを提供します。これは、スナップショット作成時点で矛盾のないデータを示しています。

データベース スナップショットには、あたかも別のデータベースであるかのようにアクセスします。データベース スナップショットに問い合わせる (クエリを実行する) 場合は、スナップショットの作成後に変更されたデータベース データの元のバージョンをデータベースのスナップショット ファイルから読み込んだり、変更される前のデータを元のデータベースから読み込んだりします。最終的な効果として、スナップショットの作成時点で最新であったデータベース データを確認できることが挙げられます (詳細については、SQL Server Books Online の「Using Database Snapshots with Database Mirroring」(英語情報) を参照してください)。

データベース スナップショットによって、ミラー サーバーにオーバーヘッドが発生する可能性があるため、データベース ミラーリングのパフォーマンスにどの程度の影響があるかを慎重に見極める必要があります。ミラーリングは 1 つのデータベースに対してしか行うことができないため、多数のレポーティング サーバーを増設する必要がある場合は、トランザクションのレプリケーションを使用することをお勧めします (詳細については、後述する導入に関する節の「データベース ミラーリングとトランザクションのレプリケーション」を参照してください)。

クライアント側のリダイレクト

SQL Server 2005 では、ADO.NET または SQL Native Client を使ってミラーリングされたデータベースに接続する場合に、データベース ミラーリング フェールオーバーが発生したときのドライバの自動リダイレクト機能をアプリケーションから利用することができます。接続文字列の中に最初のプリンシパル サーバーとデータベース、およびオプションでフェールオーバー パートナー サーバーを指定する必要があります。接続文字列のすべてのキーワードの詳細については、「SQL Native Client での接続文字列キーワードの使用」を参照してください。

接続文字列の作成方法は複数ありますが、ここでは、サーバー A をプリンシパル サーバーとして、サーバー B をミラー サーバーとして、AdventureWorks をデータベース名として指定する場合の例を示します。

"Data Source=A;Failover Partner=B;Initial Catalog=AdventureWorks;Integrated Security=True;"

接続文字列内のフェールオーバー パートナーは、最初のプリンシパル サーバーへの接続が失敗した場合の代替サーバー名として使用されます。最初のプリンシパル サーバーへの接続が成功した場合は、フェールオーバー パートナー名は使用されませんが、ドライバがクライアント側のキャッシュ上のプリンシパル サーバーからフェールオーバー パートナー名を検索して保存します。

クライアントがプリンシパル サーバーとの接続に成功して、データベース ミラーリング フェールオーバー (自動、手動、または強制サービス) が発生したと仮定します。次に、アプリケーションがその接続を使用するときに、ADO.NET ドライバまたは SQL Native Client ドライバが、古いプリンシパル サーバーへの接続が失敗したことを検出して、自動的にフェールオーバー パートナー名を指定して新しいプリンシパル サーバーへの接続を再実行します。この接続が成功し、新しいプリンシパル サーバーによって指定されたデータベース ミラーリング セッション用の新しいミラー サーバーが存在する場合は、ドライバが新しいパートナー フェールオーバー サーバー名を検索してクライアント キャッシュに格納します。クライアントが代替サーバーに接続できない場合は、代わりにドライバがログイン タイムアウト期間が切れるまで、各サーバーに接続しようとします。

ADO.NET ドライバと SQL Native Client ドライバに組み込まれているデータベース ミラーリング サポートを使用する重要なメリットは、データベース ミラーリング フェールオーバーを処理するために、アプリケーションをコーディングし直したり、アプリケーションに特別なコードを追加したりする必要がないことです。

ADO.NET または SQL Native Client の自動リダイレクションを使わなくても、別の技法を使ってアプリケーションのフェールオーバーを実現できます。たとえば、ネットワーク負荷分散を使用すると、クライアントをバーチャル サーバー名に接続するだけで、あるサーバーから別のサーバーへ接続を手動でリダイレクトすることができます。また、独自のリダイレクション コードを作成して、そのロジックを試すこともできます。

ただし、データベース ミラーリングによってクライアントのリダイレクションを調整するこれらの技法のすべてには、重要な制限事項があります。データベース ミラーリングは、サーバー レベルではなくデータベース レベルでのみ発生します。アプリケーションから、1 台のサーバー上の複数のデータベースにクエリを実行する場合、または、複数のオブジェクト名を使って複数のデータベースにクエリを実行する場合は注意が必要です。1 台のサーバー上に複数のデータベースが存在し、それらが 1 台のスタンバイ サーバーにミラーリングされている場合は、複数のデータベースのうちの 1 つしかスタンバイ サーバーにフェールオーバーすることができません。このような場合は、クエリを実行するデータベースごとに接続を分ける必要があります。そうしなければ、1 つのデータベースだけがプリンシパルで、残りのデータベースがすべてミラーのスタンバイ サーバー上で、データベースを横断するクエリを実行することになります。

データベース ミラーリングと SQL Server 2005 のエディション

次の表は、SQL Server 2005 の複数のエディションでサポートされているデータベース ミラーリング機能を示したものです。

表 2   データベース ミラーリングと SQL Server 2005 のエディション

次のデータベース ミラーリング機能には、SQL Server 2005 の Enterprise Edition または Developer Edition が必要です。

• 安全性を OFF に設定した高パフォーマンス モード (非同期データ転送)

• データベース スナップショット

• 複数スレッドを使用したミラー データベース上のトランザクション再生 (並列再実行)

SQL Express と Workgroup Edition は、データベース ミラーリングにおいて、ミラーリング監視サーバーとして使用することはできますが、パートナー サーバーとして使用することはできません。

データベース ミラーリングのダイナミクス

SQL Server 2005 データベース ミラーリングをより深く理解するには、データベース ミラーリング セッションが時間とともにどのように変化するかを理解する必要があります。ここでは、データベース ミラーリング セッションにおけるさまざまなデータベースの状態、同期ログ レコード転送と非同期ログ レコード転送のメカニズム、およびフェールオーバー シーケンスについて説明します。

セットアップとセキュリティ

プリンシパル サーバー、ミラー サーバー、およびオプションのミラーリング監視サーバーを特定したら、データベース ミラーリングのセットアップを行います。セットアップは、基本的に次の 3 つのステップで構成されます。

1. データベースのバックアップを作成し、作成したバックアップを復旧なしで目的のミラー サーバーに復元します。

   メモ   プリンシパル データベースは、ミラー サーバーに復元するデータベースのバックアップを作成する前に、完全復旧モデルにする必要があります。一括ログ記録レコードをトランザクション ログに転送する必要がある場合、データベース ミラーリングは機能しません。ミラー サーバーには、プリンシパル データベースのファイル増大に対応できる十分な空き領域が必要です。ミラー サーバー上でデータベース スナップショットを作成する場合も同様に、空き領域を確保する必要があります。 バックアップ、コピー、および復元に比較的長い時間がかかる場合は、送信側のデータベース上でトランザクション ログのバックアップを取って、ログ サイズの増加を抑制する必要があります。ただし、トランザクション ログ レコードがログのバックアップによってログから削除されていた場合は、データベース ミラーリングを初期化することはできません。そのため、データベース ミラーリングを初期化する前に、これらのトランザクション ログのバックアップを順に目的のミラー データベースに復旧なしで復元する必要があります。

2. データベース ミラーリング セッションに関与するサーバーは、お互いに信頼されている必要があります。ドメインなどのローカル通信における信頼とは、各 SQL Server インスタンスのログインが、他のミラーリング サーバーに接続してそのエンドポイントに接続する権限を持っていなければならないことを意味します。これを実現するには、各サーバー上で CREATE LOGIN コマンドを使用してから、GRANT CONNECT ON ENDPOINT コマンドを使用します (SQL Server Books Online の「Example of Setting Up Database Mirroring Using Windows Authentication」(英語情報) を参照してください)。

   信頼されていないドメイン間の通信では、証明書を使用する必要があります。CREATE CERTIFICATE ステートメントを使って自己署名証明書を作成すると、データベース ミラーリングのほとんどの証明書要件が満たされます。このとき、CREATE CERTIFICATE ステートメント内で証明書が ACTIVE FOR BEGIN_DIALOG に設定されていることを確認してください。

3. 次のステップは、データベース ミラーリングのエンドポイントの設定です。エンドポイントを設定するには、SQL Server インスタンスに対するシステム管理者権限が必要です。データベース ミラーリングのエンドポイントとして明示的に作成されたエンドポイントを各サーバー上でセットアップする必要があります。エンドポイントをセットアップする最も簡単な方法は、データベース ミラーリング セキュリティ構成ウィザードを使用する方法です。このウィザードは、[データベースのプロパティ] ダイアログの [ミラーリング] ページで [セキュリティの構成] ボタンをクリックして起動することができます。CREATE ENDPOINT コマンドを組み立てて実行する前に、[セキュリティの構成] ダイアログで、コンピュータ名とポート番号、およびオプションでログインの入力が求められます。Transact-SQL を使用して、CREATE ENDPOINT コマンドを実行することもできます (SQL Server Books Online の「How to: Create a Mirroring Endpoint (Transact-SQL)」(英語情報) を参照してください)。

   1 つのドメイン上でデータベース ミラーリングをセットアップしているときに、すべての SQL Server インスタンスが同じサービス ログインとパスワードを使用する場合は、サーバーごとにログインを作成する必要はありません。同様に、1 つのワークグループ上ですべての SQL Server インスタンスが同じサービス ログインとパスワードを使用する場合は、サーバーごとにログインを作成する必要はありません。エンドポイントをセットアップするときは、データベース ミラーリング セキュリティ構成ウィザード上のログインを空白のままにしてください。

   データベースのエンドポイントごとにサーバー上の一意のポートを指定する必要があります。コンピュータごとに SQL Server インスタンスを使い分ける場合は、これらのポート番号をすべて同じにすることができます。データベース ミラーリング セキュリティ構成ウィザードでは、自動的に 5022 ポートを使用するように提示されます。すべての SQL Server インスタンスが同じサーバー上に存在する場合は、インスタンスごとにポートを設定して、ポート番号を一意にする必要があります。

   高可用性ミラーリング セッションで 3 台のサーバーを使用すると仮定します。サーバー A をプリンシパルに、サーバー B をミラーに、サーバー W をミラーリング監視に設定します。サーバー A の場合は、次のコマンドで 5022 ポート上にエンドポイントが作成されます。

   
   CREATE ENDPOINT [Mirroring] 
   AS TCP (LISTENER_PORT = 5022)
   FOR DATA_MIRRORING (ROLE = PARTNER, ENCRYPTION = ENABLED);
   

   このサーバーは、任意のデータベース ミラーリング用のプリンシパルまたはミラーを引き受けるために、役割が PARTNER (パートナー) に設定されていることに注意してください。同じコマンドがサーバー B 上で発行されます。サーバー B は、物理的に別のサーバー上の SQL Server インスタンスであるため、ポート番号は同じです。続いて、サーバー W に対しては、次のコマンドを発行できます。

   
   CREATE ENDPOINT [Mirroring] 
   AS TCP (LISTENER_PORT = 5022)
   FOR DATA_MIRRORING (ROLE = WITNESS, ENCRYPTION = ENABLED);
   

   サーバー W の場合は、役割が WITNESS (ミラーリング監視サーバー) に設定されていることに注意してください。

   既定では、エンドポイントは開始されません。各サーバー上で次のクエリ コマンドを発行することによって、エンドポイントを開始できます。

   
   ALTER ENDPOINT [Mirroring] STATE = STARTED;
   

   CREATE ENDPOINT コマンドに STATE オプションを任意で挿入することができます。このプロセスをサーバーごとに繰り返します。

   CREATE ENDPOINT ステートメントでエンドポイントを作成するときに、プロトコル固有の引数を使って IP アドレスでアクセスを制限できます。RESTRICT_IP と ALL オプションを組み合わせたり、EXCEPT_IP と制限する IP アドレスのリストだけを組み合わせたりすることによって、IP アドレスの特別なセットにアクセス制限を適用できます (SQL Server Books Online の「CREATE ENDPOINT」(英語情報) を参照してください)。

   次のように sys.database_mirroring_endpoints カタログ ビューにクエリを実行することによって、データベース ミラーリング エンドポイントを確認できます。

   
   SELECT *
   FROM sys.database_mirroring_endpoints;
   

4. 次に、データベース ミラーリングを開始するために、パートナーとミラーリング監視を設定します。特定のデータベース ミラーリング セッションの開始と管理には、データベース所有者の許可が必要です。プリンシパル サーバーに設定されたサーバー A 上で、次のように、特定のデータベースにプリンシパルの役割を与えて、どれがパートナー (ミラー) サーバーかを示す情報を SQL Server に伝達します。

   
   -- Specify the partner from the principal server
   ALTER DATABASE [AdventureWorks] SET PARTNER =
   N'TCP://B.corp.mycompany.com:5022';
   

   パートナー名は、パートナー サーバーの完全修飾コンピュータ名を記述する必要があります。完全修飾コンピュータ名を取得することは容易ではありませんが、データベース ミラーリング セキュリティ構成ウィザードでエンドポイントを設定すると、完全なコンピュータ名が自動的に検索されます。

   各サーバーの完全修飾コンピュータ名は、コマンド プロンプトから次を実行して検索することもできます。

   
   IPCONFIG /ALL
   

   "ホスト名" と "プライマリ DNS サフィックス" を連結します。表示例を以下に示します。

   Host Name .. . . . . . . . . . . : A
   Primary Dns Suffix .. . . . . . : corp.mycompany.com

   この例のコンピュータ名は、A.corp.mycompany.com となります。前に "TCP://" と ":<ポート番号>" を付けるとパートナー名になります。

   ミラー サーバー上で、次のように、プリンシパル サーバー名を使って同じコマンドを繰り返します。

   
   -- Specify the partner from the mirror server
   ALTER DATABASE [AdventureWorks] SET PARTNER =
   N'TCP://A.corp.mycompany.com:5022';
   

   次に、プリンシパル サーバー上で、ミラーリング監視サーバーを設定します。

   
   -- Specify the witness from the principal server
   ALTER DATABASE [AdventureWorks] SET WITNESS =
   N'TCP://W.corp.mycompany.com:5026';
   

   ミラーリング監視サーバー上では、最初の CREATE ENDPOINT 以外のコマンドを実行する必要はありません。

   最後に、プリンシパル サーバー上でセッションの安全性レベルを設定します。

   
   -- Set the safety level from the principal server
   ALTER DATABASE [AdventureWorks] SET SAFETY FULL;
   

   これで、ミラーリングが自動的に開始し、プリンシパル サーバーとミラー サーバーが同期します。ALTER DATABASE コマンドの TIMEOUT パラメータを使用して、パートナー サーバーの故障を判断するためのタイムアウト値を調整することができます。たとえば、TIMEOUT 値を 20 秒 (既定では 10 秒) に変更するには、プリンシパル サーバー上で次のコマンドを発行します。

   
   -- Issue from the principal server
   ALTER DATABASE [AdventureWorks] SET PARTNER TIMEOUT 20;
   

   最後に、プリンシパル サーバー上で REDO_QUEUE オプション付きの ALTER DATABASE コマンドを発行することによって、ミラー サーバー上の再実行操作用キューのサイズを調整することができます。次のクエリ コマンドは、ミラー サーバー上の再実行操作用キューを 100 MB に設定します。

   
   -- Issue from the principal server
   ALTER DATABASE [AdventureWorks] SET PARTNER REDO_QUEUE 100MB;
   

   パートナー サーバーの設定が完了すると、直ちにミラーリングが開始されます。

データベース ミラーリングのカタログ ビュー

データベース ミラーリング セッションは、パートナー サーバー間と、場合によってはミラーリング監視サーバーも含まれるサーバー間の関連付けから構成されます。関係しているサーバーのそれぞれが、セッションとデータベースの現在の状態に関するメタデータを保持します。sys.database_mirroring カタログ ビューにクエリを実行することによって、プリンシパル サーバーまたはミラー サーバー上のセッションを確認できます。ミラーリング監視サーバーのメタデータは、別のカタログ ビュー (sys.database_mirroring_witnesses) を使って返されます (両方のカタログ ビューで使用可能な列の詳細については、SQL Server Books Online の「sys.database_mirroring」と「sys.database_mirrroing_witnesses」(英語情報) を参照してください)。

データベース ミラーリング セッションがどのように動作するか、データベースがどのような状態になるかを理解するには、カタログ ビューからのデータを確認する必要があります。高可用性セッション (安全性が FULL で、ミラーリング監視サーバーが存在する) から始めます。次のクエリ コマンドは、プリンシパル サーバーとミラー サーバーのどちらかのデータベース ミラーリング セッションに関する基本情報を返します。

SELECT 
      DB_NAME(database_id) AS 'DatabaseName'
    , mirroring_role_desc 
    , mirroring_safety_level_desc
    , mirroring_state_desc
    , mirroring_safety_sequence
    , mirroring_role_sequence
    , mirroring_partner_instance
    , mirroring_witness_name
    , mirroring_witness_state_desc
    , mirroring_failover_lsn
FROM sys.database_mirroring
WHERE mirroring_guid IS NOT NULL;

次は、ミラーリング監視サーバーに関するセッション情報を返すクエリ コマンドの例です。

SELECT 
      Database_name
    , safety_level_desc
    , safety_sequence_number
    , role_sequence_number
    , is_suspended
    , is_suspended_sequence_number
    , principal_server_name
    , mirror_server_name
FROM sys.database_mirroring_witnesses;

ここで、標準的なデータベース ミラーリング セッションにおける両コマンドの出力を比較してみましょう。安全性を FULL に設定したサーバー A からサーバー B へのミラーリングのセットアップが完了していると仮定します (次のような構成をセットアップするサンプル コードについては、後述する「データベース ミラーリングの実装」の中の「セットアップとセキュリティ」を参照してください)。ミラーリング監視サーバーはサーバー W で、AdventureWorks データベースをミラーリングしています。表 3 は、2 台のパートナー サーバーに対する上記コマンドの出力例を示したものです。

表 3   サンプル高可用性セッションにおける 2 台のパートナー サーバーに対する sys.database_mirroring の出力

Partnermetadatacolumn	Principalvalues:Server A	Mirrorvalues:Server B
db_name(database_id)	AdventureWorks	AdventureWorks
mirroring_role_desc	PRINCIPAL	MIRROR
mirroring_safety_level_desc	FULL	FULL
mirroring_state_desc	SYNCHRONIZED	SYNCHRONIZED
mirroring_safety_sequence	1	1
mirroring_role_sequence	1	1
mirroring_partner_instance	TCP://B.corp.mycompany.com:5022	TCP://A. .corp.mycompany.com:5022
mirroring_witness_name	TCP://W.corp.mycompany.com:5022	TCP://W.corp.mycompany.com:5022
mirroring_witness_state_desc	CONNECTED	CONNECTED
mirroring_failover_lsn	95000000007300001	95000000007300001

データベース ミラーリング セッションにおける各パートナー サーバーは、それぞれの視点から見てすべて同じメタデータを保持し、個別のデータベース名、セッション全体の安全性設定、データベースのミラーリング状態、および 2 つのシーケンス カウンタを保持することに注意してください。

• mirroring_safety_sequence カウンタは、両方のパートナー サーバー上で保持され、安全性設定が変更されるたびに増分されます。

• mirroring_role_sequence カウンタは、両方のパートナー サーバーおよびミラーリング監視サーバー上で保持され、フェールオーバーが発生するたびに増分されます。

両方のパートナー データベースの状態とミラーリング監視サーバーの状態は、各パートナー サーバーによって保持されます。

• mirroring_state_desc は、セッション中のパートナー データベースの状態を示します。

• mirroring_witness_state_desc は、セッション中のミラーリング監視サーバーの状態を示します。

最後に、各パートナー サーバーには、mirroring_failover_lsn が含まれます。LSN は、ログ シーケンス番号の略で、トランザクション ログ レコードを一意的に識別します。ミラーリング パートナーは、セッション中に固定された最新のログ レコード セットから最大の LSN + 1 を保存します。上の表では、プリンシパル データベース上のアクティビティが少なかったために、プリンシパル サーバーとミラーリング監視サーバーの mirroring_failover_lsn が同じ値になっています。大量のデータが転送されると、ミラー サーバーは少し遅れて動作するため、プリンシパル サーバーの値がミラー サーバーの値を上回る可能性があります。

ここで、ミラーリング監視サーバー上で見つかったメタデータを比較してみましょう。次の表は、ミラーリング監視サーバーのメタデータから得られる比較可能な情報を示したものです。

表 4   パートナー サーバーのメタデータと相関関係があるミラーリング監視サーバー上の sys.database_mirroring_witnesses の出力

Witnessmetadatacolumn	Witnessvalues	対応する partnermetadatacolumn
database_name	AdventureWorks	db_name(database_id)
safety_level_desc	FULL	mirroring_safety_level_desc
safety_sequence_number	1	mirroring_safety_sequence
role_sequence_number	1	mirroring_role_sequence
is_suspended	0
is_suspended_sequence_number	1
principal_server_name	TCP://A. .corp.mycompany.com:5022
mirror_server_name	TCP://B.corp.mycompany.com:5022

注意が必要なのは、次の点です。ミラーリング監視サーバーのメタデータには、安全性の説明、安全性のシーケンス番号、および役割のシーケンス番号が含まれていますが、微妙に名前が異なります。また、ミラーリング監視サーバーは、セッションが中断されているかどうかに関するデータを保持し、プリンシパル サーバー名とミラー サーバー名を保持します。さらに、ミラーリング監視サーバーのカタログ ビューには、mirroring_failover_lsn の値は表示されず、データベースの状態も保持されません。

データベース ミラーリングに必要なメタデータ (特に、mirroring_failover_lsn とパートナー サーバー名) は、ミラーリング パートナー サーバーによって保持されます。ミラーリング監視サーバーは、高可用性モードにおけるミラーリング監視に必要なデータ (特に、セッション中の役割の変更回数を追跡するシーケンス番号) だけを保持します。このカウンタは、次の節のシナリオの中で説明しますが、プリンシパル サーバーが役割を変更するタイミングを判断するために使用されます。

データベース ミラーリングの状態と遷移

データベース ミラーリング セッション中はサーバーごとのデータベースの状態が保持され、それぞれのパートナー サーバー上に記録されるとともに、sys.database_mirroring カタログ ビューに表示されます。mirroring_state 列には状態ごとの数が表示され、mirroring_state_desc 列には状態ごとの分かりやすい名前が表示されます (データベースの数と名前の完全なリストについては、SQL Server Books Online の「sys.database_mirroring」(英語情報) を参照してください)。ミラーリング監視サーバーの状態情報も同じカタログ ビューに表示されます。

データベースごとに表示される状態のほかに、データベース ミラーリングに関与しているサーバーとデータベースの状態を説明するのに便利な次の 3 つの表現方法があります。

• プリンシパル サーバー上のデータは、トランザクション処理中に "公開" されますが、ログ データはミラー サーバーに送信されません。

• "データベース サービスを提供できない" 状態は、プリンシパル サーバーがユーザーのデータベースへの接続を受け入れず、すべてのトランザクションが処理されない状態を指します。

• データベース ミラーリング セッションにおいて、あるサーバーが他のサーバーと連絡を取ることができず、他のサーバーもそのサーバーと連絡を取ることができない場合、そのサーバーは "孤立" しています。

プリンシパル データベースが "公開" されると、ユーザー接続とトランザクション処理が可能になります。ただし、ログ レコードがミラー データベースに送信されないため、プリンシパル サーバーが故障した場合、ミラー サーバーは、プリンシパル サーバーが公開状態になった時点からのトランザクションを保持していません。また、プリンシパルのトランザクション ログが削除されないため、そのログ ファイルは無限に増大し続けます。

安全性が FULL の場合、プリンシパル サーバーは、他のサーバーとクォーラムを形成できなければ、データベース サービスの提供を中止します。ユーザー接続とプリンシパル データベース上のトランザクションを拒否し、すべてのユーザー接続を切断します。再びクォーラムが形成できるようになるとすぐに、データベースの提供を再開します。

データベース ミラーリング セッションにおいて、サーバーは稼動していても、他のサーバーとの通信回線がダウンしている場合があります。このような状態をサーバーが孤立していると言います。安全性が FULL の場合、プリンシパル サーバーが孤立すると、セッション中にクォーラムを形成できるサーバーが存在しないため、データベース サービスを提供できなくなります。

ここで、データベース ミラーリングの状態に焦点を当ててみましょう。プリンシパル サーバーとデータベースから始めます。

プリンシパル サーバーのデータベースの状態

安全性が FULL の場合、プリンシパル データベースの通常の動作状態は、SYNCHRONIZED (同期完了) 状態です。
安全性が OFF の場合、プリンシパル データベースの通常の動作状態は、SYNCHRONZING (同期中) 状態です。

• 安全性が FULL の場合、プリンシパル データベースは、常に SYNCHRONIZING 状態で開始して、プリンシパルとミラーのトランザクション ログが同期したときに SYNCHRONIZED 状態に遷移します。

• 安全性が FULL で、プリンシパル サーバーとミラーリング監視サーバーが切断状態でもトランザクションの処理を継続している場合は、データベースが公開されます。

• 安全性が FULL で、プリンシパル サーバーが他のサーバーとクォーラムを形成できない場合は、データベースを提供できません。すべてのユーザーがプリンシパル サーバーに接続できず、トランザクションが処理されません。

次の表は、プリンシパル データベースが遷移可能な状態と、状態遷移を引き起こすイベントを示したものです。

表 5   安全性が FULL と OFF の場合のプリンシパル データベースの状態

安全性	プリンシパルの初期状態	イベント	遷移後の状態	クォーラム	公開	データベースの提供
FULL	SYNCHRONIZING	同期化が発生	SYNCHRONIZED	あり	なし	あり
FULL	SYNCHRONIZED	セッションが中断	SUSPENDED	あり	あり	あり
FULL	SYNCHRONIZED	ミラー上で再実行エラーが発生	SUSPENDED	あり (ミラーリング監視が存在する場合) なし (ミラーリング監視が存在しない場合)	あり -	あり なし
OFF	SYNCHRONIZING	セッションが中断	SUSPENDED	-	あり	あり
OFF	SYNCHRONIZING	ミラー上で再実行エラーが発生	SUSPENDED	-	あり	あり
OFF	SYNCHRONIZING	ミラーが使用不能	DISCONNECTED	-	あり	あり

安全性が FULL の場合は、プリンシパル サーバーが最初に SYNCHRONIZING 状態に入り、ミラー サーバーと同期するとすぐに、両方のパートナーが SYNCHRONIZED 状態に入ります。安全性が OFF の場合は、パートナー データベースが SYNCHRONIZING 状態で開始して、通常のミラーリング中はその状態を維持します。

両方の安全性設定に共通して、セッションが中断した場合、または、ミラー サーバー上で再実行エラーが発生した場合は、プリンシパル サーバーが SUSPENDED 状態になります。ミラー サーバーが使用不能になると、プリンシパル サーバーが DISCONNECTED 状態に入ります。

DISCONNECTED 状態と SUSPENDED 状態では次のようになります。

• 安全性が FULL の場合、プリンシパル サーバーがミラーリング監視サーバーまたはミラー サーバーとクォーラムを形成できれば、プリンシパル データベースは公開されていると見なされます。これは、プリンシパル データベースに対するユーザー接続とトランザクション処理が可能であることを意味します。ただし、ログ レコードがミラー データベースに送信されないため、プリンシパル サーバーが故障した場合、ミラー サーバーはプリンシパル サーバーがその状態になった時点からのトランザクションを保持していません。また、プリンシパルのトランザクション ログが削除されないため、そのログ ファイルは無限に増大し続けます。

• 安全性が FULL の場合、プリンシパル サーバーは、他のサーバーとクォーラムを形成できなければ、データベースを提供できません。すべてのユーザーの接続が切断され、トランザクションは処理されません。

• 安全性が OFF の場合は、トランザクション ログ レコードがミラー サーバーに送信されないため、プリンシパル データベースは公開されていると見なされます。

Management Studio のオブジェクト エクスプローラで、サーバー ツリーのデータベース名の隣に、プリンシパル データベースの状態が表示されます。プリンシパルの SYNCHRONIZED 状態は "プリンシパル、同期中" と表示され、DISCONNECTED 状態は "プリンシパル、未接続" と表示されます。

ミラー サーバーのデータベースの状態

ミラー データベースは、プリンシパル データベースと同じ状態になりますが、常に復旧不可状態にあるため、ミラー中はデータベースを提供しません。次の表は、ミラー サーバーとデータベースの状態遷移を引き起こす最も一般的なイベントを示したものです。

表 6   安全性が FULL と OFF の場合のミラー データベースのミラーリング状態

安全性	ミラー サーバーの状態	イベント	遷移後の状態
FULL	SYNCHRONIZING	同期化が発生	SYNCHRONIZED
FULL	SYNCHRONIZED	セッションが中断	SUSPENDED
FULL	SYNCHRONIZED	ミラー上で再実行エラーが発生	SUSPENDED
FULL	SYNCHRONIZED	プリンシパル データベースが使用不能	DISCONNECTED
OFF	SYNCHRONIZING	セッションが中断	SUSPENDED
OFF	SYNCHRONIZING	ミラー上で再実行エラーが発生	SUSPENDED

プリンシパル サーバーと同様に、Management Studio のオブジェクト エクスプローラで、サーバー ツリーのデータベース名の隣に、ミラー データベースの状態が表示されます。ミラーの SYNCHRONIZED 状態は "ミラー、同期中" と表示され、DISCONNECTED 状態は "ミラー、未接続" と表示されます。

ミラーリング監視サーバーの状態

sys.database_mirroring カタログ ビュー内のミラーリング監視サーバーの状態には、CONNECTED、DISCONNECTED、および UNKNOWN の 3 種類があります。

表 7   ミラーリング監視サーバーの状態 (パートナー サーバー上に記録された場合)

ミラーリング監視サーバーの状態	イベント	遷移後の状態
CONNECTED	ミラーリング監視サーバーが使用不能	DISCONNECTED
	プリンシパルがミラーを初期化できない	UNKNOWN

ミラーリング監視サーバーの状態は、実際には、ミラーリング監視サーバー上ではなくパートナー サーバー上に記録されるため、これらの状態はパートナー サーバーの視点から設定されます。したがって、ミラーリング監視サーバーの DISCONNECTED 状態の表示は、パートナー サーバーがミラーリング監視サーバーから切断されていることを意味します。データベース ミラーリングの開始時に、ミラー サーバーがプリンシパル サーバーを初期化できなかった場合は、ミラーリング監視サーバーが UNKNOWN 状態に入ります。

トランザクション ログ レコードの転送

プリンシパル SQL Server とミラー SQL Server がメッセージやログ レコード ブロックの転送に使用する動作シーケンスは、安全性の設定によって異なります。最初に、同期転送について検証してから、非同期転送について検証します。

SQL Server がトランザクション イベントをトランザクション ログに保存するときに、ログ レコードがディスクに書き込まれる前に一時的にログ バッファに格納されます。データベース ミラーリングでは、ログ バッファがディスクに書き込まれる (固定される) たびに、プリンシパル サーバーがログ レコードの特定のブロックをミラー サーバーに送信します。

• 安全性が FULL の場合、プリンシパル SQL Server は、ログ レコードのブロックを書き込むときに、同じブロックをミラー サーバーに送信し、そのログに対するローカル I/O とリモート ミラー サーバーの I/O を基本的に同じものとして扱います。プリンシパル サーバーが、ローカル I/O (書き込み) の完了と、ミラー サーバーが I/O (書き込み) を完了したという応答の両方を待ってから、トランザクションが完了したと見なされるため、この転送は同期していると言えます。

  プリンシパル サーバーまたはミラー サーバーは、ログ バッファを固定するたびに、バッファの最大ログ シーケンス番号 (LSN + 1) を mirroring_failover_lsn としてメタデータに記録します。mirroring_failover_lsn は、2 つのパートナー データベースが最初からフェールオーバー後も同期し続けることができるように、トランザクション ログ内の最後に保証された点を決定するために使用されます。

  通常、プリンシパル サーバーがミラー サーバーにログ レコードを送信しているときは、プリンシパル サーバー上の mirroring_failover_lsn の方が上回ります。ミラー サーバーは、ログ レコードを固定するときに mirroring_failover_lsn を記録して、プリンシパル サーバーに応答を返しますが、プリンシパル サーバーがミラー サーバーからの応答を受信する前に、新しいログ レコードのセットを固定している場合があります。

  表 8 は、安全性が FULL の場合のプリンシパル サーバーとミラー サーバー間のイベントのサンプル シーケンスを示したものです。

  表 8   安全性が FULL (同期転送) の場合のイベントのサンプル シーケンス

  サーバー A	サーバー B
  プリンシパル、同期完了	ミラー、同期完了
  複数ステートメント トランザクションがデータ変更の抑制を開始する
  プリンシパル データベースのトランザクション ログ レコードがトランザクション ログ バッファに入力される
  トランザクション ログ バッファがディスクに書き込まれ (固定され)、 ログ レコードのブロックがミラー サーバーに送信されて、 プリンシパル サーバーがそのログ ブロックの mirroring_failover_lsn を記録し、 プリンシパル サーバーがミラー サーバーからの確認応答を待つ
  	ミラー サーバーがログ レコードのブロックをトランザクション ログ バッファ内に受信する
  	ミラー サーバーがログ バッファをディスクに書き込み、 mirroring_failover_lsn を記録して、 ログ ブロックが固定されたことをプリンシパル サーバーに通知する
  プリンシパル サーバーがミラー サーバーによってログ レコードのブロックがディスクに書き込まれたという通知を受信する	ミラー サーバーが再実行操作用キュー内のトランザクション ログ レコードの再生を継続する
  トランザクションに対する COMMIT (コミット) がトランザクション ログ バッファに入力される
  トランザクション ログ バッファがディスクに書き込まれ (固定され)、 COMMIT を含むログ レコードのブロックがミラー サーバーに送信されて、 プリンシパル サーバーがそのブロックの mirroring_failover_lsn を記録し、 プリンシパル サーバーがミラー サーバーからの確認応答を待つ
  	ミラー サーバーがログ レコードのブロックをトランザクション ログ バッファ内に受信する
  	ミラー サーバーがログ バッファをディスクに書き込み、 mirroring_failover_lsn を記録して、 ログ ブロックが固定されたことをプリンシパル サーバーに通知する
  プリンシパル サーバーがミラー サーバーによってログ レコードのブロックがディスクに書き込まれたという通知を受信し、 トランザクションがコミットされたと見なされる	ミラー サーバーが再実行操作用キューから COMMIT を含むトランザクション ログ レコードを再生し、データ ページを変更する
  新しいトランザクションがプリンシパルのログ バッファに書き込まれる

  上記シーケンスのキー ポイントを以下に示します。安全性が FULL の場合、プリンシパル サーバーは、ログ バッファに書き込むと同時に、そのログ レコードのコピーをバッファからミラー サーバーに送信します。その後、プリンシパル サーバーがローカル I/O の完了とミラー サーバーの I/O の完了を待ってから、トランザクションが完了したと見なされます。プリンシパル サーバーは、ミラー サーバーからの応答を受信してから、次の書き込みを実行することができます。

  安全性が FULL の場合のプリンシパル サーバーとミラー サーバー間の緊密な連携に反して、データベース ミラーリングは分散トランザクションではなく、2 フェーズ コミットを使用しません。

  • データベース ミラーリングでは、2 つのトランザクションを 2 台のサーバーに展開することはできますが、1 つのトランザクションを 2 台のサーバーに分散させることはできません。

  • データベース ミラーリングは、パートナー サーバーを分散トランザクション内のリソース マネージャとして使用しません。

  • データベース ミラーリングのトランザクションには、準備フェーズとコミット フェーズがありません。

  • 最も重要な分散トランザクションとの違いは、ミラー サーバー上でコミットが失敗しても、プリンシパル サーバー上でトランザクションのロール バックが発生しないことです。

• 安全性が OFF の場合、プリンシパル サーバーはミラー サーバーからの確認応答を待ちません。そのため、表 9 に示すように、プリンシパル サーバー上でコミットされたトランザクションの数がミラー サーバーのそれを上回る可能性があります。

  表 9   安全性が OFF (非同期転送) の場合のイベントのサンプル シーケンス

  サーバー A	サーバー B
  プリンシパル、同期中	ミラー、同期中
  複数ステートメント トランザクションがデータ変更の抑制を開始する
  データ変更用のトランザクション ログ レコードがトランザクション ログ バッファに書き込まれる
  トランザクション ログ バッファがディスクにフラッシュされ (固定され)、 ログ レコードのブロックがミラー サーバーに送信されて、 プリンシパル サーバーがそのブロックの mirroring_failover_lsn を記録する
  トランザクションに対する COMMIT (コミット) がその他のトランザクション アクティビティとともにトランザクション ログ バッファに入力される	ミラー サーバーがログ レコードのブロックをトランザクション ログ バッファ内に受信する
  トランザクション ログ バッファがディスクに固定され、 COMMIT を含むログ ブロックがミラー サーバーに送信される	ミラー サーバーがログ バッファをディスクに書き込み、 mirroring_failover_lsn を記録して、 ログ ブロックが固定されたことをプリンシパル サーバーに通知する
  トランザクションがコミットされたと見なされる	ミラー サーバーが再実行操作用キュー内のトランザクション ログ レコードの再生を継続する
  	ミラー サーバーがログ レコードのブロックをトランザクション ログ バッファ内に受信する
  	ミラー サーバーがログ ブロックをディスクに書き込むことによって固定し、 mirroring_failover_lsn を記録し、 ログ ブロックが固定されたことをプリンシパル サーバーに通知する

データベース ミラーリングの役割変更

データベース ミラーリングのフェールオーバーは、データベース ミラーリング サーバーのスナップショットまたはアプリケーションから対処できる問題です。データベース ミラーリング サーバーから見ると、フェールオーバーとは、セッション中にミラー サーバーをプリンシパル サーバーに変換し、新しく復旧されたデータベースをプリンシパル データベースとして使用することです。フェールオーバーには、自動、手動、強制サービスの 3 種類があります。

• 自動   高可用性動作モードでのみ発生します (安全性は FULL で、ミラーリング監視がセッションに含まれます)。

• 手動   高可用性動作モードと高度な保護動作モードで発生します (安全性は FULL で、パートナー データベースはともに SYNCHRONIZED 状態です)。

• 強制サービス (データ損失を許可)   手動で迅速にミラー データベースを復旧するために、主として高パフォーマンス動作モード (安全性 OFF) で使用されます。

安全性が FULL の場合、サーバーの役割を交換する最良の方法は、強制サービス フェールオーバーではなく手動フェールオーバーを使用することです。

自動フェールオーバー

自動フェールオーバーは、高可用性動作モード (安全性 FULL でミラーリング監視を含む) でのデータベース ミラーリングの特徴の 1 つです。ほとんどの場合、SQL Server は自動データベース ミラーリング フェールオーバーを数秒で完了することができます。SQL Server がこれを実現可能な理由の 1 つは、データベース ミラーリング セッションに関与しているすべての SQL Server がお互いの存在を確認するためです。このプロセスは、ping と呼ばれていますが、IP アドレス を調査する通常の ping よりもはるかに多くの処理を含んでいます。ミラー サーバーとミラーリング監視サーバーは、物理サーバーの存在、SQL Server インスタンスの存在、およびプリンシパル データベースの可用性を確認するために、プリンシパル サーバーと連絡を取ります。同様に、プリンシパル サーバーとミラーリング監視サーバーは、物理サーバーの可用性、SQL Server インスタンス、およびミラー データベースの復旧状態を確認するために、ミラー サーバーを ping します。

データベース ミラーリング セッションが、安全性 FULL、ミラーリング監視サーバーありでセットアップされたと仮定します。ミラー サーバーのサーバー B は、ping を通して、プリンシパル サーバーのサーバー A が使用不能であることを検出します。サーバー B は、ミラーリング監視サーバーと連絡を取って、ミラーリング監視サーバーからもサーバー A が確認できないという応答を受信します。また、ミラーリング監視サーバーとクォーラムを形成し、自身をプリンシパルに昇格させます。さらに、データベースを復旧し、プリンシパルを引き受けたことをミラーリング監視サーバーに通知します (ただし、データベースは切断状態になり、新しいプリンシパル データベースのトランザクション ログは削除できません)。

サーバー B の新しいプリンシパル データベースは、トランザクション ログ アクティビティの再生を継続しますが、ずっと再実行状態にあったため、行うべきことはほとんど残っていません。すべての SQL Server エディションのデータベース ミラーリングでは、新しいプリンシパル データベースは再実行状態を終了するとすぐに使用可能になります。データベースが取り消し状態に入ると、ユーザー接続を受け入れ可能になります。通常、再実行状態は数秒間で終了しますが、その後の取り消しフェーズはかなり時間がかかる可能性があります。データベース ミラーリングでは、新しいプリンシパル データベースは、再実行プロセスが終了するとすぐに、ユーザー接続を提供可能になります。新しいプリンシパル サーバー B のデータベースは、DISCONNECTED 状態で公開されますが、再実行フェーズが終了するとすぐに、データベースを提供することができます。

通常、古いプリンシパル サーバーから新しいプリンシパル サーバーへのアプリケーション全体のリダイレクトは、データベース ミラーリングの自動フェールオーバーより時間がかかります。アプリケーションは、接続を検出したり、再実行したりする必要があるため、処理に余分な時間がかかります。さらに、SQL Server 認証を使用する新しいログインがサーバーに追加されている場合は、システム ストアド プロシージャの sp_change_users_login を使用して、これらのログインを新しいプリンシパル サーバーにマップする必要があります。また、SQL エージェント ジョブなどの古いプリンシパル サーバー上の重要なオブジェクトのすべてが新しいプリンシパル サーバーにコピーされていなかった場合は、完全なアプリケーション フェールオーバーが遅延する可能性があります (詳細については、後述する導入に関する節の「ミラー サーバーにおけるフェールオーバーへの準備」を参照してください)。

ここで、古いプリンシパル サーバーがオンライン状態になったと仮定します。手動フェールオーバーまたは自動フェールオーバー (きわめて迅速に古いプリンシパル サーバーを復旧させるフェールオーバー) によって 2 台のサーバーが役割を交換中の場合は、そのサーバー間でのネゴシエーション プロセスが必要です。この 2 台のパートナー サーバーは、ミラーリングを再開する前に、お互いに同期する方法を見つける必要があります。このプロセスでは、mirroring_failover_lsn が重要な役割を果たします。

サーバー A (新しいミラー) の方が低い値ですが、どのくらい低いかは明確ではありません。サーバー A は、サーバー B (新しいプリンシパル) から受け取った最新の mirroring_failover_lsn をサーバー B に通知します。一方、サーバー B は、mirroring_failover_lsn をより最新の状態にする作業に注力します。それから、両サーバーは、サーバー B が正しいフェールオーバー LSN を持つこと、サーバー A がそれに追いつかなければならないことに同意します。サーバー B は、十分な数のトランザクション レコードをサーバー A に送信し、サーバー A がそれらを再生することによって同期が完了します。

手動フェールオーバー

手動フェールオーバーは、2 台のパートナー サーバー間の役割の交換をエラーなしで、順序正しく実現する方法です。手動フェールオーバーを行うには、安全性を FULL に設定し、プリンシパル データベースとミラー データベースを SYNCHRONIZED 状態にする必要があります。

手動フェールオーバーを起動するには、プリンシパル サーバー上で次の ALTER DATABASE コマンドを呼び出します。

ALTER DATABASE AdventureWorks SET PARTNER FAILOVER;

または、Management Studio の [データベースのプロパティ] ダイアログの [ミラーリング] ページで [フェールオーバー] ボタンをクリックします。手動フェールオーバーは、現在のユーザーを切断状態にし、古いプリンシパル データベースから終了していないトランザクションをロール バックします。また、再実行キュー内の完了したすべてのトランザクションを終了させ、終了していないトランザクションを (取り消しフェーズで) ロール バックすることによって、ミラー データベースを復旧します。古いミラー データベースにプリンシパルが割り当てられ、古いプリンシパル データベースは新しいミラーの役割を引き受けます。この 2 台のサーバーは、それぞれの mirroring_failover_lsn の値に基づいてミラーリングの新しい開始点を決定し、交換した役割を実行します。

サーバーのオペレーティング システムまたは SQL Server インスタンスへのローリング アップグレードを実施する手段として手動フェールオーバーを使用することができます。これによって、ミラーリングを初期化する前にミラー サーバーをアップグレードすることができます。詳細については、SQL Server Books Online の「Manual Failover」(英語情報) を参照してください)。

強制サービス

ミラー サーバー上で次の ALTER DATABASE コマンドを呼び出して、強制サービスを起動することができます。

ALTER DATABASE AdventureWorks SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS;

通常、このコマンドは、安全性が OFF で、プリンシパル サーバーが動作していない場合にだけ有効です。このコマンドは、安全性を FULL にして使用することもできますが、復旧されたミラー サーバーがクォーラムを形成できなければ、データベースを提供できません。そのため、このコマンドは安全性が OFF のとき (高パフォーマンス モード) にのみ使用することをお勧めします。非同期転送では、プリンシパル サーバーからコミットされたトランザクションに遅れないようにミラー サーバーを維持することが困難なため、データの一部が損失する可能性があります。

データベース ミラーリングの可用性シナリオ

この節では、次の 2 種類のイベントに基づくデータベース ミラーリング シナリオの予想される可用性の結果について説明します。

• 1 つまたは複数のサーバーまたはデータベースが故障している

• 1 つまたは複数のサーバー間の通信回線が切断している

パートナー データベースの 1 つまたは SQL Server インスタンスの 1 つが使用不能になると、サーバー ダウンが発生する可能性があります。または、サーバー自体は動作していても、データベース ミラーリング パートナー サーバー間の通信回線が切断している可能性があります。

次のシナリオでは、2 つのコンポーネントの同時故障を、1 つのコンポーネントに続いて別のコンポーネントが故障した連続故障と見なします。たとえば、サーバー A とサーバー B が同時に故障した場合、ミラーリング システムはその故障を連続故障 (サーバー A の後にサーバー B が故障、またはその逆) として扱います。

次のルールに基づいて、故障イベントの結果を予想することができます。

1. 安全性が FULL の場合、プリンシパル サーバーがデータベースを提供し続けるためには、1 台以上の別のサーバーとのクォーラムが必要です。

   プリンシパル サーバーがクォーラムを形成できなければ、データベースを提供することができません。

2. 安全性が FULL で、ミラー サーバーとミラーリング監視サーバーの両方がプリンシパル サーバーを確認できない場合、ミラー サーバーはミラーリング監視サーバーとクォーラムを形成し、役割を変更して新しいプリンシパル サーバーになります。

   これが自動フェールオーバーです。

3. 安全性が FULL で、プリンシパル サーバーがミラーリング監視サーバーとのクォーラムでの作業が完了しているのに、ミラー サーバーとの回線が切断している場合は、プリンシパル サーバーが故障してもミラー サーバーはミラーリング監視サーバーとクォーラムを形成できず、新しいプリンシパル サーバーの役割を引き受けることができません。

   これによって、セッション中の作業の損失が回避されます。

4. 安全性が FULL で、故障したプリンシパル サーバーがダウンまたは孤立後にセッションに復帰して、古いミラー サーバーが既に (ミラーリング監視サーバーとのクォーラムで) 新しいプリンシパルを引き受けていた場合は、古いプリンシパル サーバーがセッション中に新しいミラーを引き受けます。

   フェールオーバー イベント中に、ミラー サーバーとミラーリング監視サーバーは、ミラーリング ロール シーケンス カウンタを増分しています。古いプリンシパルのミラーリング ロール シーケンス カウンタは、他のパートナー サーバーやミラーリング監視サーバーのそれよりも値が低いため、この 2 つのサーバーは古いプリンパル サーバーがセッションに復帰する前にクォーラムを形成しており、新しいプリンシパル サーバー上で新しい作業が発生していた可能性があります。古いプリンシパル サーバーが、セッション中にミラーの役割を引き受けます。

5. 安全性が FULL で、ミラーリング監視サーバーがセッションに参加していない、または、何らかの形でセッションから切り離されている場合、パートナー サーバーが故障するとクォーラムの形成が不可能になり、プリンシパル サーバーはプリンシパル データベースを提供できません。

   ミラーリング監視サーバーが安全性 FULL のセッションに参加していない場合は、クォーラムが形成できないため、自動フェールオーバーが発生しません。

サーバー ダウンを伴う高可用性シナリオ

高可用性動作モードでのデータベース ミラーリングの目的は、できるだけデータベースの使用可能状態を維持することです。このモードでは、プリンシパル データベースが使用不能になっても、データベース ミラーリングによってミラー データベースがすぐに使用可能になります。次のシナリオ セットでは、最初に 3 台の独立したサーバーを含む高可用性構成を取り上げます。

次の高可用性シナリオでは、図 1 に示すように、サーバー A がプリンシパルとして開始し、サーバー B がミラーに、サーバー W がミラーリング監視になります。

図 1   サンプル データベース ミラーリング セッションが、高可用性動作モードで開始する

3 台すべてのサーバーが物理的に同じサイト上に存在してローカル ネットワーク経由で接続されているか、独立サイト上に存在して、WAN 経由で接続されているとします。サーバー A とサーバー B は役割を交換しますが、サーバー W はミラーリング監視サーバーのまま変わりません。

ここで、サーバーの 1 つがダウンしたらどうなるか考えてみましょう。

シナリオ HASL1.1 : プリンシパル サーバーのダウン

次のシナリオでは、高可用性シナリオでプリンシパル サーバーがダウンしたときにどうなるかを検証します。図 2 は、複数の役割とそれらがパートナー サーバー間でどのように変化するかを示したものです。

図 2   高可用性モードで、プリンシパル サーバー A が故障した場合は、フェールオーバーが発生する

プリンシパル サーバー A がダウンすると、ミラー サーバーとミラーリング監視サーバーがクォーラムを形成して、自動フェールオーバーが発生します。元のプリンシパル サーバーを復活させることができた場合は、ミラーの役割を引き受けることになります。

メモ   高可用性モードでフェールオーバーを引き起こすには、物理サーバーがダウンする、プリンシパル サーバー上の SQL Server インスタンスが停止または故障する、サーバー上のプリンシパル データベースが使用不能または不安定になるなど、複数のレベルの故障が発生することが必要です。次のシナリオでプリンシパル サーバーがダウンした場合は、これらのいずれかのイベントによってフェールオーバーが引き起こされる可能性があります。

サーバー B とサーバー W はクォーラムを形成可能で、どちらもサーバー A を確認できないため、サーバー B は自身を新しいプリンシパルに昇格させることができます。ただし、ミラー サーバーがない場合は、ミラーリング セッションが公開されていると見なされます。

サーバー A を復活させると、サーバー A が新しいプリンシパルになり、ミラーリング セッションは公開されなくなります。

1 台のサーバーが故障することは、めったにありません。さらに、2 台のサーバーが故障する確率は、もっと低くなります。まれにしか発生しないとしても、その結果を調査する必要があります。

2 台のサーバーが同時にまたはほぼ同時に故障する可能性がありますが、データベース ミラーリングから見ると、1 台のサーバーが故障してから別のサーバーが故障したことになります。そのため、これらのシナリオでは、サーバーが連続して故障したときにどうなるかだけについて検証します。

次の 2 つのシナリオでは、プリンシパル サーバー A が故障してから、次の 2 つの代替サーバーが故障したときにどうなるかを検証します。

• 新しいプリンシパル サーバー B の故障

• ミラーリング監視サーバー W の故障

シナリオ HASL1.2 : プリンシパル サーバーのダウンに続く新しいプリンシパル サーバーのダウン

上のシナリオで説明したように、高可用性モードで、最初にプリンシパル サーバーがダウンした場合は、フェールオーバーが発生します。図 3 は、次に新しいプリンシパル サーバーが故障した場合は、サーバーを復元しても、新しいプリンシパル サーバー (サーバー B) がプリンシパルを保持することを示したものです。

図 3   プリンパル サーバーのダウンに続く新しいプリンシパル サーバーのダウンによる役割の変化

拡大表示する

サーバー A が故障した後、サーバー B が新しいプリンシパルになりますが、サーバー B はデータをミラー サーバーに送信できないため、データベースを提供できたとしてもプリンシパルが公開されます。サーバー A の故障に続いてサーバー B が故障した場合は、ミラーリングは行われません。

最初にサーバー A を復活させた場合、サーバー A は、ミラーリング監視サーバー上の mirroring_role_sequence 番号から、ミラーリング監視サーバーが既に新しいクォーラムを形成済みであることを認識します。サーバー A は、ミラーを引き受け、サーバー B が復活するのを待ちます。サーバー B を復活させるとすぐに、サーバー B はサーバー A へのミラーリング プロセスを開始します。最初にサーバー B を復活させた場合は、HASL1.1 で示した元のシナリオに戻ります。

メモ   サーバー A の後にサーバー B がダウンし、それからサーバー W がダウンして、3 台すべてのサーバーがダウンした場合は、サーバー A とサーバー B に対して行われた役割の変更がサーバーの復元シーケンスとは無関係に保持されます。

シナリオ HASL1.3 : プリンシパル サーバーのダウンに続くミラーリング監視サーバーのダウン

プリンシパル サーバーがダウンすると、フェールオーバーが発生します。図 4 に示すように、続いてミラーリング監視サーバーが故障します。

図 4   最初のプリンシパル サーバーのダウンに続いてミラーリング監視サーバーがダウンした場合は、新しいプリンシパル サーバーはデータベースを提供できない

拡大表示する

プリンシパル サーバー A がダウンしてから、ミラーリング監視サーバー W がダウンした場合は、新しいプリンシパル サーバー B がプリンシパルを保持しますが、孤立するうえに、クォーラムを形成できないため、データベースを提供できません。

最初にサーバー A を復活させた場合は、フェールオーバーが発生するため、サーバー B の mirroring_role_sequence 番号がサーバー A のそれを 1 つ上回ります。これによって、サーバー A は、サーバー B がサーバー A の代わりにプリンシパルを引き受けたことを認識します。サーバー A はサーバー B とクォーラムを形成し、ミラー サーバーになります。それから、両サーバーが同期します。サーバー W を復活させるまで、自動フェールオーバーは発生しません。

メモ   サーバー A の後にサーバー W がダウンし、それからサーバー B がダウンした場合は、サーバー A とサーバー B の新しい役割がサーバーの復元シーケンスとは無関係に保持されます。

シナリオ HASL2.1 : ミラー サーバーのダウン

最初にミラー サーバーがダウンした場合、プリンシパル サーバーは、ミラー サーバーにデータを送信できないため、公開されていると見なされます。図 5 は、ミラー サーバー B がダウンした場合の役割の変化を示したものです。

図 5   高可用性モードで、ミラー サーバー B が故障した場合、フェールオーバーは発生しない

自動フェールオーバーは発生せず、パートナー間の役割の交換は行われません。サーバー B が復元されると、3 台すべてのサーバーが元の役割と状態に戻ります。

次の表は、ミラー サーバー B がダウンして復活するまでのデータベースの状態とクォーラムを示したものです。

予備のデータベースにデータが保存されていないため、ミラーなしでセッションが公開されることに注意してください。

サーバー B を復元するとすぐに、サーバー B はミラーを再開し、2 台のパートナー サーバーが同期した時点で、ミラーリング セッションは公開されているとは見なされなくなります。

次の 2 つのシナリオでは、ミラー サーバー B に続いてプリンシパル サーバー A またはミラーリング監視サーバー W が故障した場合にどうなるかを検証します。

シナリオ HASL2.2 : ミラー サーバーのダウンに続くプリンシパル サーバーのダウン

ミラー サーバーに続いてプリンシパル サーバーがダウンした場合は、パートナー サーバーの役割は変化しません。図 6 は、さまざまな経路でサーバーを復活させた場合にどのように役割が変化するかを示したものです。

図 6   ミラー サーバーに続いてプリンシパル サーバーがダウンした場合、ミラーリング監視サーバーが孤立する

拡大表示する

サーバー B に続いてサーバー A がダウンした後は、図の右上に示す状態になります。

最初にサーバー B を復活させた場合、サーバー B は、ミラーリング監視サーバー W から、サーバー A がプリンシパルを継続しており、mirroring_failover_lsn が増分されていない、つまり、フェールオーバーが発生していないことを認識します。その結果、サーバー B はミラーを継続します。その後、サーバー W を復活させれば、セッションが元の状態に復元されます。

メモ   サーバー B の後にサーバー A がダウンし、それからサーバー W がダウンした場合は、どの順番でサーバーを復活させても結果は同じになります。

シナリオ HASL2.3 : ミラー サーバーのダウンに続くミラーリング監視サーバーのダウン

ミラー サーバーに続いてミラーリング監視サーバーがダウンした場合は、プリンシパル サーバーが孤立し、他のどのサーバーともクォーラムを形成できません。そのため、サーバー A は、図 7 の右上に示すように、データベース サービスの提供を中止しなければなりません。

図 7   ミラー サーバーに続いてミラーリング監視サーバーがダウンすると、プリンシパル サーバーはデータベース サービスを提供できなくなる

拡大表示する

ミラー サーバーに続いてミラーリング監視サーバーが故障している間、プリンシパル サーバー A は、プリンシパルを保持しますが、他のどのサーバーともクォーラムを形成できないうえに安全性が FULL のため、データベースを提供できず、すべてのユーザーを切断します。

最初にサーバー B を復活させた場合は、ミラーリング監視サーバーがないために自動フェールオーバーは発生しませんが、ミラーリングは再開します。

最初にサーバー W を復活させた場合は、図 5 で示すシナリオと同じになります。

メモ   サーバー B の後にサーバー W がダウンし、それからサーバー A がダウンした場合は、どの順番でサーバーを復活させても最終結果は同じになります。

シナリオ HASL3.1 : ミラーリング監視サーバーのダウン

ミラーリング監視サーバーが故障したときは、ミラーリングは継続しますが、自動フェールオーバーは発生しません。もう 1 台のサーバーのダウンは、クォーラムが形成できないことと、そのためにプリンシパル サーバーがデータベースを提供できないことを意味します。

図 8   高可用性モードで、最初にミラーリング監視サーバー W が故障した場合、ミラーリングは継続する

サーバー W を復元すると、パートナー サーバーのサーバー A とサーバー B はそれぞれ元の役割を保持します。

次の表は、ミラーリング監視サーバーがダウンして復活するまでのデータベースの状態とクォーラムの変化を示したものです。

次の 2 つのシナリオでは、ミラーリング監視サーバー W に続いてプリンシパル サーバー A またはミラー サーバー B が故障した場合にどうなるかを検証します。

シナリオ HASL3.2 : ミラーリング監視サーバーのダウンに続くプリンシパル サーバーのダウン

最初にミラーリング監視サーバーが故障したときは、ミラーリングは継続しますが、自動フェールオーバーは発生しません。残りの 2 台のサーバーのどちらかが故障した場合は、クォーラムは形成されず、最後に残ったサーバーは孤立します。

図 9   最初のミラーリング監視サーバーの故障後にプリンシパル サーバーが故障した場合、パートナーは変化しない

最初にサーバー W を復活させた場合は、サーバー B がミラーリング監視サーバーから、最後の正常なプリンシパルがサーバー A だったこと、そのため、サーバー B はミラーのままであることを認識します。最後にサーバー A を復活させると、サーバー A はプリンシパルを保持します。

メモ   サーバー W の後にサーバー A がダウンし、それからサーバー W がダウンした場合は、どの順番でサーバーを復活させても最終結果に影響を与えません。

シナリオ HASL3.3 : ミラーリング監視サーバーのダウンに続くミラー サーバーのダウン

ミラーリング監視サーバーが故障してから、ミラー サーバーが故障した場合は、プリンシパル サーバーが孤立します。図 10 に示すように、プリンシパル サーバーは、安全性が FULL で、クォーラムを形成できないため、データベース サービスを提供することができません。

図 10   ミラーリング監視サーバーに続いてミラー サーバーが故障した場合、プリンシパル サーバーはデータベースの提供を中止しなければならない

拡大表示する

メモ   サーバー W の後にサーバー B がダウンし、それからサーバー W がダウンした場合は、どの順番でサーバーを復活させても最終結果に影響を与えません。

結論 : サーバー ダウンを伴う高可用性シナリオ

以上のシナリオから複数の結論が導かれます。高可用性動作モードでは次のことが起こります。

1. 最初にプリンシパル サーバーが使用不能になった場合は、自動フェールオーバーが発生して、元のミラー サーバーがプリンシパルを引き受け、ユーザー アクティビティに対してデータベースを使用可能にします。その後のサーバーの故障と復元は、新しいプリンシパル サーバーを含むミラーリングの全体構成に影響を与えません。逆方向のミラーリングが継続します。

2. 最初にミラー サーバーが使用不能になった場合は、自動フェールオーバーが発生しません。その後のサーバーの故障と復元シーケンスは、ミラーリング パートナーの役割に影響を与えません。

3. 最初にミラーリング監視サーバーが使用不能になった場合は、自動フェールオーバーは発生せず、パートナー サーバーは元の役割を保持します。その後のサーバーの故障と復元シーケンスは、パートナーの役割に影響を与えません。

次の表は、1 台または 2 台のサーバーがダウンする高可用性シナリオの結果をまとめたものです。表内の仮定条件は、安全性が FULL で、ミラーリング セッション サーバーが以下の状態にあることです。

A : プリンシパル、SYNCHRONIZED

B : ミラー、SYNCHRONIZED

W : ミラーリング監視、CONNECTED

表内の灰色で強調表示された部分は、フェールオーバー シナリオを示します。

表 10   1 台または 2 台のサーバーが故障した場合のパートナー サーバーの役割とデータベースの状態のまとめ

拡大表示する

通信回線ダウンを伴う高可用性シナリオ

高可用性動作モードでは、3 つの SQL Server インスタンスが必要です。サーバーが、遠隔地にある 2 つまたは 3 つの独立サイトに設置されている場合は、サイト間の通信障害が発生する可能性が十分あります。つまり、サーバーは使用可能でも通信回線が切断する可能性があります。このシナリオは、これまでのシナリオより若干複雑ですが、適用するプリンシパル サーバーは同じです。

次の通信回線ダウンを伴う高可用性動作モード シナリオは、2 つのセットで構成されます。最初のセットは、独立サイトに設置された 3 つの SQL Server インスタンスに基づいているため、3 本の独立した通信回線を伴います。2 番目のセットは、2 つの独立サイトに設置されたサーバーに基づいており、1 組のサーバーと 3 番目のサーバー間の 1 本の通信回線を伴います。

最初のセットから説明を始めるにあたって、データベース ミラーリング セッション内のすべてのサーバー間を結ぶ 3 本の独立通信回線があると仮定します。たとえば、プリンシパル サーバー、ミラー サーバー、およびミラーリング監視サーバーが、3 つの独立したサイトに設置されているとします (または、3 台のサーバーが 1 つのサイトに設置され、専用回線で接続されているとすることもできます)。

初期状態は、サーバー A がプリンシパル データベースを収容しており、ミラー化されたデータベースを収容しているサーバー B とパートナーとして同期しています。また、安全性は FULL に設定され、ミラーリング監視サーバー (サーバー W) がデータベース ミラーリング セッションに含まれます。図 11 は、この初期構成を示したものです。

図 11   3 台の独立サーバーが 3 本の独立通信回線を使用している初期高可用性構成

メモ   以下の図の説明については、前述の「サーバー ダウンを伴う高可用性シナリオ」を参照してください。

図 11 には、最初に切断される可能性のある 3 本の回線 (A/B、A/W、B/W) が示されています。1 本の通信回線がダウンしても 3 台すべてのサーバーは動作を継続することに注意してください。表 11 に示すように、プリンシパル サーバーとミラー サーバー間の回線だけが何らかの影響を与えます。

表 11   1 本の通信回線がダウンした場合の結果

初期状態	イベント	クォーラム	結果	状態
A : プリンシパル、 SYNCHRONIZED B : ミラー、 SYNCHRONIZED W : ミラーリング監視、 CONNECTED	A/B 回線切断	A と W	A のデータベースがサービス提供中で、公開されている	A : プリンシパル、 DISCONNECTED B : ミラー、 DISCONNECTED W : ミラーリング監視、 CONNECTED
	A/W	A と B	A のデータベースがサービス提供中	A : プリンシパル、 SYNCHRONIZED B : ミラー、 SYNCHRONIZED W : ミラーリング監視、 CONNECTED
	B/W	A と B	A のデータベースがサービス提供中	A : プリンシパル、 SYNCHRONIZED B : ミラー、 SYNCHRONIZED W : ミラーリング監視、 CONNECTED

プリンシパル サーバーとミラー サーバー間の接続が切断したときだけ影響があります。プリンシパル サーバーとミラーリング監視サーバー間、またはミラー サーバーとミラーリング監視サーバー間の接続が切断しても、データベース ミラーリング セッションの動作は変化しません。

要約すると、表の HACL1 は次のことを示しています。

• 単一回線切断のうち、プリンシパル サーバーとミラー サーバー間の回線切断だけがデータベース ミラーリングに影響を与えます。プリンシパル サーバーは、ログ レコードをミラー サーバーに送信できないため、公開されます。

ここで、2 本目の回線が切断したらどうなるか考えてみましょう。2 本の回線は、同時にまたは連続して切断する可能性があります。

2 本の回線が同時に切断した場合も、1 本の回線が切断してからもう 1 本の回線が切断した場合も結果は同じです。ただし、正確なシーケンスを前もって予測することはできません。その後の動作が、同時切断と同じシーケンスを示しているに過ぎません。

したがって、ここでは連続回線切断だけを検証します。表 12 は、この節で命名された高可用性モードでの通信回線切断に関する基本シナリオを示したものです。

表 12   2 回線レベルの通信回線切断シナリオは、1 台のサーバー ダウン シナリオとほとんど同じである。

シナリオ	最初の回線切断	シナリオ	2 番目の回線切断	結果	残ったサーバーに関する同等のシナリオ	参照シナリオ
HACL1.1	A と W	HACL1.2	A/W	サーバー A 孤立	サーバー A ダウン	(なし)
		HACL1.3	B/W	サーバー B 孤立	サーバー B ダウン	HASL2.1
HASL2.1	A/W	HASL2.1	A/B	サーバー A 孤立	サーバー A ダウン	HASL1.1
		HASL2.2	B/W	サーバー W 孤立	サーバー W ダウン	HASL3.1
HACL3.1	B/W	HACL3.1	A/W	サーバー W 孤立	サーバー W ダウン	HASL3.1
		HACL3.2	A/B	サーバー B 孤立	サーバー B ダウン	HASL2.1

表の HALC2 は、連続 2 通信回線切断のすべてが、前の節の単一サーバー ダウン シナリオと同等であることを示しているため、ここではその分析は省略します。

重要事項

• プリンシパル サーバーとミラーリング監視サーバー間の回線が切断してから、プリンシパル サーバーとミラー サーバー間の回線が切断する 2 回線切断を伴うシナリオだけがフェールオーバーを引き起こします。

プリンシパル サーバーとミラー サーバー間の回線が切断してから、プリンシパル サーバーとミラーリング監視サーバー間の回線が切断した場合は、プリンシパル サーバーが孤立して、ミラー サーバーとミラーリング監視サーバーがプリンシパル サーバーを確認できなくても、フェールオーバーは発生しません。

シナリオ HACL1.2 について、さらに注意深く検証してみます。

シナリオ HACL1.2 : プリンシパル サーバーとミラー サーバー間の回線切断に続くプリンシパル サーバーとミラーリング監視サーバー間の回線切断

プリンシパル サーバーとミラー サーバー間の回線が切断してから、プリンシパル サーバーとミラーリング監視サーバー間の回線が切断した場合は、プリンシパル サーバーが孤立します。プリンシパル サーバーは、他のサーバーを確認できないため、クォーラムを形成できません。一方、ミラー サーバーとミラーリング監視サーバーは、プリンシパル サーバーが稼動しているかどうかが確認できないため、サーバー B がプリンシパルを引き受けて、自動フェールオーバーが発生します。図 12 は、これらのイベントを示したものです。

図 12   高可用性モードで、プリンシパル サーバーとミラー サーバー間の回線が切断してから、プリンシパル サーバーとミラーリング監視サーバー間の回線が切断した場合、フェールオーバーは発生しない

拡大表示する

プリンシパル サーバーとミラー サーバー間の回線が切断してから、プリンシパル サーバーとミラーリング監視サーバー間の回線が切断した場合は、サーバー A が孤立して、データベースの提供を中止します。サーバー B とサーバー W は、サーバー A がサーバー B では行われない作業を完了している可能性があるため、クォーラムを形成しません。

最初にプリンシパル サーバーとミラーリング監視サーバー間 (A/W) の回線切断が復旧した場合は、サーバー A が DISCONNECTED 状態でプリンシパルを再開します。ただし、プリンシパル サーバーとミラー サーバー間の回線が復旧していないために、ミラーリングは行われていません。

最初にプリンシパル サーバーとミラー サーバー間 (A/B) の回線切断が復旧した場合は、サーバー A がミラーリング監視サーバー不在の状態でサーバー B へのミラーリングを再開します。そのため、セッションが公開されます。ただし、プリンシパル サーバーとミラーリング監視サーバー間の回線が最終的に復旧するまで、自動フェールオーバーは発生しません。

結論 : 3 サイト構成で通信回線ダウンを伴う高可用性シナリオ

次の表は、3 台の独立サーバー間の回線の 1 本または 2 本が切断した場合の動作をまとめたものです。表の初期状態では、安全性レベルは FULL で、サーバーは次の状態にあります。

A : プリンシパル、SYNCHRONIZED

B : ミラー、SYNCHRONIZED

W : ミラーリング監視、CONNECTED

フェールオーバー シナリオについては、灰色で示しています。

表 13   高可用性モードで安全性が FULL に設定された 3 台の独立サーバーに関して 1 本または 2 本の回線が切断された結果

拡大表示する

シナリオ HACL4 : ミラー サイトにミラーリング監視サーバーが設置された 2 つのサイト

サーバー セット間に通信回線が 1 本しかない場合は、ミラーリング監視サーバーの設置場所を決定する必要があります。手始めに、ミラーリング監視サーバーをミラー データベース サーバーと同じサイトに設置すると仮定します。図 13 に示すように、2 セットのサーバー間には通信回線が 1 本しかなく、その回線が切断されます。

図 13   プリンシパル サイトとミラー/ミラーリング監視サイト間の通信回線が切断している

サーバー A は、ミラーリング監視サーバー W とミラー データベースのサーバー B を確認できないため、クォーラムを形成できません。サーバー B とサーバー W はクォーラムを形成できますが、どちらのサーバーもサーバー A 上のプリンシパルを確認できません。回線が切断した結果を図 14 に示します。

図 14   ミラーリング監視サーバーがミラー サイトに設置された環境で通信回線が切断した場合、フェールオーバーが発生する

サーバー A は、ミラーリング監視サーバー W と元のミラー パートナー サーバー B を確認できないため、切断状態に入ってデータベースを使用不能にする必要があります。

サーバー B とサーバー W はクォーラムを形成することができます。サーバー B は、サーバー A を確認できないため、プリンシパルになって、データベースを公開しようとします。サーバー W は、サーバー A を確認できないため、サーバー B に従います。これで、サーバー B は、クォーラムを手に入れ、このセッションのプリンシパルを引き受け、データベースを復旧します。

通信回線が復旧された場合、サーバー A は、サーバー B がプリンシパルになっており、ミラーリング監視サーバー W がサーバー B をプリンシパルと見なしていることを認識します。サーバー A は自身の役割をミラーに変更し、新しいプリンシパルと同期しようとします。同期がとれた場合の最終的な構成を図 15 に示します。

図 15   ミラーリングの方向が逆になったこのシナリオの復元バージョン

まとめ : ミラーリング監視サーバーがミラー サーバーとともにリモート サイトに設置されている場合は、サイト間の通信回線が切断すると、自動フェールオーバーが発生します。

シナリオ HACL5 : プリンシパル サイトにミラーリング監視サーバーが設置された 2 つのサイト

この高可用性シナリオでは、図 16 に示すように、ミラーリング監視サーバーをプリンシパル データベースのサーバーと同じサイトに設置し、この 2 サイト間の通信回線が切断すると仮定します。

図 16   プリンシパル/ミラーリング監視サイトとミラー サイト間の通信回線が切断している

この場合は、ミラー データベースを収容しているサーバー B がプリンシパル サーバーとミラーリング監視サーバーから孤立します。サーバー A とサーバー W はクォーラムの形成を継続するため、サーバー A はプリンシパルとしてデータベースを維持します。ただし、サーバー A は、サーバー B を確認できず、データを転送できないため、データベースを切断状態にします。サーバー B もサーバー A を確認できないため、同様に切断状態になります。最終的な構成を図 17 に示します。

図 17   このシナリオにおける通信回線ダウンによって、両パートナーが切断状態に入る

サーバー A は、トランザクションの受け入れを継続しますが、トランザクション ログは削除できません。回線が迅速に復旧されれば、ミラーリング セッションが再び同期して、元の動作状態に戻ることができます。

まとめ : ミラーリング監視サーバーがプリンシパル サーバーと同じサイトに設置され、ミラー サーバーがリモート サイトに設置されている場合は、サイト間の通信回線切断によって自動フェールオーバーは発生しません。

結論 : 通信回線ダウンを伴う高可用性シナリオ

3 台の独立サーバーによる高可用性構成では、3 本の独立した通信回線が必要です。

• プリンシパル サーバーとミラー サーバー間の通信回線ダウンが発生した場合は、自動フェールオーバーが発生しません。

• 最初にプリンシパル サーバーとミラーリング監視サーバー間の通信回線ダウンが発生してから、プリンシパル サーバーとミラー サーバー間の通信回線ダウンが発生した場合は、自動フェールオーバーが発生します。回線が復旧されれば、ミラーリング方向の逆転が回避されます。

• ミラー サーバーとミラーリング監視サーバー間の通信回線ダウンが発生した場合は、自動フェールオーバーが発生しません。

通信回線が 1 本しかない高可用性構成では、ミラーリング監視サーバーがプリンシパル サイトとミラー サイトのどちらかに設置されます。

• ミラーリング監視サーバーがミラー サーバーとともにリモート サイトに設置されている場合は、サイト間の通信回線が切断すると、自動フェールオーバーが発生します。

• ミラーリング監視サーバーがプリンシパル サーバーと同じサイトに設置され、ミラー サーバーがリモート サイトに設置されている場合は、サイト間の通信回線切断によって自動フェールオーバーが発生しません。

高度な保護シナリオ

高度な保護動作モードは、安全性 FULL で動作しますが、ミラーリング監視サーバーがありません。プリンシパル データベースを搭載した 1 台のサーバーとミラー データベースを搭載した 1 台のサーバーだけが関与するため、サーバー間の通信回線は 1 本だけです。このため、シナリオの数は大幅に削減されます。

ケース 1 : 高度な保護動作モードでは、プリンシパルとミラーの 2 つの SQL Server インスタンスだけが関与します。ミラーリング監視サーバーが存在しないため、自動フェールオーバーは使用できません。サーバー間の通信回線は 1 本しかなく、これが切断すると、図 18 に示すような構成になります。

図 18   高度な保護シナリオで通信回線が切断した場合、両パートナーが切断状態になるが、プリンシパル データベースは使用不能にならない

安全性が FULL で、プリンシパル サーバーがミラー サーバーとクォーラムを形成できないため、プリンシパル サーバーはデータベースを切断して、ユーザー アクティビティから使用できないようにする必要があります。

ケース 2 : 高度な保護シナリオでミラー データベースが使用不能になった場合は、プリンシパル サーバーは図 19 に示すようなシナリオになります。

図 19   高度な保護シナリオで、ミラー サーバーが使用不能になった場合、プリンシパル データベースが影響を受ける

ケース 3 : 高度な保護シナリオでプリンシパル データベースが使用不能になった場合は、図 20 に示すように、ミラー データベースがミラーを継続する必要がありますが、切断状態になります。

図 20   高度な保護モードでプリンシパル サーバーが使用不能になった場合、ミラー データベースが切断状態に入る

高度な保護動作モードでは安全性が FULL に設定されているため、何らかの不具合によってプリンシパル データベースは使用不能になり、ミラー データベースは復旧途中の状態、つまり、データベースがオフライン状態のままになります。結果的に、高可用性の要件を満たすことができません。ミラーリング監視サーバーを一時的に短期間取り外さなければならない場合には適しています。

高パフォーマンス シナリオ

高パフォーマンス動作モードは、安全性 OFF で動作します。ミラーリング監視サーバーが担当する役割はありません。プリンシパル データベースを搭載した 1 台のサーバーとミラー データベースを搭載した 1 台のサーバーだけが関与し、サーバー間の通信回線は 1 本だけです。高パフォーマンス モードは高度な保護モードと似ていますが、安全性が OFF のため、動作が異なります。

ケース 1 : 高パフォーマンス動作モードでは、2 つの SQL Server インスタンスが関与します。一方がプリンシパル データベースを収容し、もう一方がミラー データベースを収容します。そのため、サーバー間の通信回線は 1 本しかなく、これが切断すると、図 21 に示すような構成になります。

図 21   高パフォーマンス シナリオで通信回線が切断した場合、両パートナーが切断状態になるが、プリンシパル データベースは使用可能状態のままになる

トランザクションの安全性が OFF のため、サーバー A はデータベースを使用可能に維持するためのクォーラムを必要としません。そのため、プリンシパル サーバーは、切断状態であっても、ユーザー アクティビティの受け付けを継続します。通信回線が復旧されると、ミラー データベースは、遅れを取り戻そうとしますが、取り戻すことができないか、損失したトランザクションのすべてを読み取ることができない場合は、再実行エラーが発生する可能性があります。

ケース 2 : 高パフォーマンス シナリオでミラー データベースが使用不能になった場合は、プリンシパル サーバーは図 22 に示すような状態になります。

図 22   高パフォーマンス シナリオでミラー サーバーが使用不能になった場合、プリンシパル データベースは影響を受けない

プリンシパル データベースは、安全性が OFF のため、使用可能状態のままです。

ケース 3 : 高パフォーマンス シナリオでプリンシパル データベースが使用不能になった場合は、図 23 に示すように、ミラー データベースはミラーのままですが、切断状態になります。

図 23   プリンシパル サーバーが使用不能になった場合、サーバー B は影響を受けないが、切断状態に入る

高パフォーマンス動作モードでは、高度な保護動作モードと同様、自動フェールオーバーは使用できません。安全性が OFF のため、プリンシパル サーバーは、ミラー サーバーが使用不能になっても、データベースを使用可能に維持します。また、安全性が OFF のため、トランザクションがミラー サーバーに届いているかどうか保証されません。ミラー サーバーにフェールオーバーを強制すると、トランザクションの一部が失われる可能性があります。

データベース ミラーリングの実装

データベース ミラーリングの実装に関する基礎的な情報については、SQL Server 2005 Books Online のデータベース ミラーリングについての説明にある「How To」(英語情報) を参照してください。ここでは、データベース ミラーリングの実装例とベスト プラクティスを説明します。

データベース ミラーリングの監視

SQL Server 2005 Management Studio のオブジェクト エクスプローラでプリンシパル データベースまたはミラー データベースを調査すると、各データベース ミラーリングのパートナーの状態を検出できます。プリンシパルとミラーが同期済みの場合は、オブジェクト エクスプローラのプリンシパル データベース名の横に (プリンシパル、同期完了) のメッセージが追加表示され、ミラー サーバー名の横に (ミラー、同期完了) のメッセージが追加表示されます。また、プリンシパル サーバーで [データベースのプロパティ] ダイアログ ボックスを開き、[ミラーリング] ページの [状態] ボックスを参照して、データベース ミラーリング セッションの状態を調べることもできます (ミラー データベースで [データベースのプロパティ] ダイアログ ボックスを開くことはできません)。

また、sys.database_mirroring および sys.database_mirroring_witnesses というデータベース ミラーリングのカタログ ビューに対してクエリを実行することもできます (ミラーリング セッションのデータベースの状態の調査にカタログ ビューを使用する方法の詳細については、前述の「データベース ミラーリングのダイナミクス」の「データベース ミラーリングのカタログ ビュー」を参照してください。カタログ ビューについては、SQL Server Books Online でも詳しく説明されています)。

データベース ミラーリングの Perfmon カウンタ

Perfmon カウンタを使用すると、データベース ミラーリング セッションのパートナー間のトラフィックを監視できます。SQL Server の Database Mirroring オブジェクトには、プリンシパル サーバーとミラーリング監視サーバーに使用できる、便利な Perfmon カウンタが数多く実装されています (SQL Server Books Online の「Monitoring Database Mirroring」(英語情報) を参照してください)。

Database Mirroring オブジェクトの各カウンタは、データベースごとに設定できます。1 台のサーバー上で複数のデータベースをミラー化している場合は、すべてのデータベースのミラー化の動作を全体として測定できるだけでなく、各データベースの動作を個別に測定することも可能です。

プリンシパル サーバーの場合、プリンシパル サーバーからミラー サーバーへのトランザクション ログの送信速度が Log Bytes Sent/sec カウンタに示され、特定の時点で、トランザクション ログ バッファからミラー サーバーにまだ送信されていないデータのバイト数が Log Send Queue に表示されます。 トランザクション ログ データがプリンシパルからミラーに送信されると、プリンシパルの Send キュー (送信キュー) は空になりますが、新しいログ レコードがログ バッファに入力されると送信キューは増加します。プリンシパルの Transaction Delay カウンタには、ミラー データベースからのログ レコード受信確認応答待ちが原因でプリンシパルに発生している遅延が表示されます。Pages Sent/sec には、同期化を進めるためにプリンシパルからミラーに送信されるデータ ページに関連した情報が表示されます。

ミラー サーバーの Log Bytes Received/sec には、ミラーがプリンシパルにどの程度遅れずに対応できているかが表示されます (前述の Log Bytes Sent/sec カウンタについての説明を参照してください)。Redo Queue カウンタには、再実行キューのサイズが表示されます。この Redo Queue (再実行操作用キュー) は、ミラーで実行中の再実行フェーズで、プリンシパルのトランザクションを再生するために使用されます。Redo Bytes/sec には、ミラーが再実行操作用キューのトランザクションを再生できる速度が表示されます。

パートナーごとの情報としては、Sends/sec カウンタと Receives/sec カウンタに、個別の送信動作と受信動作の数が表示されます。これらの情報から、サーバーのおおよその通信速度がわかります。Bytes Sent/sec カウンタと Bytes Received/sec カウンタには、これらの送受信動作のために各パートナー サーバーで送受信された合計バイト数が表示されます。

再実行時間と遅れを取り戻すための時間の推定

フェールオーバーが発生した場合に、ミラーが再実行処理を完了し、使用可能になるまでの時間は、Redo Queue および Redo Bytes/sec の値から予測できます。次のような簡単な式を使用します。

再実行に必要な推定時間 (秒) =
        (Redo Queue)/(Redo Bytes/sec)

同様に、プリンシパルの動作が先行している場合に、動作が休止したとき、ミラーがプリンシパルからの遅れを取り戻すために必要な時間も、Log Send Queue カウンタと Log Bytes Received/sec カウンタを使用して予測できます。次のような式を使用します。

遅れを取り戻すために必要な推定時間 (秒) =
        (Log Send Queue)/( Log Bytes Received /sec)

プロファイラ イベント

SQL Server 2005 プロファイラには、データベース ミラーリング用のイベント クラスが 1 つあります。Database:Database Mirroring State Change イベントで、監視対象のサーバーで状態変更が発生したかどうかが記録されます (SQL Server Books Online の「Database Mirroring State Change Event Class」(英語情報) を参照してください)。このイベント クラスを使用するときには、[データベース名] 列と [状態] 列を含めておくと便利です。このイベントを使用すると、データベース ミラーリング セッションで状態変更が発生したときに警告を受信できます。

データベース ミラーリングのトラブルシューティング

ほとんどのエラーは、セットアップ中とランタイムの 2 つの段階で発生します。

セットアップのトラブルシューティング

データベース ミラーリングのインストールが完了しても起動しない場合は、セットアップ中に実行した手順を追跡します。

1. 必要な時間内に、ミラー サーバーがプリンシパルからの遅延を取り戻していることを確認します。ミラーリングを起動しようとしたときに、次のメッセージが表示される場合があります。

   データベースのリモート コピー "AdventureWorks" は、時間内にデータベース ログのローカル コピーを含むポイントに到達できませんでした。 (Microsoft SQL Server, エラー: 1412)

   メッセージが表示されたときは、ミラーが遅延を取り戻していないことがわかります。このような場合は、ミラーがプリンシパルからログ レコードの受信を開始できる時点まで遅延を取り戻せるように、プリンシパルのログのバックアップを (NORECOVERY 指定で) ミラーに適用することが必要です。

2. 各サーバー上の SQL Server Windows サービス アカウントの信頼関係が、相互のサーバー上で確立されていることを確認します。信頼関係にないドメイン上にサーバーがある場合は、証明書が正しいことを確認します。

3. 次のように sys.database_mirroring_endpoints カタログ ビューに対するクエリを実行し、エンドポイントが定義されているだけでなく、起動されていることを確認します。

   
   SELECT * FROM sys.database_mirroring_endpoints;
   

   また、完全修飾コンピュータ名およびポート番号が正しいことも確認します。1 台の物理サーバー上の複数のインスタンス間でミラーリングを行っている場合は、それぞれ一意のポート番号を使用します。各 SQL Server のサービス ログインには、エンドポイントに対する接続 (CONNECT) 権限が必要です。

   最後に、サーバーに対する各エンドポイントの役割が、意図したとおりに正しく定義されていることを確認します。

4. 正しいパートナー名を ALTER DATABASE コマンドに指定したことを確認します。プリンシパルとミラーの sys.database_mirroring カタログ ビューで (高可用性モードの場合は、sys.database_mirroring_witnesses のミラーリング監視サーバーで) パートナー名を調べることができます。

ランタイム エラーのトラブルシューティング

データベース ミラーリングのセットアップが正しく完了した後、実行中にエラーが発生した場合は、セッションの現在の状態を調べます。SUSPENDED 状態になっている場合は、ミラーで再実行エラーが発生している可能性があります。再実行用 (データ ドライブの空き領域) とログ強化用 (ログ ドライブの空き領域) の両方に十分なディスク領域が、ミラー上にあることを確認します。セッションを再起動する準備ができたら、ALTER DATABASE を使用して、セッションを再開します。

プリンシパル データベースに接続できないのは、ほとんどの場合、Safety = FULL に設定されているために、プリンシパル サーバーがクォーラムを形成できないためです。たとえば、システムが高度な保護モード (Safety = FULL に設定されているけれどもミラーリング監視サーバーがない状態) で動作している場合に、この現象が発生して、古いプリンシパルからミラーが切断される場合があります。その場合は、ミラー サーバー上で次のコマンドを使用して、ミラー サーバーを強制的に復旧させます。

ALTER DATABASE [AdventureWorks] SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS

この場合の問題点として、ミラー データベースを復旧するとプリンシパル サーバーになりますが、クォーラムを形成できないことに起因してデータベース サービスを提供できないことが挙げられます。その場合は、Safety = OFF に設定し、データベース サービスを提供できるようにしてください。

安全性とパフォーマンス

データベース ミラーリングのパフォーマンスは、動作のタイプとトランザクションの安全性 (Safety) の設定によって異なります。

プリンシパル サーバーのパフォーマンスは、ミラーに対するログ レコード転送の影響を受けます。データベース ミラーリングの負荷は、動作のタイプによって異なります。データベース ミラーリングのパフォーマンスが最高になるのは、ユーザー数が多く、長いトランザクションが多い場合です。これは、データベース サーバーの通常のトランザクションの動作が、ミラーに対するログ レコードの転送の負荷を表面上は隠すことになるためです。単一のユーザーが多数の小さなトランザクションを順次発行する場合は、各トランザクションのデータベース ミラーリングの負荷がより顕著になります。

プリンシパル サーバーのパフォーマンスは、Safety 設定値の影響も受けます。Safety = FULL の場合、プリンシパルは、トランザクションのコミット メッセージをクライアントに返信する前に、ミラーからのログ レコード受信確認応答を待つことが必要です。ユーザーが多くてトランザクションが長い場合は、この負荷が影響を及ぼすことはありません。スレッドが 1 つで小さなトランザクションが多いシステムでは、Safety = OFF の設定の方が運用に有利な場合があります。

ミラー サーバーでは、プリンシパルから受信されたデータ変更トランザクションが継続的に再生されているので、ミラー サーバー上のデータ キャッシュは "ホット" な状態になります。つまり、プリンシパル上の同じような変更に基づいたデータ ページやインデックス ページが、データ キャッシュに読み込まれます。ミラーのキャッシュをプリンシパルのキャッシュの状態により近づけるために、データベース ミラーリングでは、SELECT コマンド情報についてもヒントとしてミラーに渡し、データのクエリに使用するキャッシュもミラー サーバーで複製できるようにしています。この処置によって、ミラーをプリンシパルの状態に一層近づけることができるので、フェールオーバーが発生した場合の再実行時間を短縮できます。当然のことながら、データベースのスナップショットに対するクエリなど、ミラー サーバー上でさらに他の動作を行うと、キャッシュの状態に影響を与えるため、フェールオーバー時の再実行を完了するための時間が長くなることがあります。

データベース ミラーリングのテスト

データベース ミラーリングをテストするためにシステムをセットアップする場合は、多くの選択肢があります。ミラーリングを利用する場合は、データベース ミラーリング セッションに参加する各サーバーが、別個の SQL Server インスタンスであることが必要です。そのため、SQL Server 2005 のリレーショナル エンジンのインスタンスを複数インストールすると、1 台の物理サーバー上でデータベース ミラーリングについて理解を深めながらテストを実行できます。また、1 台の仮想サーバー上でも複数のインスタンスをテストできますが、物理サーバー上でテストする方がテストの信頼性が高まります。

データベース ミラーリングの負荷テストまたはストレス テストを行う場合は、別個の物理サーバーが必要です。1 台のサーバーに 2 つか 3 つのインスタンスがあると、物理サーバーのリソースの消費割合が現実的でなくなる場合があります。サーバー間が良好に接続されていることも、同様に重要です。プリンシパルとミラーの間のネットワーク接続が良好であればあるほど、ログ レコードとメッセージの転送も速くなります。

実際のターゲット サーバー上または最終システムと同じ物理特性のテスト環境でテストするのが最も理想的です。1 台のサーバー上の複数のインスタンスを使用してテストする場合にシミュレートできるのは、データベース ミラーリングでサーバーが失われた場合の影響に限定されます。この場合は、インスタンスの 1 つを停止するか、コンピュータをシャット ダウンしてテストします。複数の物理サーバーを使用できる場合は、ネットワーク ケーブルを外すと、接続が失われた場合のテストも実行できます。

テスト条件を満たす環境を整えるためのガイドラインを以下に示します。

• サーバーの障害をテストするには、SQL Configuration Manager と SHUTDOWN WITH NOWAIT コマンドのいずれかを使用して、SQL Server のインスタンスをシャット ダウンします。

• 通信障害をテストするには、サーバーからネットワーク ケーブルを外します。

• データベース障害をテストするには、SQL Server サービスを停止し、基盤となる .mdf ファイルの名前を変更して、SQL Server を再起動します。

• ミラー サーバーで再実行操作エラーを発生させるには、ミラー サーバーには存在しないドライバ ボリューム上のプリンシパル データベースにファイルを追加します。

• また、ミラー サーバーのデータ ファイルを強制的にディスク容量不足にしても、ミラー サーバーで再実行操作エラーを発生させることができます。

• プリンシパル サーバーのデータベースを強制的にシャット ダウンするには、プリンシパルのデータ ファイルを強制的にディスク容量不足にします。

• プリンシパルまたはミラーのログ バッファへの固定機能に障害を発生させるには、ログ ファイルを強制的にディスク容量不足にします。

ミラー サーバーにおけるフェールオーバーへの準備

データベース ミラーリングは、厳密なデータベース間の関係性で成り立っています。プリンシパルからミラーへは、ログ レコードを使用して、データベースのデータのみが送られます。ログ配布やレプリケーションの場合と同様に、フェールオーバーの発生時に完全にサービスを引き継げるようにするには、ミラー データベースを備えたスタンバイ サーバーを用意する必要があります。ミラー サーバーを用意する際には、いくつかのレベルについて考慮します。

物理サーバーのレベルでは、スタンバイ サーバーが、物理 CPU とメモリについて同じ構成またはできるだけ近い構成になっていることを確認します。そうしなければ、フェールオーバー後にスタンバイ サーバーで十分なパフォーマンスを得られません。また、サポート アプリケーション、モニタ、またはデータベース アプリケーションをサポートするその他の実行可能ファイルをミラー サーバーにインストールして設定しておくことが必要になる場合もあります。

SQL Server のレベルでは、スタンバイ サーバーの SQL Server の構成 (AWE、並列処理の最大限度など) が同じになっていることも確認します。ただし、最も基本的な項目は、ログインと権限の設定です。プリンシパル サーバー上の SQL Server のアクティブなすべてのログインを、ミラー サーバーにも設定します。そうしないと、フェールオーバー発生時に、アプリケーションがミラー サーバーを新しいプリンシパル サーバーとして使用できません。SQL Server Integration Services には、あるサーバーから別のサーバーにログインとパスワードをコピーできるログイン転送タスクがありますが、これらのログインに対しても別途データベース権限の設定が必要になることもあります。異なるドメイン内のサーバーにログインを転送する場合で、SID が一致しないときは、一致させることが必要です。

プリンシパル SQL Server には、スタンバイ サーバーに移行することが必要な多数のサポート オブジェクトが含まれていることが考えられます。たとえば、SQL エージェントのジョブと警告、SQL Server Integration Services のパッケージ、サポート データベース、リンク サーバーの定義、バックアップ デバイス、保守計画、SQL Mail または Database Mail の設定などが挙げられます。分散トランザクション コーディネータ (DTC) の設定が含まれていることもあります。

スタンバイ サーバーに転送される SQL エージェントのジョブについては、ほとんどの場合、ジョブを無効のままにします。これらのジョブは、フェールオーバー発生時に有効にすることが必要になります。

アプリケーションが SQL Server 認証を使用している場合に、フェールオーバーが発生したら、新しいプリンシパル データベースのユーザーを使用して、新しいプリンシパル SQL Server のログインを解決します。この作業用のツールとしては、sp_change_users_login ストアド プロシージャが最適です。

複数データベース使用時の問題点

1 台のサーバー上で複数のデータベースを使用するアプリケーションは多数あります。1 つのアプリケーションが複数のデータベースを参照している場合もあれば、多数のアプリケーションすべてが、数個のデータベースを使用している場合もあります。ただし、データベース ミラーリングは、一度に 1 つのデータベースで動作します。このことを考慮に入れて、データベース アーキテクチャ設計にミラーリングを組み込みます。

高可用性モードを使用する場合は、1 つのアプリケーションが 1 つのデータベースに対応するようにするのが最善です。そのようにすると、自動フェールオーバーが発生しても、アプリケーションがプリンシパル サーバー上のデータベースを必要とすることはありません。1 つのサーバー上で複数のデータベースを高可用性モードで運用しているとどうなるかを考えてみましょう。物理サーバーの機能停止、SQL Server インスタンスの障害、または通信障害が発生すると、すべてのデータベースは、自動的にスタンバイ サーバーにフェールオーバーし、それぞれのミラー データベースが新しいプリンシパル データベースになります。ミラーリング監視サーバーを認識できる場合、アプリケーションは新しいプリンシパル データベースに接続できます。しかし、いずれかのデータベースがディスク障害によってページに損傷を受け、そのデータベースのみがフェールオーバーしたらどうなるでしょうか。その場合は、正常に動作しているすべてのデータベースに、アプリケーションが接続できなくなるおそれがあります。

そのため、複数のデータベースに依存するアプリケーションは、データベース ミラーリングによる高可用性モードを使用する運用には向いていません。このような場合、自動フェールオーバーは使用せず、Safety = OFF を指定して、別のデータベース サーバーを常に同期させておく高パフォーマンス方式を採用します。

データベースのミラーリングと高可用性テクノロジ

SQL Server 2005 には、現在少なくとも 4 つの高可用性テクノロジが採用されています。重複している部分もありますが、それぞれのテクノロジには独自の利点と欠点があります。採用されているテクノロジは次のとおりです。

• データベース ミラーリング   Safety = FULL を指定した高可用性動作モードと、ミラーリング監視サーバーの配置について検討します。

• フェールオーバー クラスタリング   2 ノードの Windows フェールオーバー クラスタで、1 つの SQL Server インスタンスを使用する構成が最も一般的です。

• ログ配布   SQL Server には、独立した監視機能を備えたログ配布機能が組み込まれています。

• トランザクションのレプリケーション   ディストリビューション サーバー 1 台とサブスクライバ 1 台が設定された構成を考えます。サブスクライバは、パブリッシャ サーバーの障害時にスタンバイ サーバーとして機能します。

この節では、これらの 4 つのテクノロジについて基本機能を比較し、データベース ミラーリングで機能を補完したり、さらに優れたソリューションを提供したりできる可能性のある領域について説明します。

次の表は、ここに挙げた 4 つのテクノロジで利用できる多くの機能を示したものです。

表 14   SQL Server 2005 に実装されている高可用性テクノロジ (比較表)

上の表では、4 つの高可用性テクノロジの特徴について、概要を示しました。次の節では、より詳しく比較内容を検討します。

データベース ミラーリングとクラスタリング

データベース ミラーリングとフェールオーバー クラスタリングの相違点で最も重要なのは、冗長性を実現するレベルの違いです。データベース ミラーリングは、データベース レベルの保護を実現するのに対し、クラスタリングは、サーバー インスタンス レベルの保護を実現します。もう 1 つの重要な違いは、データベース ミラーリングの場合、プリンシパル サーバーとミラー サーバーは別々の SQL Server インスタンスになっており、それぞれに別の名前が付いているのに対し、クラスタ上の SQL Server インスタンスの場合、仮想サーバー名が 1 つで、設定されている IP アドレスはクラスタ内のどのノードがインスタンスをホストする場合でも変更されないことです。

サーバー レベルでデータベースを保護する必要がある場合 (たとえば、同じデータベース サーバー上の多数のデータベースに対し、アプリケーションが同時にアクセスする必要がある場合) は、フェールオーバー クラスタリングを選択する方が適切なときがあります。ただし、一度に 1 つのデータベースの可用性を実現することが重要な場合は、データベース ミラーリングに多くの利点があります。

クラスタリングとは異なり、ミラーリングには独自開発のハードウェアは不要で、共有記憶域で問題が発生するおそれもありません。データベース ミラーリングを使用すると、他の高可用性テクノロジを使用した場合よりもずっと速くスタンバイ データベースを稼動状態にできます。また、ADO.NET の新機能およびクライアント側のフェールオーバーに対応する SQL Native Client とも良好に動作します。

データベース ミラーリングをクラスタ内で使用することはできませんが、クラスタ インスタンス用のホット スタンバイの作成にはデータベース ミラーリングの使用を検討できます。その場合は、クラスタのフェールオーバーにかかる時間が、データベース ミラーリングのタイムアウト値より長いので、高可用性モードのミラーリング セッションでは、クラスタのフェールオーバーがプリンシパル サーバーの障害として処理されることに注意してください。その後、クラスタ ノードがミラーリング状態になります。

データベース ミラーリングとトランザクションのレプリケーション

データベース ミラーリングとトランザクションのレプリケーションでは、両方ともまず元のサーバーのトランザクション ログが読み込まれますが、その後に使用されるテクノロジが大きく異なります (トランザクションのレプリケーションの詳細については、SQL Server Books Online 内の関連するトピックを参照してください)。トランザクションのレプリケーションを使用すると、パブリッシャ データベースからサブスクライバにユーザーのトランザクションをわずか数秒で配信できるため、高可用性を実現する場合は、トランザクションのレプリケーションがよく使用されます。データベース ミラーリングは、レプリケーションと同等またはそれ以上に高速ですが、ユーザー テーブルに関連したトランザクションだけでなく、データベースのすべてのトランザクションを配信できるという利点があります。

トランザクションのレプリケーションは、複数のサブスクライバにレポート用のデータをスケール アウトする場合に適したテクノロジです。トランザクションのレプリケーションのサブスクライバ データベースは、通常、読み取り専用です。そのため、リアルタイムに近いデータへのアクセスが必要な場合には、これらのデータベースにトランザクションのレプリケーションを使用することが理想的です。

データベース ミラーリングは、トランザクションのレプリケーションと互換性があり、パブリッシャ データベースのホット スタンバイ状態を維持する場合に最も便利な方法です。ログ配布機能など、レプリケーションのパブリッシャを保護する他の方法を使用すると、パブリッシャのスタンバイ サーバーよりもパブリッシャ自身のサブスクライバの方が新しい状態になってしまいます。つまり、トランザクションのレプリケーションは、トランザクション ログのバックアップを使用する方式よりもずっと速くトランザクションをサブスクライバに配信できます。パブリッシャ データベースのホット スタンバイ状態を維持するためには、データベース ミラーリングが非常に高速なので、はるかに適切な方法といえます。

ただし、パブリッシャに障害が発生した場合は、復元したスタンバイ データベースをパブリッシャとして手動で再設定し、ディストリビューション サーバーに再接続する必要があります。これは、ログ配布機能を使用してパブリッシャ サーバーのスタンバイ状態を維持している場合でも、実行が必要になる操作です。

データベース ミラーリングとログ配布

データベース ミラーリングとログ配布はいずれも、SQL Server データベースの復元機能と回復機能に依存しています。データベース ミラーリングのミラー データベースは、常に回復中の状態にあり、多かれ少なかれ継続的にプリンシパルのトランザクションが再生されています。ログ配布のセカンダリ サーバーの場合は、サーバーに適用されるトランザクションが、トランザクション ログのバックアップから定期的に再生されています。一括ログ記録形式のデータが、トランザクション ログのバックアップの最後に付加されるので、一括ログ記録を使用した復旧モデルでログ配布機能を使用できます。一方、データベース ミラーリングの場合は、プリンシパルからミラーへ、ログ レコードが直接転送されるため、一括ログ記録形式のデータは配信できません。

多くの場合、データベース ミラーリングを使用すると、ログ配布と同様のデータの冗長性が実現できるだけでなく、高可用性と自動フェールオーバーも実現できます。ただし、1 台のサーバー上の複数のデータベースをアプリケーションで使用する必要がある場合は、ログ配布機能でも同等の有効性を実現できる場合があります (前節の「複数データベース使用時の問題点」を参照してください)。

さらに、データベース ミラーリングのシナリオの中には、ログ配布によって可用性を補完できるものもあります。たとえば、データベース ミラーリングを使用した高可用性構成のシステムを自社で運用している場合は、障害時の回復のために、プリンシパル サーバーからリモート サイトにログを配布することができます。図 24 は、そのような構成の例を示したものです。

図 24   プリンシパル データベースからリモート サイトにログを配布する

この構成の利点は、サイト全体が失われた場合でも、セカンダリ サイトでデータを利用できることです。ただし、データベース ミラーリングでフェールオーバーが発生した場合は、通常、サーバー B からリモートのスタンバイ サーバーへのログの配布を再初期化する必要があります。

データベース ミラーリングを補完するためにログ配布機能を使用する別のシナリオは、障害回復にデータベース ミラーリング セッションを使用しているプリンシパル サーバーのローカル スタンバイ用にログ配布機能を使用する方法です。この場合のミラーリング セッションは、リモート スタンバイ用のリモート サイトにミラーリングを設定した高パフォーマンス モードで動作します。

図 25   すべてのトランザクションを保存する方法として、プリンシパル データベースのログの配布を行う

高パフォーマンス モードの場合は、プリンシパルに障害が発生したときに、強制サービス復旧を使用してミラーを回復すると、データを損失するおそれがあります。古いプリンシパルのログを配布している場合で、古いプリンシパルのトランザクション ログ ファイルに損傷がないときは、プリンシパルの "ログの最終部分" のバックアップを作成すると、トランザクション ログの最後の一連のログ レコードを取得できます。他のトランザクション ログのすべてのバックアップがスタンバイ側のログ配布データベースに既に適用されている場合は、ログの最終部分のバックアップをスタンバイ サーバーに適用すると、古いプリンシパルのデータは失われません。次に、ログ配布用のスタンバイ サーバーとリモート データベースのデータを比較して、失われたデータがあればリモート サーバーにコピーできます。

いずれの場合でも、ログ配布とデータベース ミラーリングを比較すると、"プリンシパル データベースについてバックアップおよびトランザクション ログ バックアップを保存しておくことが重要である" ことがわかります。これらのログのバックアップをログ配布サーバーに適用すると、データベース ミラーリング構成の弱点を補完できます。

まとめ

データベース ミラーリングは、データベースの冗長性に対して高可用性および高パフォーマンスを提供する SQL Server 2005 の新しいテクノロジです。データベース ミラーリングでは、プリンシパル データベースのトランザクション ログ バッファがディスクに書き込まれる (固定される) たびに、トランザクション ログ レコードがプリンシパル データベースからミラー データベースに直接送信されます。この技法により、ミラー データベースを、コミットされたデータを失うことなく、プリンシパル データベースの最新版に近い状態に維持することができます。高可用性動作モードでは、プリンシパルに障害が発生すると、ミラー サーバーが自動的に新たなプリンシパルとなり、データベースを復旧します。アプリケーションは、ADO.NET または SQL Native Access Client の新しいドライバを使用して、クライアント サーバーからの自動フェールオーバーを実行することもできます。このように、データベース ミラーリングは、SQL Server 2005 でサポートされる数多くの高可用性テクノロジにおいて、重要な新オプションとなりました。

For More Information

SQL Server TechNet サイト (https://www.microsoft.com/japan/technet/prodtechnol/sql)

SQL Server デベロッパー センター (https://www.microsoft.com/japan/msdn/sqlserver/)

Microsoft SQL Server サイト (https://www.microsoft.com/japan/sql/)

この資料は役に立ちましたか?ご意見をお寄せください。1 (劣) ～ 5 (優) の 5 段階評価で、この資料について採点してください (英語のみ)。