Jump to content

Strategy for migrating to a new server with different platform and version.

  • Please log in to reply
2 replies to this topic

#1 evt9m



  • Members
  • Pip
  • 1 posts

Posted 18 July 2019 - 07:21 PM

We are currently running version 2016.1/1405859 on FreeBSD.  Since this is no longer a supported platform we want to migrate to an Ubuntu 18.04 server so we can keep the server up to date as needed.

The documentation suggests that we should perform the upgrade and server migration as two separate steps, however in this case that doesn't appear to be possible since there are no newer versions of the server for BSD and I don't see a 2016.1 version available for Ubuntu 18.04.

Any suggestions for how I should approach this?  It's a small server with a single depot (~20GB) so it wouldn't be too much trouble to manually recreate the users on the new server the migrate over just the depot data if that's an easier approach?  I think that would cause me to lose the workspaces which isn't ideal, but I could live with that if I did the migration in between projects.

#2 Matt Janulewicz

Matt Janulewicz

    Advanced Member

  • Members
  • PipPipPip
  • 223 posts
  • LocationSan Diego, CA

Posted 26 July 2019 - 07:39 AM

You should be able to dump a checkpoint from the older BSD version and replay it to create db files on the Linux host. The only thing I think you'd normally have to worry about is the case-sensitivity of the filesystems but I'm pretty sure they would be case sensitive on both BSD and Ubuntu.

However, 2019.1 does some major recombobulating (technical term) of the database, which might be a lot to take in for the more paranoid admin like myself. If I were being especially paranoid/pedantic/untrusting, I might do something like this, fully testing it with a dry run before going live, of course:

0. Obtain duplicate p4 license for Ubuntu host.
1. Shut down BSD host.
2. Dump checkpoint of BSD host.
3. Replay checkpoint on Ubuntu host using p4d 2016.1 for Linux.
4. Rsync archives from BSD to Linux host.
5. Fire up and test Linux host.
6. Upgrade Linux host to latest 2018 series.
7. Maybe hold off on 2019.1 upgrade because it's new and was just patched. :)

I'm assuming your db is small enough where a checkpoint dump and replay won't take that long and downtime would be minimal. There are ways of leveraging an offline checkpoint (if you have an offline db) and creating a live replica of the BSD server which would minimize your downtime to about however long it takes to flip over the DNS entry, but I'll refrain from confusing everyone with that idea for now. :)
-Matt Janulewicz
Currently unemployed, looking for work in Boise, ID!

#3 Miles O'Neal

Miles O'Neal

    Advanced Member

  • Members
  • PipPipPip
  • 197 posts
  • LocationAustin. Texas. Y'all.

Posted 05 August 2019 - 07:05 PM

Matt's process is basically what we've done to move servers, irrespective of OS. We add a couple of extra steps to minimize downtime, but we have a much larger data set.

FWIW, our production servers use symlinks to the binaries (p4d, p4broker, etc.) We install the newer binaries alongside the old ones before we do anything else. Then we change the symlinks when we're ready to switch to the new versions.

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users