高可用Windowsシステムの研究 SQL Server 2005の高可用テクノロジ編 第2回　SQL Serverの可用性向上のためのシステム構成 3．データベース・ミラーリングの構成とはたらき デジタルアドバンテージ 資料提供、技術協力：マイクロソフト 2007/03/12
Page1 Page2 Page3 Page4 Page5 Page6

　データベース・ミラーリングはソフトウェア的にデータベースを冗長化する可用性向上技術である。ソフトウェアによる冗長化技術であるため、前述したフェイルオーバー・クラスタのように、特定のハードウェア（HCL準拠のハードウェア）を準備しなくても構成できるという特長がある。

　データベース・ミラーリングでは、データベース単位でデータの冗長化（本番系と待機系）を図り、トランザクション単位でこれらのデータベースの同期を行う（同期方法には大きく2種類がある。詳細はすぐ次で述べる）。障害が発生した場合には待機系サーバが処理を引き継ぎ、クライアントに対するサービスを継続する。一般的にはフェイルオーバー・クラスタよりも高速なフェイルオーバーが可能である。なお前回も説明したとおり、SQL Server 2005のミラーリング機能は、SQL Server 2005 SP1で追加された機能であり、現時点でこの機能を使うには、SQL Server 2005のインストール後に、別途SP1を追加する必要がある。

　データベース・ミラーリングの基本的な構成は次のとおり。

データベース・ミラーリングの基本構成

本番系のプリンシパル・サーバと、待機系のミラー・サーバの双方にデータベースを置き、トランザクション単位でデータベースの同期を図る。ミラーリング監視サーバは、ミラーが正常に実行されているかを監視し、障害を検知したときにはフェイルオーバー処理の指示をサーバに送信する。

　このようにデータベース・ミラーリングでは、本番系サーバとなるプリンシパル・サーバと、待機系サーバであるミラー・サーバにそれぞれデータベースを配置して冗長化し、これらを常に同期させておく。具体的には、プリンシパルからトランザクション単位でデータをミラー側に送信し、それを受信したミラー側では、自身のデータベースにデータを書き込む（反映する）。こうしてプリンシパルとミラーのデータベースを同一の内容に保つ。

　ミラーリング監視サーバはプリンシパルとミラーの両サーバの状態を監視し、同期処理が正しく実行されているか、データベースに障害が発生していないかを常時監視する。障害を検出したときには、フェイルオーバー開始の通知を各サーバに送信する。ミラーリング監視サーバが存在する場合には、このようにフェイルオーバー処理を自動化できる。自動フェイルオーバーが不要なら監視サーバを省略した構成も可能である。

　ミラー・サーバはいつでも本番サーバとして稼働できるホットスタンバイの状態にあり、高速なフェイルオーバーが可能である。データベース・ミラーリング構成での障害発生時のシステム停止時間の中身は次のようになっている。

データベース・ミラーリングのフェイルオーバー処理の内容

データベース・ミラーリングでの復旧作業では、クラスタの再構成やDBの復旧を行う必要があるが、いずれも短時間で実行が可能であり、システム停止時間を圧縮することが可能である。

データベース・ミラーリングの動作モード別構成法

　データベース・ミラーリング構成法にはいくつかの種類がある。トランザクションの安全性とパフォーマンスに応じて、これらの中から適当な構成を選択できる。構成方法には次の種類がある。

データベース・ミラーリングの構成

まずプリンシパルとミラーの間でデータベースを同期するかどうかを選択できる。同期する場合には、監視サーバを置いて自動フェイルオーバーを可能にするか、自動フェイルオーバーをあきらめる代わりに監視サーバを省略するかを選択する。

■同期データベース・ミラーリング
　プリンシパルとミラーの間でデータベースの同期を行い、トランザクションの同期を保証するのが「同期データベース・ミラーリング」である。SQL Server 2005データベースが持つプロパティのトランザクション安全性レベルをSAFETY FULLにすることで、このミラー・モードを選択できる。

