Wondering if anyone can help with our replication issue
We have 2 identical Domino 8.5 servers in a Domino clustered enviornment running on Linux (I believe its Red Hat). The servers are 01 and 02.
Our website resides on a large Notes database - the documents are updated via an internal server using a Web Content Manager (same replica).
1- Whenever new documents are posted; the document replicates up normally and then the cluster replicates the document from 01 to 02. Everything is well.
2- Whenever EXISTING documents are updated - the document replicates normally to 01 - however 50% of the time - the same document on 02 is not updated. It is as if the cluster does not recognize the document was updated and 02 never update the document.
To ‘fix’ you can ‘delete and paste’ the document within 01 and the cluster says ‘ah yes ok’ and it synchronizes fine.
This issue does seem to be intermittent - it doesn’t appear to happen on ALL documents - we have not been able to find a pattern; although we do know it does NOT happen on brand new documents.
This same problem happens in reverse also (i.e. if you update a document on 02 - it may or may not update the document on 01).
Can anyone suggest any troubleshooting steps? We are at a loss
I have seen that you can change the cluster replication method in 8.5 to an older method; perhaps this is one thing we can try.
Some things to check, (from iNotes in cluster experiences):1. If you replicate the database manually does this update the document? (I expect a No)
Check the ODS version. If it is not ODS43 (Domino 6/7) do a compact revert is possible and the increase in database size is not a problem.
This may well be due to a bug in the ODS48 and 51 where certain document modifications made in a browser are not recognised as changed by the replicator.
My comments based on iNotes restored docs from server archives are not updated by the replicator.
Solution: Revert to ODS43 or upgrade to 851fp4 or 852.
If you replicate the database manually does this update the document? You are correct it does not One awkward solution we have considered (we do it on our critcal documents) is have an agent that deletes and pastes back in the documents, effectively forcing the cluster to replicate. The UNID changes of course, but that does not matter because we assign a unique key ourselves.
Check the ODS version. If it is not ODS43 (Domino 6/7) do a compact revert is possible and the increase in database size is not a problem.
It is ODS43 running on a Domino 8 box.
Solution: Revert to ODS43 or upgrade to 851fp4 or 852.
We can look at upgrading to 8.5.2 - and upgrading our ODS to the latest and greatest. Do you think this would help?
Unfortunately, the answer is no, based on the scope of our problem. The fact that our pb was not present on ODS43 (all clustered replicas’), but defintely on ODS48 and 51 was the key element in the PMR with IBM. We received a hotfix for 851 FP2 that worked. This hotfix only made it officially into 851FP4. Have not tested it on 852.
However, the no becomes a maybe - the symptoms are the same … maybe another manifestation of same core bug? At the time, the bug/fix/regression we had was also linked to Inbox folder not being updated. (msg in all docs OK) so maybe worth a try. It was only until 851FP4 that all aspects were fixed.
One awkward solution we have considered (we do it on our critcal documents) is have an agent that deletes and pastes back in the documents, effectively forcing the cluster to replicate. The UNID changes of course, but that does not matter because we assign a unique key ourselves.