From dev-return-20445-apmail-jackrabbit-dev-archive=jackrabbit.apache.org@jackrabbit.apache.org Mon Oct 13 18:01:06 2008
Return-Path:
Delivered-To: apmail-jackrabbit-dev-archive@www.apache.org
Received: (qmail 19782 invoked from network); 13 Oct 2008 18:01:06 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
by minotaur.apache.org with SMTP; 13 Oct 2008 18:01:06 -0000
Received: (qmail 29114 invoked by uid 500); 13 Oct 2008 18:01:05 -0000
Delivered-To: apmail-jackrabbit-dev-archive@jackrabbit.apache.org
Received: (qmail 29075 invoked by uid 500); 13 Oct 2008 18:01:05 -0000
Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
List-Help:
List-Unsubscribe:
List-Post:
List-Id:
Reply-To: dev@jackrabbit.apache.org
Delivered-To: mailing list dev@jackrabbit.apache.org
Received: (qmail 29064 invoked by uid 99); 13 Oct 2008 18:01:05 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 13 Oct 2008 11:01:05 -0700
X-ASF-Spam-Status: No, hits=-2000.0 required=10.0
tests=ALL_TRUSTED
X-Spam-Check-By: apache.org
Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140)
by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 13 Oct 2008 18:00:07 +0000
Received: from brutus (localhost [127.0.0.1])
by brutus.apache.org (Postfix) with ESMTP id 78DD7234C21B
for ; Mon, 13 Oct 2008 11:00:44 -0700 (PDT)
Message-ID: <1212192255.1223920844494.JavaMail.jira@brutus>
Date: Mon, 13 Oct 2008 11:00:44 -0700 (PDT)
From: "Antonio Martinez-Navarro (JIRA)"
To: dev@jackrabbit.apache.org
Subject: [jira] Commented: (JCR-1801) Support Online Backup
In-Reply-To: <774819883.1223890484570.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on apache.org
[ https://issues.apache.org/jira/browse/JCR-1801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12639138#action_12639138 ]
Antonio Martinez-Navarro commented on JCR-1801:
-----------------------------------------------
This new feature would be usefull in two scenarios: "Online Backup" and "Online Addition of Cluster Node".
In both cases the problem is that we need to make a copy of the local data (i.e, repository dir, revision.log file and workspaces dir), guaranteeing that it is in sync with the DB at the time of the snapshot.
The reason why this is needed is is because in large DBs (for example I have tested with 20G DB), indexing (with local indexing data missing) would take more than 3 hours, and we can run out of Heap (tested with 2G Heap)
For Online Backup, the user application will backup both the DB and the local index data
For "Online Addition of Cluster Node", the user application will backup ONLY the local data. This snapshot of local data can then be copied by the user to the new cluster node. When the new cluster node comes up, it will have to synchronize to the latest snapshot (which can have changes as the cluster is not stopped), but if the difference is small there should be no problem.
> Support Online Backup
> ---------------------
>
> Key: JCR-1801
> URL: https://issues.apache.org/jira/browse/JCR-1801
> Project: Jackrabbit
> Issue Type: New Feature
> Components: clustering, jackrabbit-core
> Reporter: Thomas Mueller
> Priority: Minor
>
> There is no 'good' way to create an online backup for Jackrabbit. Currently you need to basically stop the repository before backing up the data, or at least make sure in the application that nobody writes to the repository.
> One solution is to add a feature to block write access to the repository until the backup is complete.
> Example configuration: database persistence manager, Lucene index, data store.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.