jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Boston <...@tfd.co.uk>
Subject Re: Oracle Cluster configuration questions
Date Tue, 27 Jul 2010 07:05:37 GMT

On 27 Jul 2010, at 07:17, zeeman wrote:

> Hi list,
> I'm quite new to JCR/Jackrabbit though I've got some questions about the
> Jackrabbit cluster configuration and behavoir:
> * My setup:
> I'm using JDK6 (1.6.0_11) running JBoss 4.2.3 with Oracle 10g. I use
> Jackrabbit 1.6.2 as JCA ressource.
> Currently I've configured my cluster (2 Jackrabbit nodes on 2 differen
> JBOss server) to
> - Repository Filesystem is an OracleFileSystem
> --- Default workspace Filesystem is a OracleFileSystem
> --- Default workspace PersistentenceManager is a OraclePersistenceMaanger
> (externalBLOBS=false)
> -- Workspaces versioning Filesystem is a OracleFileSystem
> -- Workspaces versioning PersistenceManager is a OraclePersistenceManager
> - Cluster Journal is a OracleDatabaseJournal (Revision log is under
> ${rep.home}/revision
> Starting both nodes seemt to work and the Journal table is filled with
> entries.
> Also (according to the logs) changes from one node are "replicated" on the
> other node.
> *Can anyone say if I've create a valid, stable cluster configuratin? I'm
> happy to provide my complete repository.xml (Is attaching allowed on this
> list?)

from your observations it looks like you do have a stable config.

> My goal is to persist the whole repository in the Oracle Database (except
> the search index and the revision log ;-) ) to keep backup effors minimal.
> I think this is a valid approach as I expect only small text files to be
> placed in the repository (and no (large) binary files).
> Another question aries about the cluster failover:
> * What happens if one node goes down?
> I expect on restart the failing node will "replicate" the missed updates
> from the repoistory. But as the "repository" itself is already in the
> database tables what does really happen? Is only the search index
> refreshed?

All the journal events that the failed node missed when it was down will be replayed when
the failed node comes back. This will 
1) Cause (re-) indexing of any items that changed while offline updating  the local lucene
2) invaidate any items in the shared local items state cache so that  they are refreshed from
the DB when required.

If the node has been offline for some time then this process may take some time. You might
want to consider snapshotting the local disk states =
of nodes so that you can avoid re-processing all the events since the year dot on a new node.

The simple way to do this is to shut a node down, save the local state to a tarball and when
you recover it edit the repository.xml files to update the cluster node ID on the target node.
It is possible to do hot snapshots but this involves some gymnastics with rsync and bash to
ensure that you have a consistent state, or you could hack a hook into the Journal writer
to pause operations while a snapshot is taken. I (my employer) have been running for about
24 months in production on an 8 way cluster with bash/rsync snapshotting which works just

> Also what happens if the local revision log / complete workspace folder is
> deleted?

The instance will rebuild from the year dot using the journal.

> I would expect that (a) the complete repository is somewhat replicated
> (see above) and (b) the search index is rebuild. According to the
> repository size that might take some time but should work without user
> interaction. Is that right?


> Though what is a recommended place for the local JCR "workspace folder" as
> it only contains the search index and the revision log?

and iirc some other things like config.

> Is
> <JBOSS>/server/default/tmp a good approach?

I would not call it tmp, its permanent local state.

> Thanks in advance for any clarificaion,
> Sebastian


View raw message