如果读者访问权限被撤销，在服务器到服务器复制期间会发生什么
我想了解以下 Lotus-Domino 服务器到服务器复制场景中会发生什么：
- 服务器 A 有 A 数据库的副本。
- 服务器 B 具有同一数据库的副本。
- 两台服务器都具有数据库的管理员访问权限，包括删除文档权限。
- 复制器进程刚刚复制了 A 和 B，并且所有内容都是同步的。
- 该数据库包含一个注释，其中有一个读者字段，其中提到了这两个服务器。
- 在服务器 A 上，服务器 B 的条目已从读者字段中删除。
- 服务器 A 启动与 B 的复制。
在这种情况下，我希望服务器 A 将从服务器 B 中删除文档。该情况有多种变化，服务器 C 与 B 进行复制，B 启动与 A 的复制。
我有一个应用程序是围绕这个期望构建，并且在大多数情况下都效果良好。但有一些注释保留在服务器 B 上并且被排除在复制过程之外。 OID 仍然不同。在某些情况下，两个笔记上的 DSN 都已更新，但在复制过程中却没有任何结果。
I would like to understand what happens in the following Lotus-Domino server to server replication scenario:
- Server A has a replica of A database.
- Server B has a replica of the same database.
- Both servers have manager access on the database, including the delete document privilege.
- The replicator process has just replicated A and B and all is in sync.
- The database contains a note that has a reader field where both servers are mentioned.
- On server A the entry for server B is removed from the readers field.
- Server A initiates the replication with B.
In this scenario I expect that server A will remove the document from server B. There are variations on the scenario, server C replicating with B, B initiating the replication with A.
I have an application that is build around this expectation, and it has worked well most of the time. But there are notes that remain on server B and are excluded from the replication process. The OID remains different. There are instances where the DSN is updated on both notes without any result in the replication process.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
事实上，我不同意AndrewB的回答。根据我的经验，它应该按照您的期望工作。使用 readernames 字段来控制复制已经成为我标准武器库的一部分超过 15 年了，我发现它比选择性复制的替代方案可靠得多——选择性复制是邪恶的，应该不惜一切代价避免，但那是另一个故事了！
确实，一旦 readernames 字段不再包含 serverB 的条目，则注释本身对于 serverB 是不可见的，但注释已更改这一事实对于复制器来说并不是不可见的。复制器应该注意到这一点，确定 serverB 不再拥有该文档的权限，并将其删除——不留下存根。
您是否尝试过清除双方的复制历史记录？
Actually, I disagree with AndrewB's answer. In my experience, it should work as per your expectations. Using readernames fields to control replication has been part of my standard arsenal for 15+ years, and I have found it far more reliable than the alternative of selective replication -- which is evil and should be avoided at all costs, but that's another story!
It is true that once the readernames field no longer contains the entry for serverB the note itself is invisible to serverB, but the fact that the note has changed is not invisible to the replicator. The replicator should notice this, determine that serverB no longer has rights to the document, and remove it -- without leaving a stub.
Have you tried clearing the replication history on both sides?
这是一个很容易陷入的陷阱，您不应该使用 Reader 字段来控制服务器之间的复制，它们非常适合控制用户和组，但复制组中的所有服务器都应该始终有权访问所有内容。
文档留在服务器 B 上/未更新的原因是，从文档的阅读器字段中删除服务器 B 使其对服务器不可见，因此它不知道它已更改或已删除。服务器 A 上的删除被服务器 B 拾取的原因是，删除将文档转换为删除存根，该存根仅比 UNID 大一点，因此读者字段也会使删除对服务器 B “可见”。甚至强制服务器 A 写入服务器 B，因为服务器 A 知道服务器 B 不允许查看该文档，因此推送复制将忽略相关文档。
This is an easy trap to fall into, you should not use Reader fields to control replication between servers, they are fantastic to control users and groups but all servers in a replication group should always have access to everything.
The reason the documents are left/not updated on server B is that removal of the server B from reader field on the document makes it invisible to the server hence it has no idea that it has changed, or been deleted. The reason that the deletion on server A was picked up by server B is that deletion converts the document into a deletion stub which is little more than the UNID so readers field also go making the deletion 'visible' to server B. You can't even force server A to write to server B because server A will know that server B isn't allowed to see the document so a push replication will ignore the document in question.
IBM 为此创建了一个 SPR：
IBM has created an SPR for this:
我们在整合服务器时发生过类似的事情，但效果并不好。如果我使用您的服务器 A/服务器 B 场景，我们所发生的情况是服务器 B 与服务器 A 进行了复制，并且文档从服务器 B 中消失了。不幸的是，这被跟踪为删除，因此当 A 和 B 再次复制时，文档随后从服务器中删除答：
幸运的是我们有备份。
We had something like this happen when we were consolidating servers and it didn't work out very well for us. If I use your server A/server B scenario what happened for us was Server B replicated with Server A and the document disappeared from Server B. Unfortunately this was tracked as a deletion so when A and B replicated again the documents were then removed from server A.
Luckily we had backups.