jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vidar Ramdal <vi...@idium.no>
Subject Re: Hot-backup strategy
Date Tue, 25 May 2010 11:47:52 GMT
>>> On 25 May 2010, at 11:56, Vidar Ramdal wrote:
>>>> According to [1]: "Database persistence managers: many databases
>>>> support online backup, so if you use that you should be safe.".
>>>> Does this mean that a hot backup is "guaranteed" to be consistent when:
>>>> - The datastore is backed up
>>>> - The database is backed up using the database vendor's tools
>>>> [1] http://wiki.apache.org/jackrabbit/BackupAndMigration
>> On Tue, May 25, 2010 at 1:12 PM, Ian Boston <ieb@tfd.co.uk> wrote:
>>> From a RDBMS point of view, if the vendors tools claim consistency, then that
what you will get, only for the RDBMS.
>>> You will need to do
>>> DB backup
>>> Datastore (assuming file persistence) backup , since its append only and will
be consistent with the DB.
>>> in that order.

> On 25 May 2010, at 12:22, Vidar Ramdal wrote:
>> Thanks for your quick reply.
>> OK, so backup the DB first, then the datastore directory. Fine.
>> Just to be clear: You're saying that a hot RDBMS backup should be
>> consistent (thus restorable), even when the backup is run while
>> Jackrabbit is writing to the DB?
>> Do you yourself use this procedure?

On Tue, May 25, 2010 at 1:35 PM, Ian Boston <ieb@tfd.co.uk> wrote:
> Yes, on MySQL we use mysqldump against a mysql slave connected to a master DB.
> Mysql unfortunately does some locking of tables that makes things runs slow, so thats
why we do it on a slave. (thats how it guarantees consistency)

Thank you, that's very helpful.

> For Oracle, there is a well documented procedure for hot archive logging and hot backups.
For others there are equivalents.
> The only thing you might consider is although you will get a consistent DB and the DB
will have all the state it expects in the Datastore (although the Datastore may have more
state than the DB expects), if your users are half way though a non transacted operation (ie
web form flow) you might get their state half way through.  Not much you can do about that,
except at the application level.

Yup. Not much of a problem in our application. I guess we'll deal with
that if/when it happens :)

Vidar S. Ramdal <vidar@idium.no> - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 22 00 84 76
Quando omni flunkus moritatus!

View raw message