次の方法で共有

ピア ツー ピア トランザクション レプリケーション

  • [アーティクル]

更新 : 2006 年 12 月 12 日

ピア ツー ピア トランザクション レプリケーションは、レプリケーションに参加しているデータベースのデータを読み取ったり、変更するアプリケーション用に設計されています。たとえば、オンライン ショッピング アプリケーションはピア ツー ピア レプリケーションに適しています。データを読み取るクエリを複数のデータベースに分散することで、アプリケーションのパフォーマンスを向上させることができるからです。また、データベースをホストしているサーバーのいずれかが使用できなくなった場合は、データの同一コピーが格納されている他のサーバーにトラフィックをルーティングするように、アプリケーションをプログラミングすることができます。処理をすべてのノードに分散できるので、読み取りのパフォーマンスが向上します。最終的にすべての変更がすべてのノードに反映されるので、トポロジの集計の更新、挿入、および削除のパフォーマンスは、単一ノードと似ています。

ピア ツー ピア トポロジのすべてのノードはピアです。各ノードは同じスキーマとデータにパブリッシュおよびサブスクライブします。変更 (挿入、更新、および削除) は、すべてのノードで実行できます。指定された 1 つのノードに変更が適用されたことをレプリケーションが認識するので、変更がノードを何度も循環することはありません。

ms151196.note(ja-jp,SQL.90).gifメモ :
データにアクセスしてそのデータを変更するカスタム アプリケーションでは、挿入、更新、および削除をパーティション分割して、1 つのノードの特定の行に対する変更が、トポロジ内の他のすべてのデータベースと同期されてから、別のノードでその行が変更されるようにする必要があります。アプリケーションから、複数のノードの特定の行に対し、競合する変更が同時に実行された場合は、競合の処理に適しているマージ レプリケーションを使用してください。マージ レプリケーションの詳細については、「マージ レプリケーションの概要」を参照してください。

標準トランザクション レプリケーションは、サブスクライバが読み取り専用であることを前提とし、構造は階層化されています。通常は、1 つのパブリッシャが 1 つ以上のサブスクライバにデータをパブリッシュします。標準トランザクション レプリケーションは、再パブリッシュ階層もサポートします。更新はパブリッシャから一連の再パブリッシュ サブスクライバに配信され、それらのサブスクライバは受信した更新を、最終的な一連のリーフ ノード サブスクライバに配信します。更新サブスクリプションでは、サブスクライバはパブリッシャに変更をプッシュして戻すことができますが、サブスクライバとパブリッシャ間で移動が行われるときには、階層構造に従って変更が行われるため、配置は階層構造のまま変わりません。読み取り専用のトランザクション レプリケーションや更新サブスクリプションを使用するトランザクション レプリケーションとは対照的に、ピア ツー ピア レプリケーション トポロジのノード間の関係は、階層関係ではなくピア関係であるので、各ノードには同一のスキーマとデータが含まれます。

ms151196.note(ja-jp,SQL.90).gifメモ :
複数の参加データベースで更新を行うことはできますが、ピア ツー ピア トポロジには即時更新パブリケーション オプションまたはキュー更新パブリケーション オプションは不要または許可されないという点を理解することが重要です。即時更新およびキュー更新の詳細については、「トランザクション レプリケーションの更新可能なサブスクリプション」を参照してください。

ピア ツー ピア トポロジ

次のシナリオは、ピア ツー ピア レプリケーションの典型的な使用方法を示しています。

2 つの参加データベースがあるトポロジ

2 つのノードによるピア ツー ピア レプリケーション

この図はそれぞれ、2 つの参加データベースを示し、ユーザーのトラフィックは、アプリケーション サーバーを通じてデータベースに送信されています。この構成は、Web サイトからワークグループ アプリケーションまでさまざまなアプリケーションに使用でき、次のような利点があります。

  • 読み取りが 2 つのサーバーに分散されるため、読み取りのパフォーマンスが向上する。
  • 1 つのノードでメンテナンスが必要な場合や障害が発生した場合に高い可用性を実現する。