　具体的にこのモードでは、待機系のミラー・サーバでの書き込み完了を待ってトランザクション処理完了とする。このためプリンシパルとミラーのデータベースの内容は同期していることが保証される。トランザクションの損失は発生しない。ただしその代償として、トランザクション処理の応答処理に負荷がかかる。レスポンスの低下を避けるためには、高信頼性／高スループットのネットワークでプリンシパルとミラーを接続する必要がある。

同期データベース・ミラーリングのトランザクション処理

同期モードでは、ミラー側データベースへの書き込み完了を待ってから、プリンシパルのトランザクション処理を完了させる。

　最も安全性と可用性の高い構成は、この同期モードを選択したうえで、ミラーリング監視サーバを設置し、自動的なフェイルオーバーを可能にする構成である。自動フェイルオーバーができなくてもよいなら、監視サーバを省略することができる。

■非同期データベース・ミラーリング
　これに対し、トランザクションの安全性レベルをSAFETY OFFにすると、非同期データベース・ミラーリング・モードを選択できる。このモードでは、プリンシパルとミラー間でのトランザクションの同期は保証されない。具体的には、ミラー（待機系）での書き込み完了を待たずにトランザクション処理が完了する。トランザクションの安全性レベルは下がるが、代わりにパフォーマンスに対する影響は同期モードよりも低減する。

非同期データベース・ミラーリングのトランザクション処理

非同期モードでは、ミラーでの書き込みを待たずにプリンシパルでのトランザクション処理を完了する。

　非同期データベース・ミラーリングを選択した場合は、自動フェイルオーバーを構成することはできない。非同期データベース・ミラーリングでは、手動のフェイルオーバーのみが可能である。

データベース・ミラーリングにおける障害パターンと復旧手順

　データベース・ミラーリング構成における障害発生時の影響や復旧方法は、前述したミラーリングの構成と、障害発生パターン（プリンシパル、ミラーリング監視サーバのどれが障害を起こすか）によって異なる。以下は、これらの障害パターンと障害発生時のデータベースの利用可否、復旧手順についてまとめたものだ。

		障害パターン			データベース利用状況	復旧手順	データベース・ミラーリング構成復旧手順
		プリンシパル・サーバ	ミラー・サーバ	ミラーリング監視サーバ
非同期モード		×	○	なし	DBは利用不可	手順1	手順1
		○	×	なし	DBは利用可	なし	ミラー・サーバの起動のみ
同期モード	自動フェイルオーバーを伴うモード	×	○	○	自動フェイルオーバー発生。DBは利用可	手順1	手順1
	自動フェイルオーバーを伴わないモード	×	○	なし	DBは利用不可	手順1	手順1
		○	×	○	DBは利用可	なし	ミラー・サーバの起動のみ
		○	○	×	DBは利用可	なし	ミラーリング監視サーバの起動のみ
		×	×	○	DBは利用不可	プリンシパル・サーバか、ミラー・サーバをバックアップなどから復旧する	プリンシパル・サーバとミラー・サーバの起動のみ。どちらからサービス起動しても、役割は停止した状態を保持している。プリンシパル・サーバから起動すること
		×	○	×	DBは利用不可	手順2	手順2
		○	×	×	DBは利用不可	手順3	手順3
データベース・ミラーリングにおける障害パターンと復旧手順
○は正常稼働、×は障害発生を意味する。

■非同期モードでの障害対応
　非同期モードでは、ミラー側の障害ならデータベースは継続利用可能だが、プリンシパル側で障害が起こると、データベースは継続利用できない。この場合には、次の手順で復旧を行う。

＜手順1＞ 　強制的にミラー・サーバ側でフェイルオーバーし、データベースを使用可能状態にする。その後、停止したプリンシパルが復旧されたら、再度データベース・ミラーリング構成に戻す。

■同期モードでの障害対応
　同期モードにおいては、プリンシパル・サーバのみに障害が発生した場合だけ、自動フェイルオーバーの有無（ミラーリング・サーバの有無）によってデータベースの利用可否や復旧手順が変わってくる。具体的には、自動フェイルオーバーが可能な場合にはプリンシパルで障害が発生してもデータベース利用は継続可能だが、自動フェイルオーバーがなければデータベースは利用不可になる。

