What happens during Server to server replication if reader access is revoked

Question

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.

Whaling

Great question. You might want to also post this on ServerFault. – Lakendra

This process should "just work". But even in the straightforward scenario described above I see notes not replicating. With the C-API I have built an application to find these notes. The concept is great, I use it to distribute subsets of data to different sites, based on the readers fields. – Whaling

Far better to use ACL Role or ACL group based selective replication. The replication process has been in notes since the very beginning and is incredibly powerful if used properly but you need to understand the security model which is unlike anything else I've ever come across. – Tetrafluoroethylene

The main reason to as this question was to get a better insight in the flaws & risks of this solution. I Understand your points but I hope to get some answers on the reason not to use this approach. Selective replication could work, I doubt if it is actually easier to implement. In my scenario the server represents a site and this site does not have access to certain documents. Access to documents on that level still spells readers fields to me. – Whaling

Answer 1

IBM has created an SPR for this:

Problem Normally, when a server is removed from the reader field of a document, after scheduled replication takes place, the document is deleted from the server since that server no longer has access to the document. In some cases, when a secondary server is removed from the reader field of a document residing on a primary server, after replication occurs between the two servers, the document is not deleted from the secondary server as is expected. Enabling replication debug reveals the following error on the source server: "You are not authorized to perform that operation". Clearing the replication history and initiating replication from both servers does not resolve the problem. Upon further investigation, it was determined that the document on the secondary server had a higher sequence number which implies that it was updated more recently than the document on the primary server. Normally, when a document does not contain a reader field or if both servers involved in the 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 takes place. However, in this particular situation, since the secondary server does not have access to the document on the primary server, replication fails as is expected and a replication conflict is not generated because in order for a conflict document to be generated, both servers need to have access to the document.

Resolving the problem 1.) A short term solution would be to modify the document on the primary server so that its sequence number is higher than document on the secondary server. After replication takes place, the changes should replicate to the secondary server and the document should be deleted from the secondary server as is expected. 2.) A more permanent solution would be to prevent users and servers from making changes to the document on both servers at around the same time. Also, replicating more often should help reduce the chances of such a condition from occurring since changes made on one server will possibly replicate out before changes are also made on the other server. This issue issue is being tracked under SPR MKHS8MLQVD

Whaling

Answer 2

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?

Apparition

Answer 3

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.

Tetrafluoroethylene

What about local replica's? If the server B is a Lotus client instead of a server that replicates a local replica, should that work fine? Do you have any documentation that supports why readers fields should not be used to control the replication between servers? – Whaling

Readers fields containing groups names or ACL roles are an excellent way to control what gets replicated to the Lotus notes client, the process is identical however in terms of the way replication works. I don't have documentation, just ten years of experience. If you want to have a subset of documents on satellite servers then use selective replication, its transparent and much easier to both document and change without risk of data loss. – Tetrafluoroethylene

Answer 4

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.

Especially

Replication should nog result in a deletion(stub). Do You have an idea why this was tracked as a deletion? The only deletion I would expect is a purge, without leaving a deletion stub. – Whaling

Its possible that the document disappeared because of replication conflicts. If you delete the main document you won't automatically see the conflict document, if you can see a document on one server but can't see it on another then look for replication conflicts, it needs a special view but its easy to resolve them and although annoying they have saved my bacon on many occasions as they are automatically created to prevent loss of potentially valuable data. – Tetrafluoroethylene