none
複数DBをミラーリングしている場合に、ミラー実施順序を指定可能か RRS feed

  • 質問

  •  はじめまして。
    状況的にこの問題がクリアになっていないと、運用に進めないため質問させて頂きます。

    <質問>
    ミラーリング実施してるDBが複数存在する場合に、ミラーリングの実施順序を指定することは出来るのでしょうか?

    例えば以下のような状況において、
    DB_1のミラーが完了してからDB_2のミラーが実行されるような指定は出来るのでしょうか。

    サーバA    サーバB
    DB_1(P) ⇒ DB_1(M)
    DB_2(P) ⇒ DB_2(M)

    ※P = プリンシパル、M = ミラー

    DB_1とDB_2は連携しており、DB_2(M)のみミラー実施された状態でサーバAが停止することを避けたいのが
    目的です。

    なお、プリンシパル側のDB_1、DB_2間の動作は、
    DB_1へのアップデート処理が行われてから、DB_2に対してアップデート処理が実施される動きをします。

    何卒よろしくお願いします。

    2009年2月24日 8:48

回答

  • こんにちは、naginoです。

    SQL Server のバージョンが不明ですので 2008 という想定で以下記載します。

    SQL Server の標準機能の範囲内では複数のミラーリングで前後関係を維持するような仕組みはありません。
    ミラーリングの機能から見た場合、DB_1 で構成しているミラーリングと、 DB_2 で構成しているミラーリングは全く独立のものであり、その間では連携しません。
    サードパーティーでそのようなソリューションが存在するかどうかは、不勉強のため私ではちょっと分かりません。

    ただし、必ず DB_1 にアップデート処理を行い、それが完了してから初めて DB_2 にアップデート処理を行い、かつ高い安全性モード(同期ミラーリング)を使用している限りにおいては、DB_1 のアップデート処理が完了した時点で DB_1 のミラーも完了しています。
    結果として正常動作する限りにおいては DB_1 はミラーされていないが DB_2 はミラーされているという状態にはなりません。

    なお、DB_1 側で何らかの障害が発生してミラーリングが行えない場合に関して、アップデート処理を DB_2 側に行わないというオペレーションないしシステムの対応が必要です。
    そうでないと、DB_1 側でミラーリングが行われていないが、DB_2 のアップデート処理が完了した時点で DB_2 側のミラーが行われてしまいます。

    しかし、本来ハードウェア障害でも継続運用するための仕組みがミラーリングですので、ハードウェア障害で処理を中断するという仕組みを考えるというのではミラーリングを構成する意義が失われるように思われます。
    目的等詳細が分かりませんので、このあたりはご自身でご判断ください。

    ご参考になれば幸いです。

    MCITP(Database Developer/Database Administrator)
    • 回答としてマーク yagizo 2009年3月2日 9:08
    2009年2月25日 4:26
  • こんにちは、naginoです。

    繰り返しではありますが、前提として複数ミラーリング間での前後関係は Microsoft 社ではなく yagizo 様ご自身で保証しなければならない点、ご確認ください。
    もちろん私が保証するものでもありません。

    それはそれとして、特定ケースの詳細を考察するのは技術的に興味深いところです。

    > この内容について確認させて頂きたいのですが、同期ミラーリングを実施している場合、
    > DB_1(M)へのミラー処理完了にならないとDB_1(P)へのアップデート処理完了というステータスにならない
    > という理解でよろしいでしょうか。
    「同期ミラーリング」と記載してしまいましたが、厳密には「同期データベースミラーリング」「高い安全性モード」「トランザクションの安全性が FULL に設定されている」ということです。
    ご存知だとは思いますので念のための補足ですが、「トランザクションの安全性が FULL に設定されている」場合は、以下の手順でトランザクションの処理が行われますので、改めてご確認ください。
     -1.プリンシパルでトランザクションログに書き込み
     -2.プリンシパルでトランザクションの処理と、ミラーへのログの送信
     -3.ミラーでトランザクションログに書き込み
     -4.ミラーからプリンシパルへ完了通知
     -5.プリンシパルからクライアントへ完了通知
    4 の処理を待ってから 5 が行われるため、つまりミラーの処理が完了しないとプリンシパルの処理は完了しません。
    このあたりについては、2005 ということであれば以下に詳しくありますので、ご確認ください。
    http://msdn.microsoft.com/ja-jp/library/ms179344(SQL.90).aspx
    http://technet.microsoft.com/ja-jp/library/cc917680.aspx

    ただし、これは正常動作においての話です。
    障害時の動作は監視サーバの有無で動作が変わりますので、監視サーバが無いケースを考えてみます。

    プリンシパルがダウンしていると、クライアント側で特に対策していない限りトランザクションは失敗します。
    自動フェールオーバーもしませんので、ミラー側のデータベースは復旧中のため、使用できません。
    このケースはクライアント側から検知しやすいので、特に問題にはならないでしょう。

    一方ミラーがダウンしていると、プリンシパルは影響を受けずにトランザクションが成功します。
    ただし同期はされません。
    この場合、クライアント側で検知する仕組みを作りこむ必要があります。
    また、実際の処理と検知を別のタイミングで行うと、その間にミラーがダウンするケースが考えられるため、同時に行う必要があります。
    1例としては、実際の処理と、ミラーの状態を監視するための動的管理ビュー(DMV)からの情報取得を同一トランザクションで行うことになるかと思います。

    ところが、これはリンクサーバーとトリガ、ないしは2台のサーバに対する同一のクエリを分散トランザクションによって 1 つのトランザクションとすることで実現できます。
    その上、こちらですとミラー側の障害検知も単純にトランザクションの失敗で判別できます。

    これらを考えると、このケースではミラーリングによる複雑な構成と、ミラーの状況を監視するための仕組みを用意してまでミラーリングを使用する意味が私には分からないため、意義が失われるのでは、と前回記載しています。
    ミラーリングで同期の管理を隠蔽・抽象化しているのにそれを明確に管理しなければならないという本ケースにおいて、本当にミラーリングを使用しなければならないのでしょうか。
    もしそうであるならば、私が理解できていない仕様・要件があることが考えられますので、私の記載している内容が本ケースに適合していないことも考えられ、その点を大変心配しております。

    今一度ご自身でご高察ください。

    MCITP(Database Developer/Database Administrator)
    • 回答としてマーク yagizo 2009年3月2日 9:03
    2009年3月2日 3:41