　自動フェイルオーバーがない場合の復旧手順は、前記の手順1と同じである。プリンシパル・サーバにアクセスできない場合、手動フェイルオーバーが不可能なので、手順1でデータ損失を許容し、強制復旧を行う必要がある。ただし同期モードではプリンシパルとミラーでデータが同期されているので、強制復旧してもデータの損失は発生しない。

　これ以外の障害パターンでは、自動フェイルオーバーの有無はデータベースの利用可否や復旧手順とは無関係である。

　プリンシパルとミラーリング監視サーバが障害を起こした場合の復旧手順は次のとおり。

＜手順2＞ 　対応には大きく2つの方法がある。1つはデータベース・ミラーリングの構成を解除し、ミラー・サーバでデータベースを復旧して、データベースをすぐに利用可能にする方法である。同期モードなのでデータベース復旧時もバックアップから戻す必要はない。障害が解消され、再度データベース・ミラーリングを構成するには、明示的にミラーリングの再構成が必要である。 　もう1つの方法はデータベースのミラーリング構成は解除しないで、そのままの構成で復旧するものだ。この場合はまずプリンシパル・サーバを起動し、次にミラーリング監視サーバを起動する。停止した時点の役割が保持されているため、必ずプリンシパル・サーバから起動する必要がある。ミラーリング監視サーバだけ起動して、手動でフェイルオーバーを行っても、ミラー・サーバにフェイルオーバーすることは不可能である。プリンシパル・サーバが起動すればフェイルオーバーが可能である。

　ミラー・サーバとミラーリング監視サーバが障害を起こした場合の復旧手順は次のとおり。

＜手順3＞ 　このケースでは、プリンシパル・サーバでデータベース・ミラーリング構成を解除すればすぐにデータベースが利用可能になる。クライアント・アプリケーションの接続先はもともとプリンシパル・サーバなので、この際でも接続先を変更する必要はない。手順2と同様に、障害が解消され、再度データベース・ミラーリングを構成するには明示的にミラーリングの再構成が必要である。

サーバ入れ替え時のデータベース・ミラーリングの復旧方法

　これまで述べてきたのは、障害を起こしたサーバを回復させ、復旧させる方法だった。しかし障害の内容によってはそれまで稼働していたサーバの使用を中止し、新たなサーバに置き換えなければならない場合がある。あるいは障害でなくても、より性能の高いサーバへの交換などが必要になる場合もあるだろう。

　サーバを入れ替えたときには、データベースを復旧しなければならない。具体的には、エンドポイント（endpoint）と呼ばれるオブジェクトを復旧する。エンドポイントは、SQL Serverインスタンス間でネットワーク経由の通信を行えるようにするSQL Server オブジェクトであり、SQL Server 2005での接続管理はこのエンドポイントに基づいて行われる。ミラーリングでは認証と暗号化はエンドポイントに対して構成することになる。

　プリンシパル、ミラー、ミラーリング監視の各サーバを交換したとき、エンドポイントを復旧できるようにするには、各サーバのエンドポイントを作成したときに、Masterデータベースのバックアップを事前に作成しておく必要がある。エンドポイントとしての情報や認証情報などはMasterデータベースに保存されているためだ。各サーバを入れ替えてSQL Serverをインストールしたら、バックアップしてあったMasterデータベースを復旧する。Masterデータベースを復旧した時点で、ログイン、ユーザー、証明書、エンドポイントが回復される。

INDEX
	［高可用Windowsシステムの研究−SQL Server 2005の高可用テクノロジ編］
	第2回　SQL Serverの可用性向上のためのシステム構成
	1．フェイルオーバー・クラスタの構成と働き
	2．ログ配布の構成と働き
	3．データベース・ミラーリングの構成とはたらき
	4．可用性向上テクノロジの比較
	5．複数の可用性向上テクノロジの組み合わせ

　

［高可用Windowsシステムの研究］

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）