Archived

This forum has been archived. Please start a new discussion on GitHub.

3.3 upgrade went well

Just wanted to share my experience.

I just upgraded one of my nodes to 3.3, and rebuilt all of the software against it. It was relatively painless, just with a few minor modifications I had to make, but nothing that was Ice's fault by any means.

I did a manual db_dump | db_restore on one of my freeze databases to migrate it up from 4.5 top 4.6. I didn't see a way to do this with the freeze tools that came with Ice, but I'm sure I'm just missing something.

Also, since the main icegrid server is still running 3.2 (and will be for a while yet), I had to override the IceBox.Service.IceStorm property for the IceStorm server running at that node, because the template by default wants to set it to IceStormService,32 and that node needs ,33. I also think this means that all of my nodes are going to have to be ugpraded to 3.3 BEFORE I can upgrade icegrid on the server because then it will change all of the icestorm servers default to ,33 at that point.

All in all, very smooth. Next I just have to scour my code to find ways to take advantage of all of the new goodies.

Comments

  • bernard
    bernard Jupiter, FL
    Hi Caleb,

    Thanks for the upgrade report, it's good to hear that everything went smoothly.

    Regarding the Freeze (Berkeley DB) database upgrade, it should have been documented in the release notes. We'll fix this oversight in the next release.

    There is no special Freeze procedure or Freeze tool to perform this upgrade: Freeze is still storing exactly the same data, in the same format. However, we upgraded the version of Berkeley DB, and as a result when upgrading from Ice 3.2 to Ice 3.3, you have to upgrade your database from the "Berkeley DB 4.5" format to the new "Berkeley DB 4.6" format. This is fortunately straightforward, since the only relevant format change for Freeze was the log format change.

    From the Berkeley DB Upgrade Process:

    If the application has a Berkeley DB transactional environment, and the log files need upgrading but the databases do not, the application may be installed in the field using the following steps:

    1. Shut down the old version of the application.
    2. Still using the old version of Berkeley DB, run recovery on the database environment using the DB_ENV->open method or the db_recover utility.
    3. If you used the DB_ENV->open method to run recovery, make sure that the Berkeley DB environment is removed using the DB_ENV->remove method or an appropriate system utility.
    4. Archive the database environment for catastrophic recovery. See Archival procedures for more information.
    5. Recompile and install the new version of the application.
    6. Force a checkpoint using the DB_ENV->txn_checkpoint method or the db_checkpoint utility. If you use the db_checkpoint utility, make sure to use the new version of the utility; that is, the version that came with the release of Berkeley DB to which you are upgrading.
    7. Restart the application.

    Naturally, I recommend to use the db_ utilities, and not write your own upgrade program!

    Cheers,
    Bernard