SQL Server2008レプリケーションおよび同期フレームワーク-実用的な制限
クライアントのデータを独自のシステムでホストし、MS SyncFrameworkを使用して各クライアントのサイトのSQLServerインスタンスでデータを複製することを検討しています。各クライアントには平均で約500MBのデータがあり、最大1,000のクライアントサイトが存在する可能性があるため、全体で約500GBのデータがあります。データの変更は、両方向に複製する必要があります。
この数のクライアントで分散システムを試みた人はいますか？実用的な制限はありますか？
私は、同期フレームワークを使用してSQL Express 2008を実行しているリモートサイトを同期するプロジェクトに携わってきました。一部はWANで、一部はADSLで（元々はダイヤルアップでも、3Gワイヤレスモデムにアップグレードされましたが）中央に同期しました。 SQLサーバー。
私たちは1,000までスケールアップしませんでした-おそらくそのクライアントでの私の時間の終わり近くまでに約60-80サイトだけでした。同期フレームワークは非常に信頼できることがわかりました。私たちが抱えていた唯一の問題は、SQL Serverの 変更追跡 機能を使用していたときの奇妙な動作でした。
データチェンジセットを「見逃す」ことがあることに気づきました。これを繰り返し再現できるようになったのは、ロールアウトへの公正な方法だったので、MicrosoftPSSに連絡しました。
結局、彼らは、本質的に時々SQL Change Trackingが更新を削除/挿入として報告することを確認しました。これは、同期フレームワークを完全に混乱させます。これに直面して、トリガーを使用した変更追跡の独自の実装を展開することに頼らなければなりませんでした。これは、a）実際に適切に機能し、b）変更のログ記録と監査をより細かく制御できるため、有益であることが証明されました。
このアプリケーションは、同期フレームワークのバージョン1.0を使用して作成されました。つまり、チームはクライアント側にカスタムプロバイダーを適合させる必要がありました。 v2.0には独自の SqlSyncProvider が付属しているので、心配する必要は1つ少なくなります。
考慮すべきもう1つのことは、直接SQL接続を使用するか、WCFプロバイダーのサポートを利用するかです。クライアントサイトがインターネット経由でメインサーバーにアクセスしている場合は、おそらくWCFが最適です。必要に応じて、セキュリティ/暗号化を追加できます。ある種の圧縮を含めるようにWCFトランスポート層を最適化することを検討することもできます。
Wireshark のようなものを使用して、そのパスを進んでいる場合は、ネットワークの使用状況を比較することをお勧めします。帯域幅の要件がどうなるかを事前に把握しておくことをお勧めします。
-デイブ