IT Support Small Medium Business

I recently upgraded and migrated a production instance of Confluence wiki. The task is interesting. The production instance of Confluence version 2.1.2 ran on a SELS 9 server with its ‘data’ directory NFS mounted. It uses external user management (CAS) with LDAP backend, plus a v8 DB2 database as the external database to store content of the wiki instead of the built-in suit-for-trial-only database. The new instance runs on RHEL 5 AS server with a v9 DB2 database.

My initial plan is to migrate the same old instance to the new data center, then upgrade whenever. Bossman overwrote the plan thinking it’d be a simple task to upgrade and migrate in one shot. Neither of us sees any feature in the new release as a deal-maker. I  guess common sense doesn’t always  win

• The upgrade went smoothly, once I finally located the upgrade page on the vendor’’s site.
  • The upgrade instruction page is not diretly linked to the upgrade instruction links in the release notes. I guess this is the problem with any WIKI.
  • The information is there somewhere in the WIKI. In order to find what you want, you just need to know your way around first!!!
• local config files used to be stored under /data/config. Now they get stored in new tables such as BANDANA. The main config was imported automatically. The mail server configuration was somehow lost and had to be configured manually after the upgrade.
• ‘Content Reindex’ from the Administration panel reports 100% when it really meant was ‘best efforts’ 100%! None of the 5600 attachments were indexed since the upgraded instance tried to locate them by attachID, the primary key for the ‘attachment’ table.
  • All Confluence releases prior to 2.2 has attachments stored as a file named after the version number under a directory named after the file name.
  • The upgrade documentation fails to mention this biggie when it mentions other gotchas for the 2.1.x releases. To its credit, it did instruct readers to read all notes from all intermediate major releases.
  • initially we thought it could be a bug or a misconfiguration. Correlating the apache log and knowledge of the attachment table, we know the second number is the attachID when it failed to locate pageID/attachID. Even with this knowledge, it takes me nearly two hours to come up (if not stumble upon) with a good comination of search terms to find the JIRA tickets reporting this Confluence 2.2 new feature, storing attachment files as a number (attachment ID) instead of real names. The wicked WIKI!
  • I ended up writing a perl script to dump contents of the ‘attachment’ table to prepare a simple shell script consisting of 5600 lines of ‘mv’ statements.
• No need to do the external database migration seperately, other than creating an empty new database with an application user account granted ADM rights.
  • Confluence, like its twin brother JIRA, can export (or manual backup) everything to a big zip file then imported to a new instance. This includes entities.xml, a big XML file for the page contents stored in the external database.
  • In fact, the upgrade went awry at different points with the external database replicated seperately from the old instance.
• The export form under ‘backup and restore’ of the ‘Administration’ panel seems to be buggy. For three exports we tried on different days, each submission causes the job got kicked off several times, each twenty thirty minutes apart. I suspect accidental repost of the form data by our confluence admin. Then again I explicitly instructed the Confluence administrators to leave that page alone upon starting the manual backup.
• The upgrade tasks are handled automatically by a bunch of java classes. No easy way to back out or determine which one is done and which one is not or how to repapply a single task. SQL DDL statements are hardcoded in the java classes to update the database schema. When it works smoothly, it is OK. One couldn’t care less. When it doesn’t, it is such a horrible design.
• If your CAS is configured as ours in osusers.xml, os_user and users tables are useless to you.

Add to: