db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Lawrenson <andrew.lawren...@coppereye.com>
Subject Replication - switching back after failover
Date Mon, 13 Oct 2008 08:26:51 GMT
Hi again,

    I'm using Derby Replication at the moment (with, and I'm after some advice on
how to "fail back" after a fail-over has occurred.

The scenario I'm looking at is having a Primary Server, which is normally the database master,
and a Secondary Server, in a different location, which is the slave.

If the primary fails, it will all switch over to the Secondary ok.  What I'm wondering about
is the best way to switch back to the original setup, of the Primary being the Master &
the Secondary being the Slave again.  As I understand it, Derby does nothing automatic do
to this - I have to do it myself.    I can do this fine, but I need to try & minimise
any downtime when the system is not available - and as the servers are in different locations,
there is only limited bandwidth between the two, so copying the database back & forth
may take some time.

So, the easiest way to do this is to stop both databases, copy the database from the secondary
to the primary, then restart the replication.  However, this would require copying the database
over the network twice whilst the system is down (once to transfer from slave to master, and
again when starting replication).

I can improve on this by backing-up the secondary, transferring over the network to the primary,
then shutting down the two, copying the transaction logs since the backup from the seconday
to the primary, the doing a restore, then restarting replication.  This will only require
only one big copy over the network whilst the servers are unavailable.

However, main query is regarding the need to copy the database from the master to the slave
when starting replication.  The docs state:

"Before you start replication, you must boot the master database and then copy the database
to the slave location. To ensure that the master database is not modified between the time
you start the file-system copy and the time you start replication, you must freeze the master

In this scenario, where you've just copied the slave to the master, to copy it back again
seems a little excessive - is there any way to "streamline" this, if you know that the two
databases are the same? (e.g. just copying the logs, but not the main database files).  If
something is possible, does it make any difference whether you do a straight binary copy of
the slave database, versus doing a restore? (which should create a logically identical database,
but may not be the same exact binary files).

many thanks in advance for any advice,

Andrew Lawrenson

View raw message