Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: domain of lists@nabble.com designates
 216.139.236.158 as permitted sender)
Message-ID: <25132565.post@talk.nabble.com>
Date: Tue, 25 Aug 2009 04:29:13 -0700 (PDT)
From: AdamR <adam.ross@runbox.com>
To: users@jackrabbit.apache.org
Subject: Re: Clustering with database replication
In-Reply-To: <25132305.post@talk.nabble.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <25132305.post@talk.nabble.com>


AdamR wrote:
> 
> On the master, the local_revisions table contains one row for itself,
> which obviously always contains the latest revision ID. The table does not
> contain any data for the other cluster nodes (the MySQL replication only
> works in one direction), which it has no knowledge about. As far as I can
> tell this table is only used to determine which items from the journal
> need to be processed on each node, therfore so long as each node's copy of
> the local_revisions table has itself in, it should be fine?
> 

Hmm, I just discovered the RevisionTableJanitor. This would be problematic
as the cluster journal would constantly get cleaned-up before the slave
nodes have a chance to update themselves. However, I think everything will
be fine if I keep this turned off and run periodic manual clean-ups instead.
-- 
View this message in context: http://www.nabble.com/Clustering-with-database-replication-tp25132305p25132565.html
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.