@loopback_detection

ピア ツー ピア レプリケーションは、データのコピーを複数のサーバー インスタンス ( ノード) で保持することにより、可用性の高いスケールアウト ソリューションを実現します。 ピア ツー ピア レプリケーションはトランザクション レプリケーションを基礎としており、トランザクション的に一貫性のある変更がほぼリアルタイムで反映されます。 これにより、読み取り操作のスケールアウトを必要とするアプリケーションで、クライアントからの読み取りを複数のノードに分散することができます。 また、データがほぼリアルタイムで複数のノードに保持されるため、データの冗長性が実現され、データの可用性が向上します。

たとえば Web アプリケーションでは、 ピア ツー ピア レプリケーションを利用すると次のようなメリットがあります。

• カタログのクエリやその他の読み取りが複数のノードに分散されるため、 読み取りが増加してもパフォーマンスを維持できます。

• システムのいずれかのノードに障害が発生した場合、アプリケーション層でそのノードへの書き込みを別のノードにリダイレクトできるため、 可用性が維持されます。

• ノードのメンテナンスやシステム全体のアップグレードが必要な場合も、それぞれのノードをオフラインにして再度システムに追加することができるため、アプリケーションの可用性に影響が及ぶことはありません。

ピア ツー ピア レプリケーションでは、読み取り操作のスケール アウトは実現されますが、トポロジへの書き込みのパフォーマンスは 1 つのノードの場合と変わりません。 これは、すべての挿入、更新、および削除が、最終的にすべてのノードに反映されるためです。 特定のノードに変更が適用されたことをレプリケーションが認識するため、変更がノードを何度も循環することはありません。 次のような理由から、各行の書き込み操作は 1 つのノードだけで実行することをお勧めします。

• 行が複数のノードで変更されると、他のノードに反映される際に競合が発生したり、場合によっては更新データが失われたりする可能性があります。

• 変更がレプリケートされるときには常にある程度の遅延が生じます。 最新の変更が直ちに反映される必要があるアプリケーションでは、複数のノードで動的に負荷を分散すると問題が発生する場合があります。

ピア ツー ピア レプリケーションには、ピア ツー ピア トポロジの競合の検出を有効にするオプションが含まれています。 このオプションは、検出されない競合によって引き起こされる問題 (アプリケーションの動作の矛盾や更新データの喪失など) の防止に役立ちます。 このオプションを有効にすると、競合する変更が、ディストリビューション エージェントの障害を引き起こす重大なエラーとして既定で扱われるようになります。 競合が発生した場合は、その競合が手動で解決されて、トポロジでデータの一貫性が確保されるまで、トポロジが一貫性のない状態のままになります。 詳細については、「 ピア ツー ピア レプリケーションにおける競合検出」を参照してください。

ピア ツー ピア トポロジ

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

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 つずつあり、サポート エンジニアがカスタマー コールに関する情報を入力、更新する際に使用されています。 トポロジは時間でパーティション分割されるので、 現在営業中のノードでのみ更新が行われ、その更新は他の参加データベースに送られます。 このトポロジには、次のような利点があります。

• 孤立せず独立性を維持。各オフィスはデータを個別に挿入、更新、または削除できますが、それらはすべて他の参加データベースにレプリケートされるため、データを共有することもできます。

• 参加データベースのいずれかで障害が発生したり、メンテナンスが行われている場合に高い可用性を実現。

  

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

• 別のオフィスが開いている場合。

• ディスク障害やその他の重大な障害が発生したときに、より高い可用性を提供してメンテナンスをサポートしたり、フォールト トレランスを強化する場合。

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

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

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

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

ここでは、ピア ツー ピア レプリケーションを使用する際に考慮する必要がある情報とガイドラインを示します。

一般的な考慮事項

• ピア ツー ピア レプリケーションは、エンタープライズ バージョンのSQL Serverでのみ使用できます。