どちらの図でも、読み取り処理の負荷が参加データベース間で分散されていますが、更新の処理は次のように異なっています。

  • 左側の図では、更新は 2 つのサーバー間でパーティション分割されています。たとえば、データベースに製品カタログが含まれている場合、カスタム アプリケーションでは、A ～ M で始まる製品名についてはノード "A" に更新を送信し、N ～ Z で始まる製品名についてはノード "B" に更新を送信するようにできます。その後、更新は他のノードにレプリケートされます。
  • 右側の図では、すべての更新がノード "B" に送信されます。そこから、更新はノード "A" にレプリケートされます。"B" がメンテナンスなどの理由でオフラインになると、アプリケーション サーバーはすべての処理を "A" に送信できます。"B" がオンラインに戻ると、更新は "B" に送られて、アプリケーション サーバーはすべての更新を "B" に移動することも、"A" への送信を維持することもできます。

ピア ツー ピア レプリケーションはどちらの方法もサポートしますが、右側の図にある中央の更新例は、標準トランザクション レプリケーションでも頻繁に使用されます。

3 つ以上の参加データベースがあるトポロジ

分散した場所へのピア ツー ピア レプリケーション

この図は、ロサンゼルス、ロンドン、台北にオフィスを持つ、世界規模のソフトウェア サポート企業にバックエンドを提供する 3 つの参加データベースを示しています。各オフィスのサポート エンジニアはカスタマ コールを受けて、各カスタマ コールに関する情報を入力および更新します。3 つのオフィスの時間帯は 8 時間の時差があるため、1 日の中で時間が重なることはありません。台北オフィスが閉まっているときに、ロンドンオフィスは開いています。1 つのオフィスが閉まっているときに 1 つのコールが進行している場合、コールは、次に開くオフィスの代表者に転送されます。

それぞれのオフィスにはデータベースとアプリケーション サーバーが 1 つずつあり、サポート エンジニアがカスタマ コールに関する情報を入力、更新する際に使用されています。トポロジは時間でパーティション分割されるので、現在営業中のノードでのみ更新が行われ、その更新は他の関連データベースに送られます。このトポロジには、次のような利点があります。

  • 孤立せず独立性を維持。各オフィスはデータを個別に挿入、更新、または削除できますが、それらはすべて他の参加データベースにレプリケートされるため、データを共有することもできます。
  • 参加データベースのいずれかで障害が発生したり、メンテナンスが行われている場合に高い可用性を実現。
    3 つまたは 4 つのノードによるピア ツー ピア レプリケーション

この図は、3 つのノードで構成されるトポロジへの 1 つのノードの追加を示しています。ノードは次のような場合に追加できます。

  • 別のオフィスが開いている場合。
  • 破局的な障害が発生したときに、より高い可用性を提供してメンテナンスをサポートしたり、フォールト トレランスを強化する場合。
  • 1 つ以上のノードでメンテナンスの必要があったり障害が発生したときの可用性を最大限にする場合。3 つおよび 4 つのノードで構成されるトポロジはどちらも、すべてのデータベースが他のすべてのデータベースにパブリッシュおよびサブスクライブしていることに注目してください。ノードを追加するときには、配置と管理のパフォーマンスおよび複雑さを考慮して可用性とスケーラビリティを調整する必要があります。

ピア ツー ピア レプリケーションの構成

ピア ツー ピア レプリケーション トポロジの構成は、一連の標準トランザクション パブリケーションおよびサブスクリプションの構成とよく似ています。次のトピックで説明する手順では、3 ノード システムの構成を説明しますが、これは上記の左側の図に示した構成と似ています。

ピア ツー ピア トランザクション レプリケーションを構成するには

ピア ツー ピア レプリケーションの使用に関する注意点

ピア ツー ピア レプリケーションを使用する場合は、次の点に注意してください。

