データベース ミラーリングとログ配布を組み合わせた高可用ソリューション
マイクロソフトの植田です。
今回はSQL Serverのデータベース・ミラーリングとログ配布の機能を組み合わせた運用に関するベスト・プラクティスをご紹介させて頂きます。
本内容は米国のTechNetのサイトにて公開されております。
注）本内容に関する詳細については以下のWebサイトに掲載されているホワイトペーパー（Database Mirroring and Log Shipping Working Together）をご参照ください。
本ドキュメントは以下の方を対象としております。
l 開発者、テストエンジニア、データベース・アドミニストレータ
l データベース、および、Microsoft SQL Serverについて基本的な知識をお持ちの方
l Microsoft SQL Serverのログ配布、および、データベース・ミラーリングについての知識をお持ちの方。ログ配布、および、データベース・ミラーリングの説明についてはSQL Server Books Onlineをご参照ください。
ログ配布：https://technet.microsoft.com/ja-jp/library/ms190016.aspx
データベース・ミラーリング：https://technet.microsoft.com/ja-jp/library/ms177412.aspx
ご紹介する内容は主に以下の3点です。
1. ログ配布の構成をデータベース・ミラーリングの構成に変更する方法
2. ログ配布を用いて、データベース・ミラーリングのペアに待機系を追加する方法
3. ログ配布のペアとデータベース・ミラーリングのペアを切り替える方法
ログ配布からデータベース・ミラーリングへの変更
ログ配布の機能はディザスタ・リカバリのソリューションの一つとして比較的古くから（Microsoft SQL Server 7.0 Service Pack 2以降）利用可能でした。SQL Server 2005では、 Service Pack 1からデータベース・ミラーリングの機能が追加され、SQL Serverのユーザーに高可用性を実現するための新たな選択肢を提供しています。 ログ配布とデータベース・ミラーリングを比較した際、以下の点でデータベース・ミラーリングにはアドバンテージがあります。
l 完全同期オプションが利用可能
l 自動フェイルオーバー・オプションが利用可能
高可用性の指標としては目標復旧時点、および、目標復旧時間（Recovery Point Objective (RPO), Recovery Time Objective (RTO)）があります。運用されるシステムにおいてそれらの指標がより厳しい制約を持つ場合、ログ配布からデータベース・ミラーリングへの変更を検討する価値があると言えます。ただし、データベース・ミラーリングへ変更する場合、以下の点に注意してください。
ü データベース・ミラーリングの構成では、データベースの復旧モデルが「完全」でなければなりません。変更対象のデータベースが一括ログ復旧モデルで構成されている場合は、復旧モデルを変更する必要があります。
ü ログ配布の構成では、配布元となるサーバ上で動作するアプリケーションに対してログ配布の動作の影響はあまりありませんが（ただし、アプリケーションの動作に対するログの量に依存します）、データベース・ミラーリングではアプリケーションのパフォーマンスに対してデータベース・ミラーリングの動作が影響を与える場合があります。詳細は以下のホワイトペーパーを参照してください。データベース・ミラーリングにおけるベスト・プラクティス、および、パフォーマンスに関する考察（英語）。従って、使用するネットワークの帯域において、システムにかかる負荷が期待通り処理されるかどうかを事前に評価することをお勧めします。
手順
1. ログ配布が行われている２台のサーバをS1（プライマリ）、S2（セカンダリ）とした時に、S1とS2の間でログ配布が正常に行われていることを確認します。また、この時セカンダリ・サーバ上のデータベースが「復旧モードなし」の状態であることを確認してください（「スタンバイ」状態はNG）。確認はプライマリ・サーバ上のデータベースのプロパティから「トランザクションログの配布」-「セカンダリ サーバ インスタンスとデータベース」の設定から行えます。
2. データベース・ミラーリングのセキュリティ、エンドポイント、パーミッションなどの設定を行います。
3. プライマリ・サーバ上でログバックアップ・ジョブを停止（Disable状態に）します。この時、停止するまでに配布された全てのログがセカンダリ側で適応されるまで、しばらく待つようにしてください。
注意：プライマリ・サーバで採取された最新のトランザクションログ・バックアップと、セカンダリ・サーバ上で復旧された最新のログが異なっている場合、データベース・ミラーリングのセットアップ時に以下のようなエラーが発生します。
データベース“＜データベース名＞”のリモートコピーは、データベースログのローカルコピーに含められた時点までロールフォワードされていません。
4. 全てのログがセカンダリ・サーバのデータベースに適応されたら、セカンダリ・サーバ上でログコピー・ジョブとログ復旧のジョブを停止してください。
5. S1をプリンシパル、S2をミラーとしてデータベース・ミラーリングを有効にします。既定の設定ではデータベース・ミラーリングは同期モードで構成されるので、非同期モードでの運用を行う場合はトランザクションの安全性を変更してください。
6. S1とS2の間のログ配布の構成を削除します。
注意：一つのサーバにおいて、ログ配布のセカンダリとデータベース・ミラーリングのミラーの役割を兼ねる構成はサポートされていません。同一のデータベースに対してログ配布のセカンダリとデータベース・ミラーリングのミラーを一つのサーバで行っている場合、以下のようなメッセージがログ配布のリストアジョブの履歴に出力されます。
データベース '＜データベース名＞' で RESTORE 操作を実行できません。このデータベースは、データベースミラーリング用に構成されています。このデータベースを復元する場合は、ALTER DATABASE を使用してミラーリングの設定を削除してください。
このようにログ配布をデータベース・ミラーリングに変更することは、別のシナリオでもメリットを発揮します。たとえば、あるシステムでサーバS1とサーバS2の間でログ配布を行っていた場合、プライマリ・サーバにおいてメンテナンスを行う状況が考えられます。この場合、ログ配布のフェールオーバーを用いて停止時間を最小にするアプローチが一般的です（ログ配布のセカンダリへのフェールオーバー）。しかし、ログ配布のフェールオーバーでは、アプリケーション側で明示的に接続先を変更する必要があるため、場合によっては数分の停止時間が発生します。一方データベース・ミラーリングでは、アプリケーションから見て透過的なフェールオーバーを提供するため、停止時間が最小に抑えられます。通常はログ配布で運用し、メンテナンス時のみデータベース・ミラーリングを利用したいときは、まずログ配布をデータベース・ミラーリングに変更し、メンテナンスが終了したらフェールバックして業務をプライマリに戻し、再度ログ配布に構成し直すことも可能です。
ログ配布を用いて、データベース・ミラーリングのペアに待機系を追加
データベース・ミラーリングは可用性の面において多くの利点があります。ただし、現在（2008年2月）は2ノード構成に限定されています。一方、ログ配布の利点として複数の配布先を構成できる点が挙げられます。ログ配布を組み合わせることにより、データベース・ミラーリングに複数の待機系を追加することができます。例えば、データベース・ミラーリングを用いてローカルサイトで二重化されたシステムを災害時にも復旧できるように、遠隔地に待機系を設置したい、といった要求に対してこのソリューションが適応できます。
注意：データベース・ミラーリングのペアから、ログ配布先のセカンダリにフェールオーバーする場合はアプリケーション側において接続先を手動で切り換える必要があります。
手順
３台のサーバ、サーバS1、S2、S3の間でデータベース・ミラーリング、および、ログ配布を構成する手順について説明します。
1. S1をプリンシパル、S2をミラーとして、S1とS2の間でデータベース・ミラーリングを設定します。
2. S1においてフルバックアップを行い、それをS3においてNORECOVERYでリストアします。
3. S1をプライマリ、S3をセカンダリとしてログ配布を構成します。
(ア)SQL Server Management StudioのGUIを用いてログ配布を構成します（ログ配布を有効にする方法（SQL Server Management Studio））。
(イ)最後のダイアログで「OK」ボタンを押してログ配布を確立する前に、スクリプトを生成してローカルディスクに保存します。このスクリプトは後ほど使用します。
(ウ)「OK」ボタンを押してログ配布を確立します。
(エ)S1とS3の間でログ配布が行われていることを確認します。ログ配布のジョブのステータスにより状態を確認できます。
4. もしデータベース・ミラーリングが非同期モードで構成されている場合は同期モードに変更してください。S1からS2に手動でフェールオーバーを行います。この時、データベース・ミラーリングがホワイトペーパー（データベース・ミラーリング上でのアプリケーション・フェールオーバーの実装方法（英語））に従って構成されていればアプリケーションも自動的にフェールオーバー先のサーバに再接続します。
5. S2をプライマリ、S3をセカンダリとしてログ配布を構成します。
(ア)SQL Server Management StudioのGUIを使用しないでください。SQL Server Management Studioを用いた構成はデータベース・ミラーリングのプリンシパル側でのみ有効です。ここでは手順3-(イ)で生成したスクリプトを使用します。
(イ)手順3-(イ)で生成されたスクリプトには２つのセクションがあります。一つは「．．．プライマリ[＜サーバ名＞]で実行されるスクリプト．．．」とマークされているセクションで、もう一つは「．．．セカンダリ[＜サーバ名＞]で実行されるスクリプト．．．」とマークされているセクションです。ここでは「．．．プライマリ[＜サーバ名＞]で実行されるスクリプト．．．」とマークされている部分のみS2上で実行します。「．．．セカンダリ[＜サーバ名＞]で実行されるスクリプト．．．」とマークされている部分は手順3-(ウ)の際にすでにS3上で実行されているので再度実行する必要はありません。
注意：スクリプトに変更を加えないでください。S1からS3へのログ配布を構成したときに指定したトランザクションログのバックアップ先が、S2においても同じであることを確認してください。
(ウ)S2からS3へのログ配布が正常に行われていることを確認します。
6. S2からS1に手動でフェールオーバーを行います。
7. もし、手順4でデータベース・ミラーリングを同期モードに変更していた場合は、再度非同期モードへ変更します。
上記の手順は、サーバS1とS2の両方をログ配布のプライマリとして構成します。データベース・ミラーリングのフェールオーバーの際、新しいプリンシパルがログ配布のプライマリの役割を透過的に引き継ぎます。ログ・バックアップのジョブはサーバS1とS2の両方で作成されます。プリンシパル（S1）側では、ログ配布のセカンダリ・サーバがログを取得する先の共有フォルダにログのバックアップを作成します。一方、ミラー（S2）側ではログ・バックアップのジョブは動作しますが何も生成しません。ミラー側のジョブ・ステータスにおいて以下のようなメッセージが見られるでしょう。
トランザクション ログのバックアップを生成できませんでした。データベースが NORECOVERY モードまたは STANDBY モードになっています。
上記のメッセージはミラー側において出力されるのは自明であり、問題ありません。
ログ配布のセカンダリ・サーバ（S3）側に置いて、S1またはS2のどちらのサーバがプライマリとして動作していても違いはありません。セカンダリ・サーバは同じ共有から必要となるログ・バックアップを取得しデータベースに適応します。
今回は一つのセカンダリ・サーバを持つ構成を紹介しましたが、複数のログ配布セカンダリ・サーバを持つことが可能です。
起こり得る問題
データベース・ミラーリングのペアから3番目のサーバにログ配布を行う際に、起こり得る問題があります。それはミラーリングされているデータベースと、ログ配布により作成されているデータベースの間にログ・シーケンス・ナンバー（Log Sequence Number: LSN）の不一致が発生する場合、ログ配布のセカンダリ・サーバにおいてエラーが発生する問題です。データベース・ミラーリングのLSNの詳細についてはBooks Onlineの以下のページをご参照ください。データベース ミラーリング セッション。LSNの詳細についてはBooks Onlineの以下のページをご参照ください。ログ シーケンス番号の概要。この問題は以下のようなケースおいて発生します。
l S1がLSN 9, 10, 11のログを記録
l S2がLSN9, 10のログを記録
l S2においてLSN11のログが記録していないため、アプリケーションはLSN11の処理に対するコミット完了をまだ受け取っていない
l S1において障害が発生し、ミラーリングの機能でS2にフェールオーバが行われる
l S1において最後に採取されたログ・バックアップはLSN11を含む
l 新たにS2で採取されるログ・バックアップはLSN10までで、LSN11を含んでいない
l ミラーリングされているデータベース（S2）と、ログ配布のセカンダリ・サーバ（S3）の間でLSNの不一致が発生
このとき以下のようなメッセージがログ配布のセカンダリ・サーバのリストアジョブの履歴に記録されます。
"＜ログ・バックアップファイル名＞" の末尾のバックアップ データのフォーマットが不適切です。メディアのバックアップ セットが破損していて使用できない可能性があります。
ログ配布のセカンダリ・サーバはプライマリ・サーバと同期がとれていない状態に陥っているため、ログ配布の構成を再度作り直す必要があります。その際は、プライマリ・サーバ上で再度データベースのフルバックアップを採取して、ログ配布の構成を構築し直す必要があります。この問題はSQL Serverの将来のリリースにおいて修正される予定です。
ログ配布のペアとデータベース・ミラーリングのペアを切り替える方法
データベース・ミラーリングとログ配布を組み合わせたシステムを運用している場合、データベース・ミラーリングのペアリングと、ログ配布のペアリングを簡単に切り替える（スイッチング）ことができます。たとえば、サーバS1とサーバS2の間でデータベース・ミラーリングを行っており、ミラーリングのプリンシパルからサーバS3にログ配布を行っている場合、サーバS2をログ配布のセカンダリ・サーバに変更して、サーバS3をミラーリングのミラーに変更することができます。このような変更はローリング・アップグレードを行う際、メリットがあります。上記の例を行う場合の手順は以下のようになります。
手順
1. S2をログ配布のプライマリ・サーバから削除します。SQL Server Management Studioから変更は行わないでください。その代り、システムのストアドプロシージャを使用します。
(ア)S2上でsp_delete_log_shipping_primary_scondaryを実行します。
（例）
sp_delete_log_shipping_primary_scondary ‘<データベース名>’, ‘S3’, ‘<データベース名>’
(イ)S2上でsp_delete_log_shipping_primary_databaseを実行します。
（例）
sp_delete_log_shipping_primary_database ‘<データベース名>’
2. S1とS2の間のデータベース・ミラーリングを削除します。
3. 上記の「ログ配布の構成をデータベース・ミラーリングの構成に変更する方法」を用いてS1とS3の間のログ配布の構成をデータベース・ミラーリングに変更します。この時点でS1がデータベース・ミラーリングのプリンシパルに、S3がミラーになります。
4. 上記の「ログ配布を用いて、データベース・ミラーリングのペアに待機系を追加する方法」を用いて、S2をログ配布のセカンダリ・サーバとして手順３で作成したミラーリング・データベースからログ配布を行うように構成します。この時点でS1、S3がログ配布のプライマリ・サーバに、S2がセカンダリ・サーバになります。
なお、SQL Server 2005のデータベース・ミラーリングの機能に関する詳細な検証結果がホワイトペーパーにまとめてられてMicrosoft TechNet のSQL Server TechCenter上で公開されておりますので、ご興味ある方はこちらも是非ご参照ください。
SQL Server 2005 **徹底検証シリーズ **
SQL Server 2005 データベース ミラーリング検証
結論
SQL Server2005のログ配布とデータベース・ミラーリングの機能を組み合わせることによって、システムの可用性を高め、ディザスタ・リカバリに対するソリューションを提供することができます。ログ配布の構成はデータベース・ミラーリングの構成に変更可能です。また、データベース・ミラーリングは2ノードの構成しかサポートされていませんが、ログ配布を組み合わせることにより、待機系ノードを追加することができます。
コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。