Your browser was unable to load all of the resources. They may have been blocked by your firewall, proxy or browser configuration.
Press Ctrl+F5 or Ctrl+Shift+R to have your browser try again.

QuickBuild

Transferring build server to a new linux host and OS, looking for ideas regarding data integrity #4711

support request question
#1
tomz ·

We are likely to be moving off of CentOs linux for our farm build server and onto a recent Amazon Linux version. During the transition we want to maintain data integrity on the server database (for instance, we wouldn't want build IDs to restart at 1). We have developed our own telemetry to track build history in an external DB in a format that helps us build useful powerbi graphs, and this system would also need to be reset if we just start fresh with a new quick build server install.

What is the proper/best/recommended method to move a build server to another host without losing any history and preferably keeping the existing build database?

  • replies 1
  • views 3
  • stars 0
#2
drdt ·

I have done this several times over the years, for

  • migration to a new server
  • testing upgrades
  • maintaining a parallel test environment

The most straightforward way is to use the QuickBuild backup facility to back up the configurations locally and then use restore.sh to import it into the new instance. This preserves all of the build and configuration IDs. I wrote a shell script to trigger the QB backup via the RESTful API and save it in a file name similar to the one generated by QB's automated backup. This has one disadvantage in that QB has to be running to take the backup.

If you are using an external database on a separate platform, it is even simpler; just copy over the hibernate file to the new instance, pointing it at the same external database. Just make sure both instances are never running at the same time. I prefer to create a new database table for each instance, and then use the database's own utilities to replicate the data. That way I can bring up both instances after the migration and verify.

Separately, you will also need to

  • copy or move the storage directory to the new instance
  • update the node.properties on all of the agents to point to the new server instance
  • re-authorize all of the agents on the new server instance
Log in to reply