SearchHere, we show you how you can migrate one or more components of the Varnish Controller installation to new servers.
The process of migrating an installation is similar to a new installation. It differs from a new installation by the necessity to keep current parameters and, in case of migrating the PostgreSQL database, backing up the database on the old server and restoring it on the new one.
Directly migrating either an Agent, a Router, or an API-GW is easy, but cannot be tested and results in an service interruption.
To avoid downtimes, we recommend to not just migrate an existing installation, but:
If it cannot be avoided to directly migrate a service, make sure to follow these steps:
Before migrating a Brainz node, make sure to collect all configuration values from files, command line parameters and environment variables to transfer them to the new installation.
Make sure all Brainz instances are connecting to the same database.
As long as at least one Brainz installation is active, you can add and remove Brainz installations without downtimes of the Varnish Controller.
Thus, a migration can easiest be performed by the following order of steps:
See the Brainz installation reference for details.
NATS can be run either on a standalone system or in a cluster configuration. It allows to minimize downtimes if NATS already runs in a cluster.
nats-server parameters of any Controller
component (Brainz, Agent, Router, API-GW).nats-server parameter of all components that refer to the old NATS server. Enter the
new server and restart the Controller component. You can do this for one component at a time with
no need to maintain one specific nats-server parameter among all components.Unlike other migrations described here, moving a single NATS server is best performed in one step. Do not convert a singe server to a temporary cluster. This avoids the multiple downtimes associated with converting NATS servers to a cluster and back to a single node again. It also lowers the risks of misconfiguration.
For migrating a PostgreSQL database to a new server, a downtime of the Controller is necessary. We recommend to restore and a dump of the database on the new machine as a test before starting the actual migration.
The singe steps of the migration are:
Setup a your new database server as described in the
Postgresql installation chapter, without
creating a new database with the createdb command as it is described in the
Create an application user and database
chapter.
Create the new user (or the new “role”, as it is called in the PostgreSQL terminology) with exactly the same name as on the old one. Otherwise, restoring the database as described will fail.
Creating the database itself will be done automatically when restoring the database from the dump.
Stop all running Brainz instances and other pieces of software that are connected to the database. This is important to guarantee a consistent database on the new server.
You can check for remaining Brainz connections with the SQL command
SELECT * FROM pg_stat_activity;
No connections to your Controller-database should show up, except maybe the SQL client you’re using
to run the command. PostgreSQL-internal server processes be be identified by [NULL] values for
datid and datname can be ignored.
Extracting all contents (dumping) is done by the pg_dump command. We recommend to use wit with the
--create and --format=c parameters. --create creates a new database upon restoring and
--format=c creates the dump in a custom format that allows for a faster restore.
Transfer the created dump to the new database host. There, you can restore the dump with the
pg_restore command. It requires no extra parameters other than those required for login.
You can pipe the output of pg_dump directly into pg_restore. The following example assumes that
you execute both commands on the old database server:
pg_dump -U [POSTGRES_USERNAME] --create --format=c | pg_restore -h [NEW_POSTGRES_SERVER] -U [POSTGRES_USERNAME]
Verify the restored database. You should get exactly one row for the following SQL command:
SELECT * FROM pg_catalog.pg_tables WHERE tablename = 'migrations';
Enable your regular backup routine. If you use WAL archiving, it’s the best point in time to do the base backup.
Go though all Brainz instances and reconfigure the connection parameters to the new database. Once the connection parameter has been updated,the Brainz instance can be restarted again.