マージ レプリケーションで競合を検出および解決する方法

サブスクリプションを作成する際には、プッシュ サブスクリプションであるかプル サブスクリプションであるかの指定に加え、クライアント サブスクリプションであるかサーバー サブスクリプションであるかを指定します。サブスクリプションの作成後は、種類を変更することはできません (以前のバージョンの Microsoft SQL Server では、クライアント サブスクリプションおよびサーバー サブスクリプションは、それぞれ、ローカル サブスクリプション、グローバル サブスクリプションと呼ばれていました)。

優先度値 (0.00 ～ 99.99) を割り当てたサブスクリプションをサーバー サブスクリプション、パブリッシャの優先度値を使用するサブスクリプションをクライアント サブスクリプションと呼んでいます。また、サーバー サブスクリプションを使用するサブスクライバは、別のサブスクライバにデータを再パブリッシュできます。次の表に、各サブスクライバの種類の主な相違点と使用法をまとめます。

クライアント サブスクリプションで行が変更された場合、サブスクリプションが同期されるまで、優先度は変更に割り当てられません。同期中には、サブスクライバからの変更にパブリッシャの優先度が割り当てられ、その後の同期でもその優先度が保持されます。ある程度までは、パブリッシャに変更の所有権があると言えます。この動作では、最初のサブスクライバがパブリッシャと同期し、その後の行または列に対する別のサブスクライバとの競合で優先されるようにすることを許可します。

サーバー サブスクリプションで行を変更する場合、サブスクリプションの優先度はその変更のメタデータに格納されます。この優先度値は、他のサブスクライバの変更とマージされるときに、変更された行と共に伝達されます。これによって、優先度の高いサブスクリプションによる変更が、その後の優先度の低いサブスクリプションによる変更に上書きされることを防ぐことができます。

サブスクリプションは、そのパブリッシャより高い明示的な優先度値を持つことはできません。マージ レプリケーション トポロジの最上位レベルのパブリッシャは、常に明示的な優先度値 100.00 を持ちます。このパブリケーションへのすべてのサブスクリプションは、この値より低い優先度値を持つ必要があります。再パブリッシュ トポロジには、以下の注意点があります。

• サブスクライバがデータを再パブリッシュする場合、サブスクリプションは、サブスクライバの上位のパブリッシャより低い優先度値のサーバー サブスクリプションである必要があります。

• サブスクライバが再パブリッシュ ツリーのリーフ レベルのためデータを再パブリッシュしない場合、サブスクリプションは、クライアント サブスクリプションである必要があります。

サーバー サブスクリプションと優先度の詳細については、「サブスクリプションの種類と割り当てられた優先度に基づくマージ競合解決の例」を参照してください。

競合通知の遅延

データ変更が競合と見なされるかどうかは、アーティクルに対して設定した競合の追跡の種類 (行レベル、列レベル、または論理レコード レベル) に依存します。論理レコード レベルの追跡の詳細については、「論理レコードの競合の検出および解決」を参照してください。

競合を行レベルで認識する場合、対応する行が変更されると、その変更が行内の同じ列に加えられたかどうかにかかわらず競合と判断されます。たとえば、パブリッシャ行の住所列が変更され、同じテーブルの対応するサブスクライバ行の電話番号列が変更されたとします。行レベルの追跡では、同じ行が変更されたため、競合が検出されます。列レベルの追跡では、同じ行で異なる列が変更されたため、競合は検出されません。

行レベルおよび列レベルの追跡では、競合の解決方法は同じです。データの行全体が、競合で優先されたデータにより上書きされます (論理レコード レベルの追跡では、解決方法はアーティクル プロパティ logical_record_level_conflict_resolution に依存します)。