すべての返信

  • こんにちは、naginoです。

    SQL Server のバージョンが不明ですので 2008 という想定で以下記載します。

    SQL Server の標準機能の範囲内では複数のミラーリングで前後関係を維持するような仕組みはありません。
    ミラーリングの機能から見た場合、DB_1 で構成しているミラーリングと、 DB_2 で構成しているミラーリングは全く独立のものであり、その間では連携しません。
    サードパーティーでそのようなソリューションが存在するかどうかは、不勉強のため私ではちょっと分かりません。

    ただし、必ず DB_1 にアップデート処理を行い、それが完了してから初めて DB_2 にアップデート処理を行い、かつ高い安全性モード(同期ミラーリング)を使用している限りにおいては、DB_1 のアップデート処理が完了した時点で DB_1 のミラーも完了しています。
    結果として正常動作する限りにおいては DB_1 はミラーされていないが DB_2 はミラーされているという状態にはなりません。

    なお、DB_1 側で何らかの障害が発生してミラーリングが行えない場合に関して、アップデート処理を DB_2 側に行わないというオペレーションないしシステムの対応が必要です。
    そうでないと、DB_1 側でミラーリングが行われていないが、DB_2 のアップデート処理が完了した時点で DB_2 側のミラーが行われてしまいます。

    しかし、本来ハードウェア障害でも継続運用するための仕組みがミラーリングですので、ハードウェア障害で処理を中断するという仕組みを考えるというのではミラーリングを構成する意義が失われるように思われます。
    目的等詳細が分かりませんので、このあたりはご自身でご判断ください。

    ご参考になれば幸いです。

    MCITP(Database Developer/Database Administrator)
    • 回答としてマーク yagizo 2009年3月2日 9:08
    2009年2月25日 4:26
  •  naginoさん

    ご回答頂き感謝いたします。

    SQL Server の標準機能の範囲内では複数のミラーリングで前後関係を維持するような仕組みは無いということで
    承知いたしました。

    > ただし、必ず DB_1 にアップデート処理を行い、それが完了してから初めて DB_2 にアップデート処理を行い、
    > かつ高い安全性モード(同期ミラーリング)を使用している限りにおいては、DB_1 のアップデート処理が完了した
    > 時点で DB_1 のミラーも完了しています。
    > 結果として正常動作する限りにおいては DB_1 はミラーされていないが DB_2 はミラーされているという状態には
    > なりません。
    この内容について確認させて頂きたいのですが、同期ミラーリングを実施している場合、
    DB_1(M)へのミラー処理完了にならないとDB_1(P)へのアップデート処理完了というステータスにならない
    という理解でよろしいでしょうか。

    ちなみに、こちらの状況をお話しさせていただくと、
    DB_1のアップデートが実行されてから、DB_2のアップデートが実行されるような仕組みになっていますので、
    上に記載させて頂いた内容の理解通りであれば、問題は発生しないことになると思います。

    また、補足情報になりますが使用しているSQL Serverのバージョンは2005 Standard Editionになります。

    以上になります。
    何卒よろしくお願いします。
    2009年2月25日 12:37
  • こんにちは、naginoです。

    繰り返しではありますが、前提として複数ミラーリング間での前後関係は Microsoft 社ではなく yagizo 様ご自身で保証しなければならない点、ご確認ください。
    もちろん私が保証するものでもありません。

    それはそれとして、特定ケースの詳細を考察するのは技術的に興味深いところです。

    > この内容について確認させて頂きたいのですが、同期ミラーリングを実施している場合、
    > DB_1(M)へのミラー処理完了にならないとDB_1(P)へのアップデート処理完了というステータスにならない
    > という理解でよろしいでしょうか。
    「同期ミラーリング」と記載してしまいましたが、厳密には「同期データベースミラーリング」「高い安全性モード」「トランザクションの安全性が FULL に設定されている」ということです。
    ご存知だとは思いますので念のための補足ですが、「トランザクションの安全性が FULL に設定されている」場合は、以下の手順でトランザクションの処理が行われますので、改めてご確認ください。
     -1.プリンシパルでトランザクションログに書き込み
     -2.プリンシパルでトランザクションの処理と、ミラーへのログの送信
     -3.ミラーでトランザクションログに書き込み
     -4.ミラーからプリンシパルへ完了通知
     -5.プリンシパルからクライアントへ完了通知
    4 の処理を待ってから 5 が行われるため、つまりミラーの処理が完了しないとプリンシパルの処理は完了しません。
    このあたりについては、2005 ということであれば以下に詳しくありますので、ご確認ください。
    http://msdn.microsoft.com/ja-jp/library/ms179344(SQL.90).aspx
    http://technet.microsoft.com/ja-jp/library/cc917680.aspx

    ただし、これは正常動作においての話です。
    障害時の動作は監視サーバの有無で動作が変わりますので、監視サーバが無いケースを考えてみます。

    プリンシパルがダウンしていると、クライアント側で特に対策していない限りトランザクションは失敗します。
    自動フェールオーバーもしませんので、ミラー側のデータベースは復旧中のため、使用できません。
    このケースはクライアント側から検知しやすいので、特に問題にはならないでしょう。

    一方ミラーがダウンしていると、プリンシパルは影響を受けずにトランザクションが成功します。
    ただし同期はされません。
    この場合、クライアント側で検知する仕組みを作りこむ必要があります。
    また、実際の処理と検知を別のタイミングで行うと、その間にミラーがダウンするケースが考えられるため、同時に行う必要があります。
    1例としては、実際の処理と、ミラーの状態を監視するための動的管理ビュー(DMV)からの情報取得を同一トランザクションで行うことになるかと思います。

    ところが、これはリンクサーバーとトリガ、ないしは2台のサーバに対する同一のクエリを分散トランザクションによって 1 つのトランザクションとすることで実現できます。
    その上、こちらですとミラー側の障害検知も単純にトランザクションの失敗で判別できます。

    これらを考えると、このケースではミラーリングによる複雑な構成と、ミラーの状況を監視するための仕組みを用意してまでミラーリングを使用する意味が私には分からないため、意義が失われるのでは、と前回記載しています。
    ミラーリングで同期の管理を隠蔽・抽象化しているのにそれを明確に管理しなければならないという本ケースにおいて、本当にミラーリングを使用しなければならないのでしょうか。
    もしそうであるならば、私が理解できていない仕様・要件があることが考えられますので、私の記載している内容が本ケースに適合していないことも考えられ、その点を大変心配しております。

    今一度ご自身でご高察ください。

    MCITP(Database Developer/Database Administrator)
    • 回答としてマーク yagizo 2009年3月2日 9:03
    2009年3月2日 3:41
  •  naginoさん

    丁寧にご説明頂き大変助かりました。
    どうもありがとうございました。

    yagizo

    2009年3月2日 9:06