[Mulgara-dev] Very large backup file

[Ben Hysell]

Paul,

No the large number never changes...same one on every line.

The guids are literals, sorry I did not make that clear in my original email.

As for operations at the time of the incident, I know we were not under heavy load because it was Memorial day at noon when the error happened, however we can not afford to cut off all access to the database every time we run a backup, this would be unacceptable. (We would need to shut off access to our website and all of our processing apps every four hours...I can already hear the phone  ringing off the hook at our support desk :-) )   

Paul, are you thinking if by chance someone had preformed an insert or a delete around the time the backup was kicked off and the backup could end up in this state?  On the same token, if a user were just querying the database and they happened to for example, create an ill formed query, would this also possibly cause this error?

As far as the iterator with the string pool, is it possible this could be corrupted?  Would this corruption cause issues like being able to query for an element while it is an object, however if you query for it when it is a subject it could not be found?

Thanks for all of your help Paul, if there is anything we are not capturing or doing that would shed any more light on this issue please let me know.

-ben

-----Original Message-----
From: gearon at gmail.com on behalf of Paul Gearon
Sent: Wed 6/6/2007 5:41 PM
To: Ben Hysell
Cc: mulgara-dev at mulgara.org
Subject: Re: [Mulgara-dev] Very large backup file
 
On 6/6/07, Ben Hysell <BenH at viewpointusa.com> wrote:
> The version of Mulgara we were running on production I believe was 250
> or 258 when this issue cropped up.  Since this issue upgraded to the
> latest version and we are now running 279.

OK.  We'd better log this in Jira then.

> I was able to open the backup, and around line 2 million onward I had a
> guid literal repeat over and over again, so my backup file never made it
> down to the quads.
>
> i.e.
> (large number) 5d868b1b-684c-42ef-b49e-979f93d64b8e
> (large number) 5d868b1b-684c-42ef-b49e-979f93d64b8e
> (large number) 5d868b1b-684c-42ef-b49e-979f93d64b8e
> (large number) 5d868b1b-684c-42ef-b49e-979f93d64b8e
> And so on...

I'm guessing that the large number never changes?

This looks like a problem with the iterator in the string pool.  Do
you have the datatype for the GUID?  It doesn't look like a string, or
is it?  (are there quote characters around it or anything?)

The other problem is the concurrent access.  I thought that was
addressed now.  Is there any possibility that you're actually doing
some operations in parallel at the time the exception was logged (ie.
a client error)?

If not, then we need to re-open that Jira bug.

Regards,
Paul

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mulgara.org/pipermail/mulgara-dev/attachments/20070606/b963a9c9/attachment.htm>