These are exhaustive notes from the migration from fedora 2.2.1 to fedora 3.1 on an old test server with about 80K objects. This test was the first of three migrations which would include our development server and ultimately our production server with nearly half a million objects. When possible, I included stack traces so that users who experience the same errors in the same context may learn from my mistakes.
- update the software without losing functionality
- switch from oracle to mysql as the backing database
- migrate tools and services to accommodate changes in the fedora API and model
- Index service
- PURL resolution
- Ingest service
Steps (including missteps)
Set up database
Set up data directories
- updated my .bash_profile to reset FEDORA_HOME
- created a new objects directory
- copied all objects from existing object directory (took several minutes to copy just under one GB of files)
Install fedora 3.1
- ran the installer
- indicated new database
- used the included mysql connector (turned out to be a mistake-- see below)
- enabled JMS
- enabled resource index
- selected "other" when prompted for servlet engine (because for this case, I'll can install it in the same tomcat instance as 2.2 with some clever restarting and file movement)
- indicated new database
- updated the fedora.fcfg to include e-mail addresses, our default pid namespace (iudl) and to point to the new objects directory and old datastream directory
Migration guide (http://fedora-commons.org/confluence/display/FCR30/Upgrading+from+2.x)
- added jrdf-0.5.5.4.jar to the "lib" directory within analyzer.jar (found this file on the internet, as suggested by this mailing list comment http://sourceforge.net/mailarchive/message.php?msg_id=4909E97D.2060503%40fedora-commons.org)
- Alright... they really wanted me to start and stop fedora. Apparently the first time you start it, it creates tables if they aren't present. For this reason, my next migration test will use a parallel instance of tomcat that I can start and stop.
- After deploying, starting and stopping the new fedora, the analyzer worked properly except for a lot of logger errors, and the presence of duplicate items which I corrected and shouldn't have been present in the first place.
- This logger error could be corrected by adding slf4j-api-1.5.2.jar and slf4j-jdk14-1.5.2.jar into the "lib" directory of the analyzer.jar. These files can be found in the fedorawar/WEB-INF/lib directory (or your fedora.war file).
- The analyzer took around 44 minutes, but this was probably largely increased because I hadn't fixed the logger error at that time. Later runs after adding the appropriate jar files were much better.
After painstakingly paring down the nearly 50 content models identified to the 5 or 6 we intended, I ran the generator as describe in the instructions without problems. (Add the same jar files to the "lib" directory)
- The transformer application ran smoothly both as a dry run and for real.
As it turns out, the include MySQL connector jar includes several class files built for java 6, while this installation process was using java 5. I found an old version of the connector that was built for java 5 and replaced the existing file and updated all references to it.
Resource Index rebuild
I encountered no problems rebuilding the resource index or in the remaining steps.
Changes that could affect other systems
- Requests for datastreams that don't exist now return a 404 rather than a blank page
- Requests for datastreams for which the user is denied access return a 403 rather than a blank page