db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <Knut.Hat...@Sun.COM>
Subject Re: Replication - switching back after failover
Date Mon, 13 Oct 2008 22:10:39 GMT
Andrew Lawrenson <andrew.lawrenson@coppereye.com> writes:

> 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 database..."
> 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).

I don't know not enough about Derby's replication to say for sure that
this is guaranteed to work, but at least it appears to work:

1) Do a clean shutdown of the database at the slave (open a connection
with URL 'jdbc:derby:mydb;shutdown=true')

2) Copy the database back to the master

3) Boot the database at the slave with startSlave=true

4) Boot the database at the master with startMaster=true

This appears to work in my environment, and I think it should work in
general because the clean shutdown in step (1) ensures that there is no
log to process in the recovery phase of the boot so that the master and
the slave will be in sync when the master starts shipping the log.

Hopefully, someone who knows more about the implementation can tell
whether this is supposed to be safe or not.

Knut Anders

View raw message