0

約 80 件の記事でさまざまなレプリケーション方法を使用するマージ パブリケーションがあります (1 つのテーブルで host_name フィルタリング、他のいくつかのテーブルで結合フィルタリング、双方向同期方向を使用するテーブル、「ダウンロードのみ、サブスクライバーの変更を禁止する」テーブル、いくつかのテーブルID 範囲管理を使用するテーブル、それを必要としない他のテーブル)。

必要なすべてのテーブルが既にあるサブスクライバー データベースにプッシュ レプリケーションを使用しているため、「名前が使用中の場合のアクション」には「データの削除」を使用しています。テーブルは、サブスクライバー データベースとパブリケーション データベースの両方で同一のスキーマを持ちますが、レプリケーションが開始されるまでは空です。

問題は、サブスクリプションの初期化に 3 分ほどかかる場合もあれば、同じようにテンプレート化されたサブスクライバー データベースと同じ開始データセット (~10,000 レコード) を使用して、~20 分後にタイムアウトになることもあります。また、初期化後、同期するときに、約 5 秒かかる代わりに、約 20 分かかります。また、レプリケーション モニターの履歴を見ると、同期履歴には、何千回ものスキーマ変更が行われていることが示されています (データの変更がない場合でも)。

詳細ログを有効にしてスキーマの変更内容を確認しましたが、すべてのテーブルを繰り返しループし、すべての制約をオフにしてから再びオンにしているようです。なぜこれをしているのか、私は途方に暮れています。

関連する場合に注意してください: 100 文字の Unicode 文字列 (文字の完全な Unicode 範囲からランダムに作成された) を、異なるサブスクライバーの host_name として使用しています。これが問題の原因ではないかと疑っていましたが、50 文字の小文字の文字列を使用して問題を再現しました。

最後に、すべてのサーバーが同じデータ センターでホストされているため、ネットワークの遅延が問題になることはないと思います。

4

2 に答える 2

0

誰かがこれに遭遇した場合の解決策は次のとおりです。

新しい「サブスクライバー」をプロビジョニングしたときに、そのサブスクライバーのテーブルに新しいデータ セットを作成しました (デフォルトに基づく)。ただし、このデータの新しいコピーを作成する際にはショートカットを使用しました。すべての制約をオフにしてから、select..insert を実行し、制約をオンに戻しました。これは、多数の制約を持つ多数のテーブルがあり、右側の各テーブルを調べる必要がなかったためです (さらに、完全性の高いデータを追加することはわかっていました)。

問題は、すべての制約をオフにしてからオンに戻すと、マージ レプリケーションによって 2 つのスキーマ変更として記録されることです。(「なし」ではなく)。そのため、サブスクライバーを追加するたびに、大量のスキーマ変更を作成しました。そして次にサブスクライバーが同期するとき、これらすべての無意味な制約のオン/オフを送信する必要がありました。

ショートカットの詳細により、実際には、新しいサブスクライバーごとにこのようなスキーマ変更が 2 つ以上追加されました。そのため、サブスクライバーがしばらく同期しないと、何千もの新しいスキーマ変更が発生することになります。

また、スナップショットを更新しない限り、新しいサブスクライバーは作成されるとすぐにスキーマが古くなってしまうため、新しいサブスクリプションがタイムアウトになるまでに時間がかかりました。

解決策: 「ショートカット」を削除し、制約に触れずにデータを正しい順序でコピーします。それ以上の問題はありません。

于 2014-02-10T22:17:00.857 に答える
-1

マージ レプリケーションの場合。質問は次のとおりです。パブリッシャーとサブスクライバーのデータベースはまったく同じですか? つまり、スナップショットを転送するには、ftp の代わりにネットワーク共有が必要ですか?

于 2013-12-23T13:32:03.610 に答える