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? -Brian -----Original Message----- From: Alan Burlison [mailto:[email protected]] 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, how > will you fail back to the old master? Yes. > 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 happened. >> 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 in > synch for replicated database 'foo'. The master log instant is 1:104173, > whereas the slave log instant is 1:103957. This is FATAL for replication > - replication will be stopped. That is going to be virtually unworkable in a production environment. -- Alan Burlison --
