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 RE: Replication - switching back after failover
Date Tue, 14 Oct 2008 12:00:23 GMT
Jorgen/Knut,

        many thanks for this.

        one clarification - "should" it work in the scenario where on the master you do a
restore from the slave & roll forward through the logs? (as opposed to just copying the
whole database while both are shut down)

        many thanks,

        Andrew.

-----Original Message-----
From: Jorgen.Loland@Sun.COM [mailto:Jorgen.Loland@Sun.COM]
Sent: 14 October 2008 12:43
To: Derby Discussion
Subject: Re: Replication - switching back after failover

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

Mime
View raw message