Hi > > There's an upgrade guide on the website defining the actions you need to > > do. One point you may have missed is, that you should dump and upload your > > old DB to the new box. Invenio has some functions to upgrade the db and > > you're with your data then on the new sytem. > Thanks! I may have missed the guide, but everything I've > found so far seems specific to upgrading an existing > installation (as opposed to migration to a new > installation). A link to any instructions I may have > missed would be greatly appreciated.
Actually, we changed machines in a scenario similar to yours. Our old sytem running 1.0.2 on prod and dev. The new system is 1.1.4 and we actually exchanged dev and prod servers. > My first attempt: > - mysqldump database from old server, and import to new mysql server > - rsync .../var/data over from old 1.0.1 server to the new 1.1.4 server Sync /opt/invenio, check if you need to adopt invenio-local.conf and then proceed with upgrade sounds like a procedure. At least this is what we did. (However, we use automatised installations, so not everything from join2 translates right away to your procedure. E.g. we just installed invenio 1.0.2 instead of rsyncing it.) > Failed with: OperationalError: (1054, "Unknown column > 'sequenceid' in 'field list'") > (connections.py:36:defaulterrorhandler) Sure. Your database is a 1.0 database if you just load the dump. You need the db upgrades from the update recipes to work with 1.1 Also note, that the upgrader creates a new table, that lists all updates that where installed already. I rember, that this table sometimes gets populated too early, ie. before the install went through without failure. At least at some point we had to drop this table (knowing that we have a 1.0.2 db dump loaded) to get the upgrader doing anything at all. > I then tried: > - starting with a clean installation of 1.0.1 on the new server and db. > - mysqldump database from old server, and import to new mysql server > - rsync .../var/data over from old 1.0.1 server to the new 1.0.1 server > - run through the normal Upgrade notes > (http://invenio-software.org/blog/invenio-1.1.4) > > "make check-upgrade" is now complaining that bibsched is > running, even though I'm sure it isn't. There is a bug, we experienced here as well. Unfortunatley, no note in our wiki how we finally solved it, so just from the memory. At one point we found a snyced pid-file for bibsched that wasn't supposed to exist. So this has to go away. Another issue we experienced at this point is, that if you dump the db the dumper process from invenio is in bibsched with status running. As the queue lives on the db, you get this process back during loading of your dump, and again with status running, which is obviously wrong. If I remember correctly we had to remove all jobs from our pseudobibsched-queue, stop bibsched and proceed. (Probably also delete some left over pid-files.) What I also remember is, that the code that throws this error is pretty simple and that you can just grep for the string to know where it originates. RTFS then gives you a guideline how to proceed. Ah, and btw: we got tons of errors from the db upgrade "column bla in table blurb isn't supposed to exist but does. Check table defs: we want ... and we have ..." In all instances our tables were fine and just got some additional columns from an earlier upgrade that the upgrader thought she had to create first. I'd advise to check this carefully, however. (It's quite time consuming, unforutnately. Its bioprocessor based diff...) HTH :) -- Kind regards, Alexander Wagner Deutsches Elektronen-Synchrotron DESY Library and Documentation Building 01d Room OG1.444 Notkestr. 85 22607 Hamburg phone: +49-40-8998-1758 fax: +49-40-8994-1758 e-mail: [email protected]
