[Mulgara-dev] CRITICAL: Bug fix to Backup operation

Paul Gearon gearon at ieee.org
Wed Mar 26 16:10:24 UTC 2008


Since this is the developers mailing list (ie. for people writing code
packaged under org.mulgara) and not the general mailing list (for anyone
USING Mulgara), then I figure I can promote what we're doing here.

Andrae has been working hard on this bug, and I even think that I have a
task to do with backup/restore, but in the longer term many of these issues
will go away for us.

The issues here are coming out of phases (transaction objects) on the string
pool. We have a design for a simpler, smaller, and MUCH FASTER string pool
that doesn't have any of these issues at all. One of the big differences is
that it won't support a delete operation - at least not in normal operation.
It does have a compaction operation to use if it starts taking up too much
space (we've also talked about running this in the background when the
system isn't busy, but that isn't decided), but in most cases it will take
up MUCH less space than the current system does, even when nothing ever gets
deleted. Because objects don't get deleted and gNodes don't get reused, then
it won't be possible for it to lose sync in any way.

So I'm just promoting the fact that by the end of the year we will have a
faster, smaller, and more reliable system. Not that I think that the current
system isn't reliable.... but we shouldn't be seeing the errors being
reported in this thread. I'd love to be working on the new string pool
already, as would Andrae (I think), but we are both trying to get other
stuff done first (including this bug), so please bear with us.  :-)

(Meanwhile we will try to fix any existing problems)

Regards,
Paul

On Wed, Mar 26, 2008 at 10:16 AM, Russell Uman <ruman at plos.org> wrote:

> > On 26/03/2008, at 6:21 AM, Russell Uman wrote:
> > > we've done backup and then restore on production databases
> > - is there
> > > anything we need to do to repair our data and/or to look for
> > > inconsistencies?
> >
> > Backups obtained while holding the write-lock should be
> > completely fine - as I believe that is how PLoS was doing
> > their backups this shouldn't have affected your existing backups.
>
> correct. since we always got NPE on backups w/o write lock we only ever
> used backups that were made in a lock :)
>
> > AFAIK this affects PLoS only in that with this patch you
> > won't be seeing the NPE when you try and run backups on the
> > committed-phase as we discussed in SF.
>
> thank you!
>
>
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> This email is confidential to the intended recipient. If you have received
> it in error, please notify the sender and delete it from your system. Any
> unauthorized use, disclosure or copying is not permitted. The views or
> opinions presented are solely those of the sender and do not necessarily
> represent those of Public Library of Science unless otherwise specifically
> stated. Please note that neither Public Library of Science nor any of its
> agents accept any responsibility for any viruses that may be contained in
> this e-mail or its attachments and it is your responsibility to scan the
> e-mail and attachments (if any).
>
> _______________________________________________
> Mulgara-dev mailing list
> Mulgara-dev at mulgara.org
> http://mulgara.org/mailman/listinfo/mulgara-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mulgara.org/pipermail/mulgara-dev/attachments/20080326/4e6da2bc/attachment.htm>


More information about the Mulgara-dev mailing list