全般的な注意点

  • ピア ツー ピア レプリケーションは、SQL Server 2005 Enterprise Edition でのみ使用できます。
  • すべての参加データベースに同一のスキーマとデータを含める必要があります。
    • オブジェクト名、オブジェクト スキーマ、およびパブリケーション名は、参加データベース間で同一であることが必要です。
    • パブリケーションで、スキーマ変更のレプリケートが許可されている (パブリケーション プロパティ replicate_ddl が既定の 1 に設定されている) 必要があります。詳細については、「パブリケーション データベースでのスキーマの変更」を参照してください。
    • 行と列のフィルタ処理はサポートされません。
  • ノードごとに独自のディストリビューション データベースを使用することをお勧めします。これにより、単一地点での失敗が発生する可能性を低減できます。
  • テーブルおよびその他のオブジェクトは、単一のパブリケーション データベース内の複数のピアツーピアパブリケーションに含めることはできません。
  • サブスクリプションを作成するには、パブリケーションをピア ツー ピア レプリケーションで有効にする必要があります。
  • サブスクリプションは、バックアップを使用するか、[レプリケーションのサポートのみ] オプションで初期化する必要があります。詳細については、「スナップショットを使用しないトランザクション サブスクリプションの初期化」を参照してください。
  • 競合の検出と解決は使用できません。ピアと同期されるまで、特定の行の更新は 1 つのデータベースで 1 回のみ実行されます。これは、たとえば、一連の行の更新をアプリケーションから特定のノードに送信すると発生することがあります。
  • ID 列の使用はお勧めできません。ID を使用する場合は、各参加データベースのテーブルに割り当てられた範囲を手動で管理する必要があります。詳細については、「ID 列のレプリケート」の「手動で ID 範囲を管理する場合の範囲の割り当て」を参照してください。

機能の制限

ピア ツー ピア レプリケーションでは、トランザクション レプリケーションの主要な機能がサポートされています。サポートされていない機能を次に示します。

  • スナップショットを使用した初期化および再初期化
  • 行と列のフィルタ選択
  • timestamp 列
  • SQL Server 以外のパブリッシャとサブスクライバ
  • 即時更新とキュー更新サブスクリプション
  • 匿名サブスクリプション
  • 部分サブスクリプション
  • アタッチ可能なサブスクリプションと変換可能なサブスクリプション (どちらも SQL Server 2005 では非推奨)
  • 共有ディストリビューション エージェント
  • ディストリビューション エージェントのパラメータ -SubscriptionStreams とログ リーダー エージェントのパラメータ -MaxCmdsInTran
  • アーティクルのプロパティ @destination_owner および @destination_table

次のプロパティには特別な注意が必要です。

  • パブリケーションのプロパティ @allow_initialize_from_backup には値 "true" が必要です。
  • アーティクルのプロパティ @replicate_ddl には値 "true" が必要です。@identityrangemanagementoption には値 "manual" が必要です。@status にはオプション "24" を設定する必要があります。
  • アーティクルのプロパティ @ins_cmd、@del_cmd、および @upd_cmd の値は "SQL" に設定できません。
  • サブスクリプションのプロパティ @sync_type には値 "none" または "automatic" が必要です。

メンテナンスの注意事項

変更履歴

リリース 履歴

2006 年 12 月 12 日
変更内容 :
  • この機能が SQL Server 2005 Enterprise Edition でのみ使用できるという記述を追加しました。

2006 年 7 月 17 日
変更内容 :
  • ピア ツー ピア レプリケーションで使用できるトランザクション レプリケーションの機能に関する説明を更新しました。

参照

概念

スナップショット レプリケーションおよびトランザクション レプリケーションのバックアップと復元の方式
トランザクション レプリケーションで使用するパブリケーションの種類

その他の技術情報

ピア ツー ピア トポロジを管理する方法 (レプリケーション Transact-SQL プログラミング)

ヘルプおよび情報

SQL Server 2005 の参考資料の入手