データベース ミラーリング セッション
データベース ミラーリングはデータベース ミラーリング セッションにより実現されます。このトピックは、データベース ミラーリングにおけるプリンシパル サーバー、ミラー サーバー、およびミラーリング監視サーバーの役割、動作モード、および役割の交代に詳しいユーザーを対象にしています。詳細については、「データベース ミラーリングの概要」を参照してください。
ミラー データベースを用意し、サーバー インスタンスを構成したら、データベース所有者はデータベース ミラーリングを開始できます。ミラーリングを開始した直後から、各パートナーは各自のデータベースの状態情報、およびもう一方のパートナーとミラーリング監視サーバー (存在する場合) の状態情報をデータベースに保存します。この状態情報を保存しておくことで、サーバー インスタンスがデータベース ミラーリング セッションという関係を維持できます。各サーバー インスタンスは、データベース ミラーリング セッション全体をとおして相互に監視します。データベース所有者がセッションを停止するまで状態情報は保持されます。詳細については、「ミラーリング状態」および「データベース ミラーリングの監視」を参照してください。
データベース ミラーリング セッションが開始されると、ミラー サーバーによりミラー データベースで適用されている最新のトランザクション ログの LSN (ログ シーケンス番号) が識別され、後続のすべてのトランザクションを記録したトランザクション ログがプリンシパル サーバーに存在する場合、それを要求します。応答で、プリンシパル サーバーにより、ミラー データベースに復元された最後のログまたはミラー サーバーに送信された最後のログ以降に蓄積されたアクティブなログ レコードがミラー サーバーに送信されます。プリンシパル データベースのログ ディスクに蓄積された未送信ログを、送信キューと呼びます。
ミラー サーバーはこのログを直ちにディスクに書き込みます。書き込まれたログは、ミラー データベースに適用されるまで保持されます。ミラー サーバーのディスクで待機しているこのログを再実行キューと呼びます。再実行キューで待機している復元されていないログの量は、ミラー データベースにフェールオーバーするために必要な時間を示します。詳細については、「役割の交代中に発生するサービスの中断時間の算出」を参照してください。
プリンシパル サーバーは、クライアントおよびクライアント接続がプリンシパル データベースを引き続き使用できる状態にします。ミラーリングが開始されると、クライアントがプリンシパル データベースを更新するたびに、プリンシパル サーバーが、プリンシパル データベースのログにトランザクションを書き込むときに、そのログ レコードをミラー サーバーにも送信します。ミラー サーバーは、このログ レコードを再実行キューの最後のレコードとして直ちにディスクに書き込みます。
バックグラウンドではミラー サーバーが、最も古いログ レコードから 1 レコードずつ、ミラー データベースでのログの再実行をできるだけ早く行います。ログの再実行では、キューに入れられているログ レコードが、最も古いレコードから順番にミラー データベースに適用されます。各ログ レコードの再実行は 1 回だけ行われます。ミラー サーバーがログを再実行することにより、ミラー データベースが継続的にロールフォワードされます。プリンシパル サーバーでプリンシパル データベースのログが切り捨てられたり圧縮されたりすると、ミラー サーバーでもログ ストリームの同時点のログが圧縮されます。
一般に、再実行によって、ミラー データベースのプリンシパル データベースに対する遅延がすばやく解消されます。ミラー データベースのプリンシパル データベースに対する遅延が完全に解消されるかどうかは、セッションの動作モードによって決まります。高い安全性の同期モードでは、プリンシパル サーバーは、新しいトランザクションがミラー サーバーのログ ディスクに書き込まれるまで、新しいトランザクションの確認を待機します。蓄積されたログ レコードがミラー サーバーに送信された後、ミラー データベースがプリンシパル データベースと同期された状態になります。
セッション中、プリンシパル サーバーがどのログ レコードもすぐに送信できない場合、未送信のログ レコードが送信キューに蓄積されます。高い安全性の同期モードでは、ミラーリングが一時停止または中断された場合にのみ、新しい未送信ログが同期後に蓄積されます。これに対し、高パフォーマンスの非同期モードでは、ミラーリングが一時停止または中断されたときだけではなく、ミラーリング中にミラー サーバーが遅延するたびに未送信ログが蓄積されます。未送信ログの量は、プリンシパル サーバーで障害が発生した場合のデータ損失の可能性を示します。
.gif "注意") 注 |
|---|
再実行が失敗した場合、ミラー サーバーのデータベースが SUSPENDED 状態になり、セッションが一時停止します。データベース所有者はセッションを再開する前に失敗の原因を解決する必要があります。 |
同時実行セッション
特定のサーバー インスタンスを、同じサーバー インスタンスまたは別のサーバー インスタンスを含む複数の同時実行データベース ミラーリング セッションに (ミラー化されたデータベースごとに 1 回) 参加させることができます。多くの場合、サーバー インスタンスは、パートナーまたはミラーリング監視サーバーとしてすべてのデータベース ミラーリング セッション内で排他的に機能します。ただし、各セッションはその他のセッションから独立しているので、サーバー インスタンスは一部のセッションではパートナーとして機能し、それ以外のセッションではミラーリング監視サーバーとして機能することができます。たとえば、3 つのサーバー インスタンス (SSInstance_1、SSInstance_2、および SSInstance_3) の間に次の 4 つのセッションがあるとします。各サーバー インスタンスは、一部のセッションではパートナーとして機能し、それ以外のセッションではミラーリング監視サーバーとして機能します。
サーバー インスタンス |
データベース A のセッション |
データベース B のセッション |
データベース C のセッション |
データベース D のセッション |
|---|---|---|---|---|
SSInstance_1 |
ミラーリング監視 |
パートナー |
パートナー |
パートナー |
SSInstance_2 |
パートナー |
ミラーリング監視 |
パートナー |
パートナー |
SSInstance_3 |
パートナー |
パートナー |
ミラーリング監視 |
ミラーリング監視 |
次の図に、2 つのミラーリング セッションに共にパートナーとして参加している 2 つのサーバー インスタンスを示します。一方のセッションは Db_1 というデータベース用で、もう一方のセッションは Db_2 というデータベース用です。
.gif "2 つの同時実行セッションにおける 2 つのサーバー インスタンス")
それぞれのデータベースは互いに独立しています。たとえば、1 つのサーバー インスタンスが最初は 2 つのデータベースのミラー サーバーである場合があります。2 つのデータベースのいずれかでフェールオーバーが発生すると、そのサーバー インスタンスはもう一方のデータベースのミラー サーバーのまま、フェールオーバーしたデータベースのプリンシパル サーバーになります。
別の例として、自動フェールオーバーを伴う高い安全性モードで実行されている複数のデータベースのプリンシパル サーバーであるサーバー インスタンスを考えてみます。このインスタンスに障害が発生した場合、すべてのデータベースが自動的にそれぞれのミラー データベースにフェールオーバーされます。
あるサーバー インスタンスをパートナーとしてもミラーリング監視サーバーとしても動作するように構成するときは、データベース ミラーリング エンドポイントで 2 つの役割がサポートされるようにしてください (詳細については、「データベース ミラーリング エンドポイント」を参照してください)。また、リソースの競合を回避するため、システムに十分なリソースを確保してください。
| 注 |
|---|
ミラー化したデータベースは互いに独立しているので、データベースをグループとしてフェールオーバーすることはできません。 |
データベース ミラーリング セッションのために作成されるスレッド
サーバー インスタンスでデータベース ミラーリング セッションのために作成されるスレッドの種類を決定する要因の一部は、そのサーバー インスタンスで実行されているミラーリング ロールです。次に示すスレッドの一部またはすべてが各セッション用に作成されます。
データベース ミラーリング通信のための 1 つのグローバル スレッド。このスレッドは Service Broker によって開始されます。
サーバー インスタンスがミラーリング パートナーとして動作している場合 (プリンシパル サーバーかミラー サーバーかは問いません):
ミラー化されたデータベースごとに 1 つのイベント処理のためのスレッド。
ミラー化されたデータベースごとに 1 つの非同期タスク (log send や log write など) のためのスレッド。このスレッドがないとイベント スレッドがブロックされます。
インスタンスがミラー サーバーとして動作している場合 :
1 つの再実行管理スレッド。再実行のためのログの送信、ページの先行読み取りの実行、ロックの再取得などを行います。
ミラー データベースごとに 1 つの再実行スレッド (SQL Server Standard の場合)、または 4 基の CPU ごとに 1 つのミラー データベースごとの再実行スレッド (SQL Server Enterprise の場合)。実際のログの再実行はこれらのスレッドによって行われます。
インスタンスがミラーリング監視サーバーとして動作している場合 :
- インスタンスがミラーリング監視サーバーとして動作しているすべてのミラーリング セッションのミラーリング監視メッセージを処理するための 1 つのグローバル スレッド。
データベース ミラーリング セッションの前提条件
ミラーリング セッションを開始するには、あらかじめデータベース所有者またはシステム管理者がミラー データベースを作成し、エンドポイントおよびログインを構成する必要があります。また、場合によっては証明書を作成および構成する必要もあります。詳細については、「データベース ミラーリングの設定」を参照してください。
ミラー データベースを作成するには、少なくとも、プリンシパル データベースの完全バックアップとそれ以降の 1 つのログ バックアップを作成し、その両方をミラー サーバーのインスタンスに (WITH NORECOVERY を使用して) 復元する必要があります。さらに、必要なログ バックアップの後に作成された追加のログ バックアップがある場合は、ミラーリングを開始する前に、それらすべてを手動で適用する必要もあります (毎回 WITH NORECOVERY を使用します)。最新のログ バックアップの適用が完了した後に、ミラーリングを開始できます。詳細については、「ミラーリングのためのミラー データベースの準備」を参照してください。
プリンシパルのトランザクション ログに対するセッションの一時停止の影響
データベース所有者はいつでもセッションを一時停止できます。一時停止では、ミラーリングは削除されますが、セッションの状態は保たれます。セッションが一時停止すると、プリンシパル サーバーからミラー サーバーに新しいログ レコードが送信されなくなります。これらのレコードはすべてアクティブなままになり、プリンシパル データベースのトランザクション ログに蓄積されていきます。データベース ミラーリング セッションが一時停止している限り、トランザクション ログを切り捨てることはできません。したがって、データベース ミラーリング セッションが長時間一時停止になっていると、ログがいっぱいになります。
詳細については、「データベース ミラーリングの一時停止と再開」を参照してください。
クライアント接続
データベース ミラーリング セッションのクライアント接続サポートは、Microsoft .NET Data Provider for SQL Server によって提供されます。詳細については、「ミラー化されたデータベースへのクライアント接続」を参照してください。