What happens during server and server replication if reader access is denied

Question

I would like to understand what happens in the following Lotus-Domino server replication server script:

• Server A has a replica of database A.
• Server B has a replica of the same database.
• Both servers have manager access to the database, including the privilege of deleting a document.
• The replicator process has just played A and B, and everything is in sync.
• The database contains a note in which there is a reader field in which both servers are mentioned.
• On server A, the entry for server B is removed from the read field.
• Server A initiates replication using B.

In this case, I expect server A to delete the document from server B. There are variations in the scenario, server C replicates from B, B, initiating replication with A.

I have an application that builds on this expectation, and it works great most of the time. But there are notes that remain on server B and are excluded from the replication process. OID remains different. There are cases where the DSN is updated in both notes without any results during the replication process.

Answer 1

IBM created the SPR for this:

Problem Typically, when a server is removed from the document reader field, after scheduled replication, the document is deleted from the server because that server no longer has access to the document. In some cases, when the secondary server is removed from the field of the document reader located on the primary server, replication occurs between the two servers, the document is not expected to be deleted from the secondary server. Enabling debug replication shows the following error on the source server: "You are not allowed to perform this operation." Clearing replication history and initiating replication from both servers do not resolve the issue. Further investigation revealed that the document on the secondary server had a higher serial number, which implies that it was updated more recently than the document on the primary server. Typically, when a document does not contain a reader, or if both servers involved in replication are listed in the reader field of both copies of the document, a replication conflict will be generated when the document is modified on both servers before replication occurs. However, in this specific situation, since the secondary server does not have access to the document on the primary server, replication is not performed, as expected, and replication is not created because, in order to be created, both servers must have access to the document.

Solution 1.) A short-term solution would be to change the document on the primary server so that its serial number is higher than the document on the secondary server. After replication occurs, the change must be replicated to the secondary server, and the document should be expected to be deleted from the secondary server. 2.) A more permanent solution will be to ensure that users and servers do not make changes to the document on both servers at approximately the same time. In addition, replication more often should help reduce the chances that such a condition arises, since changes made on one server will probably be repeated before changes are made on the other side of the server. This issue is fixed in SPR MKHS8MLQVD

Answer 2

This is an easy trap you can fall into, you should not use Reader fields to manage replication between servers, they are fantastic for managing users and groups, but all servers in a replication group should always have access to everything.

The reason the documents were left / not updated on server B is because deleting server B from the reader field in the document makes it invisible to the server, so it does not know that it has changed or has been deleted. The reason the deletion on server A was chosen by server B is because the deletion converts the document to a deletion stub, which is slightly larger than the UNID, so the reader field also makes the deletion “visible” on server B. You cannot even force server A write to server B because server A will know that server B is not allowed to see the document, so push replication will ignore the document in question.

Answer 3

Actually, I do not agree with AndrewB's answer. In my experience, it should work according to your expectations. Using the readernames fields to manage replication has been part of my standard arsenal for 15 years, and I found it much more reliable than the selective replication alternative - it is evil and should be avoided at all costs, but it's a different story!

It is true that once the readernames field no longer contains an entry for server B, the note itself is invisible to server B, but the fact that the note has changed is not invisible to the replicator. The replicator should notice this, determine that the server server no longer has rights to the document and delete it - without leaving a stub.

Have you tried to clear the replication history on both sides?

Answer 4

We had something similar when we consolidated the servers, and for us it did not work. If I use your server script A / server B, it happened for us that server B is replicated on server A and the document disappeared from server B. Unfortunately, this was tracked as deletion, so when A and B were replicated again, the documents were deleted from server a.

Fortunately, we had backups.