Return-Path: Delivered-To: apmail-db-derby-user-archive@www.apache.org Received: (qmail 32601 invoked from network); 8 Apr 2009 13:27:51 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 8 Apr 2009 13:27:51 -0000 Received: (qmail 80195 invoked by uid 500); 8 Apr 2009 13:27:51 -0000 Delivered-To: apmail-db-derby-user-archive@db.apache.org Received: (qmail 80144 invoked by uid 500); 8 Apr 2009 13:27:50 -0000 Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: List-Id: Reply-To: "Derby Discussion" Delivered-To: mailing list derby-user@db.apache.org Received: (qmail 80134 invoked by uid 99); 8 Apr 2009 13:27:50 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 08 Apr 2009 13:27:50 +0000 X-ASF-Spam-Status: No, hits=-2.8 required=10.0 tests=FS_REPLICA,RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [192.18.43.24] (HELO sca-ea-mail-1.sun.com) (192.18.43.24) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 08 Apr 2009 13:27:41 +0000 Received: from dm-uk-02.uk.sun.com ([129.156.101.196]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n38DRKNo005033 for ; Wed, 8 Apr 2009 13:27:20 GMT Received: from barman.uk.sun.com (barman.UK.Sun.COM [129.156.132.12]) by dm-uk-02.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n38DRJ91008476 for ; Wed, 8 Apr 2009 14:27:19 +0100 (BST) Received: from vpn-129-150-121-69.uk.sun.com ([129.150.121.69]) by barman.uk.sun.com with esmtp (Exim 4.42) id 1LrXuI-0000qR-6C for derby-user@db.apache.org; Wed, 08 Apr 2009 14:33:34 +0100 Message-ID: <49DCA5F0.6000803@sun.com> Date: Wed, 08 Apr 2009 14:26:08 +0100 From: Alan Burlison User-Agent: Thunderbird 2.0.0.18 (X11/20081215) MIME-Version: 1.0 To: Derby Discussion Subject: Re: master and slave are not in synch for replicated database References: <8CE9C7FC34485B41B9A6B7459DFED80802B9BD1A@MI8NYCMAIL03.Mi8.com> <8CE9C7FC34485B41B9A6B7459DFED80801939F4F@MI8NYCMAIL03.Mi8.com> <49DC53E1.5000706@Sun.COM> <49DC83DC.4000905@sun.com> <49DC8B8D.5010600@Sun.COM> In-Reply-To: <49DC8B8D.5010600@Sun.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org 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 --