db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jørgen Løland <Jorgen.Lol...@Sun.COM>
Subject Re: Replication - switching back after failover
Date Tue, 14 Oct 2008 11:43:18 GMT
Knut Anders Hatlen wrote:
> Andrew Lawrenson <andrew.lawrenson@coppereye.com> writes:
>> (...)
>> 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.

Andrew, good question

Knut Anders, good solution :)

I can confirm that this should work, but like other undocumented 
replication functionality there hasn't been any real testing for it.

However, if there are cases where this does not work (nothing comes to 
mind), you will get an assert failure on the slave immediately after 
starting it if the debug build is used. Otherwise, you'll get an 
exception on the slave once the database switches to a new file and the 
slave starts redoing it (default log file size is 1MB). Hence, if 
replication starts and has not crashed after switching to a new log file 
you should be safe :)

Jørgen Løland

View raw message