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 10:30:15 GMT

On 27 Jul 2010, at 11:00, zeeman wrote:

> Hi!
> Thanks for the first response.
> 
>>> 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 index
>> 2) invaidate any items in the shared local items state cache so that 
> they
>> are refreshed from the DB when required.
> 
> Ok, this is nearly what I expected.
> But what is is this "shared local items state cache"?
> Is this the normal cache every JCR node has? I would expect this cache is
> only filled if a item is queried for and it does not try to synchronize
> the
> complete repository in the (in-memory?) cache. 

apologies, I meant
the item is evicted and when its next required it will get pulled in from the DB
if did not mean
the item is evicted and immediately pulled in from the DB.


> 
> And as I'm usuing OracleFileSystem and OraclePersistenenceManager the
> shared folder (in fact a table) should be up-to-date as the not-failed
> node
> has done its changes to the journal and the shared folder (the shared
> table).

agreed
The shared ItemState is an in memory structure see [1], to give it its proper name SharedItemStateManager
or Shared ISM, not an Oracle table which is shared between all nodes as you state.


1 http://jackrabbit.apache.org/how-jackrabbit-works.html

> 
> 
>>> 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?
>> 
>> Correct
>> 
>>> 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.
> 
> What is permanent on of local repository home? 
> * The cache is in-memory (I guess), 
> * the workspace configuration can be recreated from the repository.xml (as
> on the very first start),
> * the search index ca be rebuild and 
> * the repository content is always up-to-date in the table. 


permanent in the sense you don't want that area to be deleted when the JVM is restarted.

Ideally you do not want to be recreating this area at all since you will have to replay all
journal events to re-build the search index.


> 
> My overall goal is to minimize backup efforts and doing no backup of the
> nodes' local repository folder would be very nice (as I hope it can be
> rebuild in case of a failure).


You don't have to back up the local folders, but if you do it will be far quicker to bring
a new  node up.

HTH
Ian

> 
> Kind regards,
> Sebastian
> 


Mime
View raw message