Currently there is no way to determine in real time when replication/save conflicts occur. I would like to have the following:
1) An event that gets triggered at the database level so we can resolve these in real time.
2) Some way to determine which fields triggered the conflict....
I'd like to see the replication history (the one that you get when you right-click a DB icon-> replication -> history) either:
Contain more information such as the info that you'd see in the log.nsf about doc's added/deleted/updated, the time it took, and the amount of data
Contain a link ...
Once in a while we will have an old replica push in records that were long ago deleted, and it creates havoc. There are just too many of them in the field to know for sure who has one that hasn't replicated all year.
I would like an option ...
If a database replicates after being isolated for a long time, it can bring back documents that were deleted if the deletion stub has been purged. There should be a setting that prevents replication of a replica that has not replicated within the purge interval. Example:
Someone with ...
We currently have:
- scheduled replication
- cluster (streaming) replication
I would like to see the following additions/variations:
- "On Change PUSH replication". When a document gets save this one document is pushed to the databases specified for that server. This would be like a "lazy cluster" without failover or ...
When DAOS-enabled Domino servers call each other for mail sending or replication, they can transfer file references first, and not transfer the file if it’s already stored in the target server's DAOS.
- We have two DAOS-enabled Domino 8.5 servers: "ServerA" and "ServerB".
- There are ...
In the Replication Events section of log.nsf it is flooded with entries of DDM doing the data roll-up every minute. Generally there is nothing in these documents anyway. It makes it very hard when checking the normal scheduled replication events.
Can it either be removed and put in it's own ...
Right now there is NO way to use an API or exposed program method to write an agent which will check or uncheck the replication advanced options which would prevent design and form updates.
This is useful when doing a slow progressive migration or upgrade from r5 to r7 in ...
Replication & Clustered replication are fantastic and rather unique technologies which appear to be about 95% there.
What is still lacking is consistency. Databases 'get out of sync'. The semi-official remedy is to *reactively * perform manual tasks such as clearing replication history and re-creating replicas. These measures are uncharacteristic of ...