Skip to main content
Version: Develop

Migration

This document describes options to migrate data from an older a9s PostgreSQL Service Instance using an older PostgreSQL version to an a9s PostgreSQL Service Instance with a higher version.

Custom Parameter copy_from

The application developer can migrate data from an older instance to a newer one using the custom parameter copy_from, see Dump and Restore From Origin Instance to New Instance.

If an error happens during the migration and no syslog endpoint has been specified, the platform operator can take a look at the first BOSH VM of the deployment in the following files:

  • /var/vcap/sys/log/postgresql-ha/post-start.*
  • /var/vcap/sys/log/postgresql-ha/copy_from.*
caution

Ensure that all objects in all databases belong to the cfuser before running copy_from.

Leveraging maintenance_work_mem

Depending on the size of your database the execution of copy_from can take a long time to finish due to the operations that it uses. As explained here the copy_from custom parameter makes use of the pg_dump and pg_restore calls behind the scenes, this allows us to leverage the value of maintenance_work_mem property to cut down on execution time, as this parameter is the maximum amount of memory that certain (maintenance) operations, such as VACCUM or INDEX, can use.

If you choose to follow this approach, please keep in mind that the value of maintenance_work_mem must be set when starting the copy_from process and should be set back to its previous value after the process finishes. This means that, if you decide to increase the value of maintenance_work_mem from 64MB to 120MB, you should set it back to 64MB at the end of the migration process.