在对特定生产问题进行故障排除时,我们在客户端网站上点击了Microsoft Sync Framework ...
我们有一个中央服务器作为记录的数据系统,它公开了一个WCF服务,我们使用Sync Framework 2.0将数据与断开连接的客户端实例同步。 (实现的许多细节都是未知的,它是一个继承的代码库。)在过去的某个时刻对用户机器上的问题进行故障排除时,决定消灭特定的客户端& #39;本地数据库,并用另一个客户端的已知好副本替换它。
一切似乎工作了一段时间。但是实施中有一个细节,当时我们都不知道。 Sync内部跟踪客户端数据库标识。这意味着服务器无法区分这两个客户端。因此,人们会同步他们的数据,然后另一个人将处于未知状态。
我们已确定受影响的用户,我们正在识别受影响的数据,并且我们正在集思广益,寻找潜在的解决方案。对于后一部分,我想知道这里是否有人对Sync Framework有任何经验,并且可以建议一个潜在的行动方案?
我们正在考虑的一种潜在方法是确定Sync内部跟踪该身份的位置和方式(可能是某处的GUID?)并进行更改。这听起来像是最快的解决方案,但至少仍然需要再次触摸受影响的记录以触发它们再次同步。
我们不想冒失去数据的风险,因此我们不愿意放弃客户端数据库并重新配置。但更重要的是,配置新数据库的过程对当前设置中的资源和用户停机造成了重大打击,因此如果可能的话,应该避免这样做。
这里有人有使用Sync Framework的经验吗?以前有人遇到过这个问题吗?您会建议采用哪种方法?
答案 0 :(得分:1)
您的想法听起来不错,但至少要了解所涉及的风险,您需要确保继承的代码库不包含任何“意外”...请提供更多信息:
编辑 - 根据评论:
我不是百分百肯定 - 请先在一个客户端上先刷一下并验证结果!
首先替换客户端上的客户端GUID ,该客户端已经意外获得了其他客户端的副本(否则“正常工作”会搞砸!)。
然后为此客户端db调用PerformPostRestoreFixup
有关详细信息,请参见
http://msdn.microsoft.com/en-us/library/ee617375.aspx
http://msdn.microsoft.com/en-us/library/bb726041.aspx
答案 1 :(得分:0)
不幸的是,它不仅仅是在范围表上替换Guids的问题。
如果您的客户端使用SqlServer或SqlExpress,则可以运行PerformPostRestoreFixup,Sync Framework将为您调整客户端ID和副本密钥映射。
下次使用其他客户端的备份初始化客户端时,请确保在还原的副本上运行PerformPostRestoreFixup。
在您的客户端可能已经不同步的情况下,您可能需要在PerformPostRestoreFixup之后进行一些验证