best practice for DB recovery

Hi,

I'm trying to come up with the best approach for supporting some kind of hot standby for my master DB.

Basically, I have the master DB running with recording and recovery enabled and have a number of applications connecting to it. I realize that I'm able to stand up read only replications and add them to my persistence unit but being able to read and not write is a condition that can't last for more than a few minutes and have to be fixed promptly. So it comes down to how can I have a hot standby server that is a replica of the master server and then be able to switch my applications to use the standby in case the master is not available.

One way of dealing with that is to simply have two(or more) entity managers in my DAO layer and write all changes to both instances(may have IDs synchronization issues), if one of the instances is not available, I'll keep writing to the instance that works and have some notification that will tell me that one instance is down. Now the way to recover from a failed instance would be to simply stop all writing, take a backup from the working instance(that will make sure all transactions are committed) and then copy the backup to the failed instance, restart the failed instance and then enable writes again(that will be controlled in the DAO layer).

Would something like this work or even feasible with objectdb or is there a more standard way for doing this?

In addition, what is objectdb approach/roadmap regarding the support of hot standby DBs as the main difficulty with using objectdb in a production environment is the fact that it doesn't support hot standby out of the box.

Thanks,

Eitan

Eventually ObjectDB should support switching a slave server to a master, allowing write operations. But this involves some challenges. See also a previous forum thread that discussed this.

You may implement your own solution in your DAO layer but it may be affected by similar technical challenges.

But instead of writing everything using two EntityManager instances you can use the ObjectDB master slave replication, and when the master fails, switch your web application to the slave (not by using a dual url, but by using only the master url and when it fails switching to the slave url by your DAO layer).

If after reading the other thread you have a clear picture of how you think ObjectDB should handle this - please create a feature request.

Hi,

When you say "switch your web application to the slave", do you mean that we can just start writing to the slave DB? My understanding from the documentation is that when a DB is started in slave mode it is read-only. So, in this scenario we would have to restart the slave DB in master mode, is that correct? Or is there a way to start writing to the replica DB without restart?

We need to ensure that we don't have unplanned outages, so we need some ability to switch to the second DB without stopping the application. We can pause it for a short while when we switch back as this would be a planned outage. Do you have any solution to support this requirement? 

Thanks,

Natalia.

> So, in this scenario we would have to restart the slave DB in master mode, is that correct?

That is correct, currently this is not automatic.

Fill a detailed feature request if you have a clear picture of how you think ObjectDB should handle this.