You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Samuel Cox <cr...@gmail.com> on 2009/12/10 13:34:54 UTC
RepositoryCopier requires shutdown of source repositoy?
Hi,
I need to backup our repository periodically and anticipate using the
RepositoryCopier class. I was curious that 2 of the methods in the Javadoc
mention that the source repo must not be modified during the call; however,
the others do not. Is it possible for me to perform a backup while still
allowing JCR API calls that modify the repo? In other words, will
RepositoryCopier somehow lock/cache/unlock/flush/etc for me? I'm guessing
it won't/can't do this.
I'm going to test it, but figured I'd ask anyway.
Thanks.
Re: RepositoryCopier requires shutdown of source repositoy?
Posted by Thomas Müller <th...@day.com>.
Hi,
I have added this information to the wiki at
http://wiki.apache.org/jackrabbit/BackupAndMigration#Repository_Copier_Tool
Regards,
Thomas
Re: RepositoryCopier requires shutdown of source repositoy?
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Thu, Dec 10, 2009 at 2:19 PM, Samuel Cox <cr...@gmail.com> wrote:
> Does this include things like indexing going on? I can cache changes
> to calls like Node.setProperty(...), but I'm not sure how to block all
> the other stuff without a complete shutdown. Is a complete shutdown
> required?
No, you're fine as long as you can guarantee that no session does a
save() or commits a transaction (or does some of the other directly
persisted changes like move(), checkin() or namespace and node type
registration) while the backup is taking place.
BR,
Jukka Zitting
Re: RepositoryCopier requires shutdown of source repositoy?
Posted by Samuel Cox <cr...@gmail.com>.
On Thu, Dec 10, 2009 at 6:58 AM, Jukka Zitting <ju...@gmail.com> wrote:
>
> Hi,
>
> On Thu, Dec 10, 2009 at 1:34 PM, Samuel Cox <cr...@gmail.com> wrote:
> > I need to backup our repository periodically and anticipate using the
> > RepositoryCopier class. I was curious that 2 of the methods in the Javadoc
> > mention that the source repo must not be modified during the call; however,
> > the others do not. Is it possible for me to perform a backup while still
> > allowing JCR API calls that modify the repo? In other words, will
> > RepositoryCopier somehow lock/cache/unlock/flush/etc for me?
> > I'm guessing it won't/can't do this.
>
> You're right, the RepositoryCopier doesn't contain any protection
> against concurrent changes to the repository. If you allow clients to
> modify the repository while you're backing it up, you may end up with
> an inconsistent backup.
Does this include things like indexing going on? I can cache changes
to calls like Node.setProperty(...), but I'm not sure how to block all
the other stuff without a complete shutdown. Is a complete shutdown
required?
Thanks.
Re: RepositoryCopier requires shutdown of source repositoy?
Posted by Thomas Müller <th...@day.com>.
Hi,
> I cannot get RepositoryCopier to work regardless of whether or not someone
> is modifying it. I get the following error if I've already created a
> TransientRepository and logged in.
See http://wiki.apache.org/jackrabbit/RepositoryLock#Why_Is_the_Repository_Locked
> Does this mean that I have to shutdown the TransientRepository before I can
> perform the backup?
You need to only one Repository instance at any time. You can open
multiple sessions however.
Regards,
Thomas
Re: RepositoryCopier requires shutdown of source repositoy?
Posted by Samuel Cox <cr...@gmail.com>.
Jukka Zitting wrote:
> Hi,
>
> On Thu, Dec 10, 2009 at 1:34 PM, Samuel Cox <cr...@gmail.com> wrote:
>> I need to backup our repository periodically and anticipate using the
>> RepositoryCopier class. I was curious that 2 of the methods in the Javadoc
>> mention that the source repo must not be modified during the call; however,
>> the others do not. Is it possible for me to perform a backup while still
>> allowing JCR API calls that modify the repo? In other words, will
>> RepositoryCopier somehow lock/cache/unlock/flush/etc for me?
>> I'm guessing it won't/can't do this.
>
> You're right, the RepositoryCopier doesn't contain any protection
> against concurrent changes to the repository. If you allow clients to
> modify the repository while you're backing it up, you may end up with
> an inconsistent backup.
I cannot get RepositoryCopier to work regardless of whether or not
someone is modifying it. I get the following error if I've already
created a TransientRepository and logged in.
javax.jcr.RepositoryException: The repository home
/opt/fuse-esb-4.1.0.0/data/di/repository/design/repository/repository
appears to be in use since the file named .lock is already locked by the
current process.
at
org.apache.jackrabbit.core.util.RepositoryLock.tryLock(RepositoryLock.java:159)
at
org.apache.jackrabbit.core.util.RepositoryLock.acquire(RepositoryLock.java:138)
Does this mean that I have to shutdown the TransientRepository before I
can perform the backup? When I do that it works, but I was under the
impression I did not have to do this.
Thanks.
--
Samuel Cox
Re: RepositoryCopier requires shutdown of source repositoy?
Posted by Samuel Cox <cr...@gmail.com>.
Guo Du wrote:
> On Wed, Dec 16, 2009 at 3:21 PM, Samuel Cox <cr...@gmail.com> wrote:
>> doing a restore (exploding the zip); however, if only reads are happening,
>> do I have to shutdown when doing the backup (creating the zip)?
>
> Yes you can. But not recommended especial for production system. It's
> related to underline database. If you use the default derby db,
> following doc may help you do the backup properly:
> http://www.ibm.com/developerworks/data/library/techarticle/dm-0502thalamati/index.html
>
Sorry, I should have specified that I am using Derby. Thanks for the
article.
I probably won't be issuing any command directly to the underyling Derby
DB (i.e. SYSCS_UTIL.SYSCS_FREEZE_DATABASE()).
If it isn't production-quality to copy the db during reads, I'll either
perform a shutdown or use the RepositoryCopier from Jackrabbit 1.6,
which would allow me to backup during read access.
Thanks.
--
Samuel Cox
Re: RepositoryCopier requires shutdown of source repositoy?
Posted by Guo Du <mr...@gmail.com>.
On Wed, Dec 16, 2009 at 3:21 PM, Samuel Cox <cr...@gmail.com> wrote:
> doing a restore (exploding the zip); however, if only reads are happening,
> do I have to shutdown when doing the backup (creating the zip)?
Yes you can. But not recommended especial for production system. It's
related to underline database. If you use the default derby db,
following doc may help you do the backup properly:
http://www.ibm.com/developerworks/data/library/techarticle/dm-0502thalamati/index.html
-Guo
Re: RepositoryCopier requires shutdown of source repositoy?
Posted by Samuel Cox <cr...@gmail.com>.
Guo Du wrote:
> On Tue, Dec 15, 2009 at 6:01 PM, Samuel Cox <cr...@gmail.com> wrote:
>> however, I'm wondering why shouldn't I just backup the entire directory into
>> a zip file? Restore would just be replace existing directory with the
>> exploded zip.
> It won't work if your PM is not in local file such as in mysql db.
>
> If you using derby to store in local directory, you may do that if
> repository is not running. If it's running, it is not safe to do so.
I can certainly understand why the repository would need to be shutdown
when doing a restore (exploding the zip); however, if only reads are
happening, do I have to shutdown when doing the backup (creating the zip)?
--
Samuel Cox
Re: RepositoryCopier requires shutdown of source repositoy?
Posted by Guo Du <mr...@gmail.com>.
On Tue, Dec 15, 2009 at 6:01 PM, Samuel Cox <cr...@gmail.com> wrote:
> however, I'm wondering why shouldn't I just backup the entire directory into
> a zip file? Restore would just be replace existing directory with the
> exploded zip.
It won't work if your PM is not in local file such as in mysql db.
If you using derby to store in local directory, you may do that if
repository is not running. If it's running, it is not safe to do so.
-Guo
Re: RepositoryCopier requires shutdown of source repositoy?
Posted by Samuel Cox <cr...@gmail.com>.
Jukka Zitting wrote:
> Hi,
>
> On Thu, Dec 10, 2009 at 1:34 PM, Samuel Cox <cr...@gmail.com> wrote:
>> I need to backup our repository periodically and anticipate using the
>> RepositoryCopier class. I was curious that 2 of the methods in the Javadoc
>> mention that the source repo must not be modified during the call; however,
>> the others do not. Is it possible for me to perform a backup while still
>> allowing JCR API calls that modify the repo? In other words, will
>> RepositoryCopier somehow lock/cache/unlock/flush/etc for me?
>> I'm guessing it won't/can't do this.
>
> You're right, the RepositoryCopier doesn't contain any protection
> against concurrent changes to the repository. If you allow clients to
> modify the repository while you're backing it up, you may end up with
> an inconsistent backup.
So I have to block those calls while I perform a backup. That is fine;
however, I'm wondering why shouldn't I just backup the entire directory
into a zip file? Restore would just be replace existing directory with
the exploded zip.
Am I missing something? Note: I'm guessing I'd need to shutdown all
active sessions during a restore, but that is ok as I have control over
that.
Thanks.
--
Samuel Cox
Re: RepositoryCopier requires shutdown of source repositoy?
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Thu, Dec 10, 2009 at 1:34 PM, Samuel Cox <cr...@gmail.com> wrote:
> I need to backup our repository periodically and anticipate using the
> RepositoryCopier class. I was curious that 2 of the methods in the Javadoc
> mention that the source repo must not be modified during the call; however,
> the others do not. Is it possible for me to perform a backup while still
> allowing JCR API calls that modify the repo? In other words, will
> RepositoryCopier somehow lock/cache/unlock/flush/etc for me?
> I'm guessing it won't/can't do this.
You're right, the RepositoryCopier doesn't contain any protection
against concurrent changes to the repository. If you allow clients to
modify the repository while you're backing it up, you may end up with
an inconsistent backup.
BR,
Jukka Zitting