我有一个发布者数据库A，我有两个订阅A的订阅者数据库B和C.我的应用程序驻留在站点B和C本地，通过复制，B和/或C的更改互相复制。
问题是自2019年1月31日以来C停止订阅A并且C站点的IT人员不知道它（没有警报）。
更大的问题是，在此期间，在B处使用应用程序的人员已经输入了复制回A的数据。同时，站点C的人员一直在向数据库C添加数据，而数据库C没有复制回来。
如果我恢复订阅，它将获取A处的数据并覆盖C，这是一个主要问题，因为我将失去在此期间在C处添加的数据。由于这是健康数据，它全部加密并以xml格式存储，它是并不像更新丢失的数据那么简单，因为某些文件在站点B和C之间共享，这意味着他们会将数据添加到保存的xml树中。
例如，如果有人在B站点看到患者并输入了一个注释，则会更新一个文件。但是，如果同一位患者在下周进入C站点，那里的护士将更新在B处更新的同一文件。
我不知道如何在恢复新订阅之前先同步回复在C上进行的更新。
如果有人有任何建议，将不胜感激，谢谢！
我们多年来一直在使用合并复制，有时（例如在DB更新之后）它确实打破了奇怪的错误，无论我们尝试什么都无法修复。在所有这些情况下，唯一有效的解决方案是重新初始化订阅，甚至删除和重新创建所有订阅的出版物。
但是由于它是合并复制的情况并且在同步未发生时在所有端（即发布者和所有订阅者）添加新数据，我们不能简单地重新初始化订阅，因为您已经指出在失败的订阅者端生成的未同步数据会迷路。您的情况更加困难，因为您使用加密和XML文件来存储数据。您是否将加密的XML存储为DB中的BLOB / CLOB？
但是，我会提供多次为我们工作的解决方案。因此，如果合并复制的一个或多个端点失败，则必须执行以下步骤：
Action if name is in use属性设置为保持所有文章的现有对象不变。在执行步骤＃2并且重新初始化订阅复制代理仍然需要时间来处理现有记录（并且根据数据集大小，可能需要相当长的时间，所以考虑将日期过滤器添加到文章中）但它不会更改任何数据如果在步骤＃1之后发布者和订阅者数据库完全同步，则不会发生删除或插入。代理将仅将处理的现有记录标记为在将来运行期间跳过它们，因此您将只看到Replication Monitor上的更新命令计数增加。订阅重新初始化后，您应该没问题，任何一方生成的新数据都会同步。
您的情况很难，因为您无法轻松地从步骤1执行手动数据同步。但这是先决条件，你需要考虑如何做到这一点。您没有提供有关如何实际存储加密数据的详细信息，因此我无法建议详细计划，但您需要手动解密现有XML记录，插入缺失部分然后再次加密并确保加密列完全相同两侧。
希望这可以帮助您解决问题。
PS。无论如何，我既不是红门也不是微软。