Master is very Slow, Because Slave Takes 20 minutes for "startup done"

Question

I have two db env to be backup for each other. I stopped one db env for 5 minutes, then restarted it. I found that it took over 20 minutes to receive the db callback event "startup done". During these time, there were transactions in the master db env. I guess this makes the sync_up process take so long time.
I used the ack policy "DB_REPMGR_ACKS_ONE_PEER" and used "txn no sync" flag for transaction, so during these 25 minutes, master is very slow.
My requirement is master can resume its performance as soon as slave comes back. Can slave accept the log before its sync completed? Or any other way to solve this issue?

Answer 1

Most likely what happened is that the stopped dbenv is the only site/peer able to
send the acknowledgement. If it is stopped but not disconnected, then the master
will wait the full ACK timeout for every txn.
It is also likely that during that 5 minutes, log files were archived and when the
stopped dbenv became active again, it had to perform an internal initialization
from scratch. That copies over every page of every database and then the logs
needed to resynchronize. If you have a lot and/or very large database files,
that can take a long time.
The client cannot send any acks until it completes its synchronization. One
way to avoid this would be to perform a manual hot backup to the client before
starting up the application. You would have to copy over all database files, then
all log files from the master (in that order) and then run catastrophic recovery
in that client directory. Then start up your application and the client should be
able to quickly synchronize.
You can control this in the application by setting DB_REP_CONF_NOAUTOINIT
to DB_ENV->rep_set_config. You'll get back an error that tells you that the site
needs an re-initialization and you can do that copying then.
Sue LoVerso
Oracle