Darren Duke recently wrote an article about DAOS optimization in Domino 8.5.1 and replication. In his article he says that there is no advantage when creating a new replica.
I tested today and here are my findings. I use a Domino cluster with 2 servers running Domino 8.5.1.
When you create a new copy using the admin client then an “accelerated create replica” request is created in admin4.nsf. In this case that won’t take advantage of DAOS exploitation as that is basically just an OS copy of the file.
But the DAOS team did a great job. When the source server determines that the target server is DAOS enabled, then adminp creates a normal replica creation request. Now only those attachments that do not already exist as .NLO files on the target server are transfered to the target. If an attachment already exists on the target server, only the ticket is replicated.
I did some more research and found a technote about “When is the AdminP “Accelerated Create Replica” feature used?”
And here I found a possible cause for the behaviour Darren mentioned in his article.
You can force to always use “accelerated create replica” by setting the following parameter in the notes.ini of the source server.
ADMINP_ACCELERATED_REPLICA_OVERRIDE=4
Pls. review your notes.ini settings to take the full advantage of DAOS optimization features in the upcoming 8.5.1 release of Lozus Notes / Domino. I will also send this as a new rule proposal to the DCT team.
We currently are not using DAOS yet. We might not be able to. Currently my mail server shuts down nightly for backup. We are moving to a model that we will replicate our mail files to another server and have that server shut down for backup. If we use DAOS on both with the NLO files use the same reference files? The reason I am asking is how would I deal with backup restores. Since the backups will come from backup server and not the live server. If the NLO have different numbers then I won’t be able to use DAOS.
If you know anything about this I would appreciate your input.
as far as I know the NLOs do reference the same file. BUT the files are encrypted with the server ID by default, so a file from the DAOS store works only on the original server.
So, when restoring a backup, you would need to restore to the backup server since that’s the origin of the backup. If you would restore DAOS repository files to the other server, it would not be able to use them.
Each server has its own DAOS repository, so there is no cross-server dependency. If you use a designated back up server and restore to that same server things will work as expected. If you want to be able to restore NLO’s to any server you should not use DAOS encryption by setting DAOS_ENCRYPT_NLO=0. This will mean that you need to control access to the DAOS repository (but you already do that for NSF files right ???) But you really DO want use DAOS on the designated server because (1) you can do incremental backups of DAOS and (2) in 8.51 replication is DAOS aware and will not send objects that already exist on the target server
So it’s great to see DAOS recognize the other server has DAOS enabled and flag it in 8.5.1, but what about turning on the DAOS flag on the new replica today in 8.5. Can it be done automagically? I’m able to catch some mail files when I create a request, but it’s not an easy process and if I don’t catch it, I have to compact -c the application on the new server to get the attachments into DAOS.
>> I have to compact -c the application on the new server to get the attachments into DAOS
This is the only way, it can be done.