Hi again,
 
    I'm using Derby Replication at the moment (with 4.3.2.0), 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).
 
many thanks in advance for any advice,
 
Andrew Lawrenson