Return-Path: Delivered-To: apmail-db-derby-user-archive@www.apache.org Received: (qmail 23614 invoked from network); 22 Oct 2008 11:05:27 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 22 Oct 2008 11:05:27 -0000 Received: (qmail 81624 invoked by uid 500); 22 Oct 2008 11:05:30 -0000 Delivered-To: apmail-db-derby-user-archive@db.apache.org Received: (qmail 81164 invoked by uid 500); 22 Oct 2008 11:05:28 -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 81153 invoked by uid 99); 22 Oct 2008 11:05:28 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 22 Oct 2008 04:05:28 -0700 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=FS_REPLICA,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [66.192.107.230] (HELO bluetang.coloflorida.com) (66.192.107.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 22 Oct 2008 11:04:17 +0000 Received: from mackerel.coloflorida.com (66.192.107.221) by bluetang.coloflorida.com (66.192.107.230) with Microsoft SMTP Server (TLS) id 8.1.291.1; Wed, 22 Oct 2008 07:04:51 -0400 Received: from EVS-RED.coloflorida.com ([66.192.107.214]) by mackerel.coloflorida.com ([66.192.107.221]) with mapi; Wed, 22 Oct 2008 07:06:19 -0400 From: Andrew Lawrenson To: Derby Discussion Date: Wed, 22 Oct 2008 07:04:53 -0400 Subject: RE: replication - master log overflow Thread-Topic: replication - master log overflow Thread-Index: Ack0HsieJGfE98lkS/Ss0qGfWH3/bAAFtecg Message-ID: <882C3355DFF9D3468379DD1E8C115FC7148BACCB58@EVS-RED.coloflorida.com> References: <48FA8EDA.6090901@lucentradius.com> <48FC2D6C.6080101@sun.com> <48FE5506.7060500@alcatel-lucent.com> In-Reply-To: <48FE5506.7060500@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Virus-Checked: Checked by ClamAV on apache.org I would also welcome a programatic way to determine the status of the maste= r and/or slave. I'm currently planning (but haven't got there yet) to regularly try & conne= ct to the slave, and make sure we get a failure with a sqlstate indicating = it's won't accept connections due to being a slave - but this is about the = only programatic check I've come up with so far. Andrew Lawrenson -----Original Message----- From: Glenn McGregor [mailto:gm44@alcatel-lucent.com] Sent: 21 October 2008 23:18 To: Derby Discussion Subject: Re: replication - master log overflow J=F8rgen L=F8land wrote: > Glenn McGregor wrote: >> How is one supposed to tell if a database in 'master' >> mode has exceeded its log buffer limit after its become isolated from >> the 'slave'? > > You'll have to look in the derby.log file on the master to learn this. > You'll find something like this (from memory - the actual text may > differ slightly): Sorry, I was not specific enough in my question. Is there a way to determi= ne this condition programmatically? I am attempting to automate the various steps of the sync-up and failover, = and I need more information about what state a database is in, both on the = master and slave servers. Thanks Glenn