• ピア ツー ピア レプリケーションに参加するすべてのデータベースに、同一のスキーマとデータを含める必要があります。

  • オブジェクト名、オブジェクト スキーマ、およびパブリケーション名が同一である必要があります。

  • パブリケーションで、スキーマ変更のレプリケートが許可されている (パブリケーション プロパティ replicate_ddl が既定の 1 に設定されている) 必要があります。詳細については、「パブリケーション データベースでのスキーマの変更」を参照してください。

  • 行と列のフィルター処理はサポートされません。

• ノードごとに独自のディストリビューション データベースを使用することをお勧めします。 これにより、単一地点での失敗が発生する可能性を低減できます。

• テーブルおよびその他のオブジェクトは、単一のパブリケーション データベース内の複数のピア ツー ピア パブリケーションに含めることはできません。

• サブスクリプションを作成するには、パブリケーションをピア ツー ピア レプリケーションで有効にする必要があります。

• サブスクリプションは、バックアップを使用するか、 [レプリケーションのサポートのみ] オプションで初期化する必要があります。 詳細については、「 スナップショットを使用しないトランザクション サブスクリプションの初期化を使用して、サブスクリプションを手動で初期化する方法について説明します。

• ID 列の使用はお勧めできません。 ID を使用する場合は、各参加データベースのテーブルに割り当てられた範囲を手動で管理する必要があります。 詳細については、「Replicate Identity Columns」 (ID 列のレプリケート) で、"Assigning Ranges for Manual Identity Range Management" (手動で ID 範囲を管理する場合の範囲の割り当て) セクションを参照してください。

機能の制限

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

• スナップショットを使用した初期化および再初期化

• 行と列のフィルター選択

• timestamp 列

• SQL Server 以外のパブリッシャーとサブスクライバー

• 即時更新とキュー更新サブスクリプション

• 匿名サブスクリプション

• 部分サブスクリプション

• アタッチ可能なサブスクリプションと変換可能なサブスクリプション (これらのオプションはどちらも、SQL Server 2005 では非推奨となりました)。

• 共有ディストリビューション エージェント

• ディストリビューション エージェントのパラメーター -SubscriptionStreams とログ リーダー エージェントのパラメーター -MaxCmdsInTran

• アーティクルのプロパティ @destination_owner および @destination_table

• ピア ツー ピア トランザクション レプリケーションでは、ピア ツー ピア パブリケーションの一方向トランザクション サブスクリプションを作成できません

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

• パブリケーション プロパティ @allow_initialize_from_backup には、 の true値が必要です。

• article プロパティ @replicate_ddl には、 の true値が必要です。 @identityrangemanagementoption には の manual値が必要であり、 @status にはオプション 24 が設定されている必要があります。

• アーティクルプロパティ @ins_cmd、 @del_cmd、 および@upd_cmdの 値を に SQL設定することはできません。

• サブスクリプション プロパティ@sync_typeには、 または automaticのnone値が必要です。

メンテナンスの注意事項

次のアクションを実行する場合は、システムを停止する必要があります。 システムの停止を実行するには、すべてのノードのパブリッシュされたテーブルで処理を停止し、他のすべてのノードからのすべての変更を各ノードが受信しているかどうかを確認します。

• SQL Server 2005 ノードを既存のトポロジに追加する

• 既存のパブリケーションへのアーティクルの追加

• スキーマの変更

• バックアップからのノードの復元

詳細については、「 レプリケーション トポロジの休止 (レプリケーション Transact-SQL プログラミング)」 および「 ピアツーピア トポロジの管理 (レプリケーション Transact-SQL プログラミング)」を参照してください。

• ピア ツー ピア トポロジに新しいノードを追加する場合は、新しいノードの追加後に作成されたバックアップのみを使用して復元する必要があります。

• ピア ツー ピア トポロジでは、サブスクリプションの再初期化を実行できません。 ノードで新しいデータのコピーを確実に保持する必要がある場合は、そのノードでバックアップを復元してください。

参照

ピアツーピア トポロジの管理 (レプリケーション Transact-SQL プログラミング)
スナップショット レプリケーションおよびトランザクション レプリケーションのバックアップと復元の方式
トランザクション レプリケーションで使用するパブリケーションの種類