problems migratiing stage databases to live for testing

Hmmm...this is a known problem with Mulgara which everyone has been screaming for them to fix and I think Andrae finally made some check ins yesterday (but that will not help us right now). Details are here http://mulgara.org/jira/browse/MGR-58.

Yes, I believe you will need to export the data, but Ronald will probably know better.

okay, i'll try and dig up the export instructions to give it a go for now. good to know it's (potentially) not all my fault :)

Directs a Mulgara server to write out a backup file that can later be restored. The general syntax is as follows:

backup server#model to [local|remote] file;

Where:

• server is the URI of a complete Mulgara server to back up.
• #model is an individual model to back up (optional).
• local or remote specifies that the backup file is written locally on the client or remotely on server's filesystem, respectively. If not specified, the default is remote.
• file is the URI of the backup file.

Note - Backups of individual models are written in RDF format while servers are written in a modified compressed (gzip) N3 format. This is because groups of models cannot be represented in RDF.

For example:

backup <rmi://mysite.com/server1> to <file:/tmp/serverbackup.gz>;

and

backup <rmi://mysite.com/server1> to remote <file:/tmp/serverbackup.gz>;

are equivalent. Both commands write the server backup file remotely on the server's filesystem.

backup <rmi://mysite.com/server1#mymodel> to local <file:/tmp/modelbackup.rdf>;

writes the model backup file locally on the client.

Use the restore command to restore server backups and use the create and load commands to restore model backups.

yes, i got that far but i can't figure out my mulgara uri.

i tried the following:

• <rmi://localhost>
• <rmi://localhost:9091>
• <rmi://localhost:9091/>

but kept getting the error

org.mulgara.itql.parser.ParserException: [1,1] expecting: EOF

okay, i read http://docs.mulgara.org/tutorial/starting.html

i tried

• <rmi://plosone-stage.plos.org/server1>
• <rmi://plosone-stage.plos.org:9091/server1>

but still no luck...

backup <local:///topazproject> to <file:/tmp/serverbackup.gz>

seems to be doing the trick...

This is what I did:

backup <local:///topazproject> to remote <file:/tmp/server.backup>;

so now when i restore, do i need to drop the existing db...i will try that first...

itql> restore <local:///topazproject> from <file:/tmp/serverbackup.gz>;
2007-09-13 10:56:01,393 WARN  AttachmentsImpl> Exception:
AxisFault
 faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server.userException
 faultSubcode:
 faultString: java.lang.IllegalArgumentException: The char '0x14' after 'restore &lt;local:///' is not a valid XML character.

hmm...

itql> restore <rmi://mulgara-dev.localdomain:9091/topazproject> from <file:/tmp/serverbackup.gz>;

seems to be doing something...

okay, we're good! thanks for your help. i'll wiki this on the plos side...

Replying to amit:

Hmmm...this is a known problem with Mulgara which everyone has been screaming for them to fix and I think Andrae finally made some check ins yesterday (but that will not help us right now). Details are here http://mulgara.org/jira/browse/MGR-58. Yes, I believe you will need to export the data, but Ronald will probably know better.

No, we are not affected by this because we use SOAP to connect to mulgara, and on mulgara we use the local:... scheme (i.e. which has no hostname and is therefore portable).

The "Unable to set the host names" message is normal and can be ignored. There must've been something else in the mulgara logs besides the two messages you listed.

Replying to russ:

itql> restore <rmi://mulgara-dev.localdomain:9091/topazproject> from <file:/tmp/serverbackup.gz>;

seems to be doing something...

Oh oh, no, this is wrong. We may be lucky that this works, but I think it may also mess things up. Use

itql> restore <local:///topazproject> from <file:/tmp/serverbackup.gz>;

Replying to russ:

so now when i restore, do i need to drop the existing db...i will try that first...

No, restore will complete replace the original stuff. Though if you remove the actual db files first, i.e. start mulgara on an empty directory, you'll get the smallest disk usage.

i tried what ronald suggests, but got an error - see comment 9...

Russ, I can bet you had a typo error in itqlrun earlier and tried to use the 'history' to get it to run again. 'history' in itqlrun is a bit iffy and I have had quite a few problems. Just type it again and try and the problem should not happen. I have tried it a few times between snape and black and have not had this problem.

sounds good - or, actually it sounds like a reasonable theory with a bad consequence.

if my previous restore failed for some reason then i'll need to do another migration before i can test the full plosone corpus on my single box, which is cutting things a little tight for this week's upgrade.

is there any way to tell if what it did was also an okay thing to do?

Replying to russ:

i tried what ronald suggests, but got an error - see comment 9...

0x14 is ctrl-t - somehow you got a control character in there. So retype from scratch, or copy paste from here.

okay, i know what i did wrong and i agree with your diagnosis of why the right thing didn't work :(

don't know if what i did also worked, but we'll find out in a few hours on ticket #637

i've since gotten the correct restore to work successfully on my single box dev.

thanks for your help.

i'm making a note for myself to try and reproduce my errors with copying the actual database instead of backup/restore, since ronald says this shouldn't be an issue either.