db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brian Spindler" <bspind...@netuitive.com>
Subject RE: master and slave are not in synch for replicated database
Date Wed, 08 Apr 2009 14:07:45 GMT
I agree.  This seems even more complicated when considering the db from
an embedded standpoint.  The slave app has to boot the db without
performing any write operations until it has become master (which I
don't know how it would know this?)

I presume from what I've seen there is very little documentation and
testing around the different replication use cases? 


-----Original Message-----
From: Alan Burlison [mailto:Alan.Burlison@sun.com] 
Sent: Wednesday, April 08, 2009 9:26 AM
To: Derby Discussion
Subject: Re: master and slave are not in synch for replicated database

V Narayanan wrote:

> I am not sure if you wanted to ask two separate questions or a single 
> question, I will treat them as two separate questions

You guesses right - two questions :-)

>> How do you 'fail back' to the master?
> fail back = auto failover?
> You mean after you failover and your slave becomes your new master,
> will you fail back to the old master?


> You will have to restart replication on the slave (i.e.) you will have

> to do the freezing, copying data files again on the
> slave.

OK, thanks.  Although I guess you'd stop both and copy from the slave to

the master, as that is the 'live' DB once the original failover

>> If I shut the master and slave down once replication is running, do I

>> have to re-copy the data files from the master to the slave before 
>> restarting the slave?
> If you shutdown both the master and the slave you are restarting 
> replication when the master comes up :),  Ideally speaking
> you should be re-copying data files, but I confess I have never tried 
> this, I think if you do it without a re-copy you will get a
> error similar to this,
> Caused by: ERROR XRE05: The log files on the master and slave are not
> synch for replicated database 'foo'. The master log instant is
> whereas the slave log instant is 1:103957. This is FATAL for
> - replication will be stopped.

That is going to be virtually unworkable in a production environment.

Alan Burlison

View raw message