jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Wechner <michael.wech...@wyona.com>
Subject Re: Add new nodes to a cluster
Date Sun, 08 May 2011 10:28:49 GMT
Hi

Thanks very much for this summary.

Maybe you can add it to the Wiki

http://wiki.apache.org/jackrabbit/Clustering

;-)

Thanks

Michael

On 5/3/11 9:18 AM, Christian Stocker wrote:
> Hi
>
> Just a little update on that, the following procedure seem to work
>
> - shutdown instance
> - get number from JOURNAL_LOCAL_REVISIONS
> - cp -r jackrabbit jackrabbit.bkup
> - mv jackrabbit.bkup to another server
> - change repository with new nodename in clusterconfig
> - add that to JOURNAL_LOCAL_REVISIONS with the number from above
> - done ;)
>
>
> I'll try to make a little script for that and document it
>
> THanks for all the input
>
> christian
>
> On 19.04.11 14:24, Christian Stocker wrote:
>> Hi all
>>
>> thanks a lot for your answers, looks good to me and we will proceed ;)
>>
>> christian
>>
>> On 19.04.11 13:46, Jeroen Reijn wrote:
>>>>>
>>>>> On 18.04.11 11:04, Jeroen Reijn wrote:
>>>>>>> I'm also not 100% sure, but I can second Alex his answer.
>>>>>>> > From what I've seen the new cluster node will start from
the persisted
>>>>> data
>>>>>>> and will continue from there on with using the journal.
>>>>> The question is then, how does the new cluster node know on which
>>>>> position he should start? Or do we "just" have to make sure, that
>>>>> nothing writes between the start of the new node and "when it's ready".
>>>>> How do we know it's ready then?
>>>>>
>>> If you're using a database I know that there is a table in which Jackrabbit
>>> stores the global revision, which is the latest revision. All the nodes in
>>> the cluster will work towards that revision based on the repository journal.
>>> My best bet would be that when a new node in the cluster starts, it starts
>>> from this global revision.
>>>
>>> Next to the global_revision table, there is also a local_revision table that
>>> contains the current revision for each node in the cluster.
>>>
>>>
>>>


Mime
View raw message