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 2
  • views 4
  • 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
#3
robinshen ADMIN ·

As drdt mentioned, the key is to retain database data, artifacts storage, and application settings. For database backup/restore, check this also:

Data Management | QuickBuild

Data backup and restore

wiki.pmease.com

For artifacts storage, just copy over the global storage directory specified in "administration / system setting / global storage directory". If this directory is changed after copy, make sure to update this setting as well (you may update this setting after new application is started).

For application settings, you may just copy over QB installation directory to your new server. And make sure that:

  1. Change the directory to be owned by new user in your system
  2. Edit "conf/hibernate.properties" to point to your new database
  3. Edit "bin/server.sh" for property "RUN_AS_USER" to make sure it reflects the new user
  4. Install service by running "sudo bin/server.sh install"

If you have agents connected server, you will need to update "conf/node.properties" of each agent to point to new server, or make sure the server address is not changed, so that you do not need to update each agent. Agents will be connected back if server address is not changed.

Log in to reply