通常、アプリケーションのセマンティクスによって、使用する追跡オプションが決まります。たとえば、住所と電話番号のように、通常は同時に入力する顧客データを更新している場合、行レベルの追跡を選択する必要があります。この場合、列レベルの追跡が選択されると、ある場所からの顧客の住所への変更と、別の場所からの同じ顧客の電話番号への変更は、競合として検出されません。同期の際にデータがマージされ、エラーは見逃されます。その他の場合では、各所のサイトから個々の列を更新するのが最も適切という場合もあります。たとえば、2 つのサイトが、収入レベルとクレジット カードによる合計購入額のような、異なる種類の顧客統計情報にアクセスできる場合があります。列レベルの追跡を選択すると、両サイトは不要な競合を避け、異なる列に対して統計データを入力できます。

注
アプリケーションで列レベルの追跡が必要ない場合は、行レベルの追跡 (既定) の使用をお勧めします。これは一般的に、行レベルの追跡の方が高い同期パフォーマンスが得られるためです。行レベルの追跡を使用すると、ベース テーブルには最大 1,024 列格納することができますが、パブリッシュ対象は最大 246 列なので、それに合わせて列をアーティクルからフィルタで選択する必要があります。列レベルの追跡を使用する場合、ベース テーブルには最大 246 列格納することができます。

マージ エージェントは、あるノードでの行 (または、列や論理レコード) に対する更新が、別のノードでの同じ行に対する別の更新と競合する場合に、更新 - 更新の競合を検出します。この場合、既定の競合回避モジュールは、優先された行を優先されなかったノードに送信し、アーティクルの競合テーブルに優先されなかった行のログを記録します。

マージ エージェントは、あるノードでのデータの更新が別のノードでの削除と競合する場合に、更新 - 削除の競合を検出します。この場合、マージ エージェントは行を更新しますが、マージ エージェントが更新先で行を検索すると、行は削除されているため見つかりません。優先されたノードが行を更新したノードの場合、優先されなかったノードでの削除は破棄され、マージ エージェントは競合で優先されなかったノードに新しく更新された行を送信します。マージ エージェントは、優先されなかった行の情報を、MSmerge_conflicts_info テーブルにログ記録します。

マージ エージェントは、特定の変更を適用できない場合にこれらの競合を発生させます。これは通常、パブリッシャとサブスクライバ間での制約定義、および制約の NOT FOR REPLICATION (NFR) プロパティの使用状況の違いにより発生します。たとえば、以下のような場合があります。

• サブスクライバでの外部キーの競合。これはサブスクライバ側の制約が NFR とマークされていないときに発生する可能性があります。

• パブリッシャとサブスクライバ間での制約が異なり、それらの制約が NFR とマークされていない場合。

• サブスクライバで従属オブジェクトが利用できない場合。たとえば、ビューが従属するテーブルではなく、ビューをパブリッシュする場合、サブスクライバでそのビューから挿入を試みるとエラーが発生します。

• 主キーと外部キーの制約に一致しないパブリケーションの結合フィルタ ロジック。SQL Server のリレーショナル エンジンが制約を受け入れようとする一方、マージ エージェントがアーティクル間の結合フィルタ定義を受け入れようとする場合に、競合が発生します。マージ エージェントは、テーブル レベルの制約のために変更先のノードで変更を適用できず、競合が発生します。

• 一意のインデックスまたは一意の制約の違反、または主キー違反が原因の競合が、アーティクルに対して ID 列が定義され、自動 ID 管理が使用されていない場合に発生する可能性があります。2 つのサブスクライバが新しく挿入された行に対して同じ ID 値を使用するのであれば、これは問題となる場合があります。ID 範囲の管理の詳細については、「ID 列のレプリケート」を参照してください。

• トリガ ロジックにより、マージ エージェントが挿入先のテーブルに行を挿入できない競合。サブスクライバで定義される更新トリガを検討します。トリガは NFR としてマークされず、そのロジックには ROLLBACK が含まれています。エラーが発生すると、トリガはトランザクションの ROLLBACK を発行します。これにより、マージ エージェントは失敗した変更の競合を検出します。