8.15.1. Upgrading Installations using update
For installation where
tungsten-installer was used to
perform the original installation and deployment, the
update tool must be used. This
includes all installations where the original deployment was in a release
of Tungsten Replicator 2.1.0 or earlier; any installation where
tungsten-installer was used with
Tungsten Replicator 2.1.1, or where an installation originally took place
using tungsten-installer that has
been updated to Tungsten Replicator 2.1.1 or later.
To perform the upgrade:
Download the latest Tungsten Replicator package to your staging server.
Stop the replicator service on the host:
The replicator service must be switched off on each machine before
the upgrade process is started. Multiple machines can be updated at
the same time, but each datasource must have been stopped before the
upgrade process is started. Failing to shutdown the replicator
before running the upgrade process will generate an error:
ERROR >> host1 >> The replicator in /opt/continuent is still running. »
You must stop it before installation can continue. (HostReplicatorServiceRunningCheck)
Run the ./tools/update command.
To update a local installation, you
must supply the
parameter to specify the installation location of your service.
INFO >> host1 >> Getting services list
INFO >> host1 >> .
Processing services command...
appliedLatency : 0.405
role : master
serviceName : firstrep
serviceType : local
started : true
state : ONLINE
Finished services command...
NOTE >> host1 >> Deployment finished
The replicator will be upgraded to the latest version. If your
installation has only a single service, the service will be restarted
automatically. If you have multiple services, the replicator will need
to be restarted manually.
To update a remote installation, you
must have SSH installed and configured to support password-less access
to the remote host. The host (and optional username) must be supplied
on the command-line:
./tools/update --host=host2 --release-directory=/opt/continuent
When upgrading a cluster, you should upgrade slaves first and then update
the master. You can avoid replication downtime by switching the master to
an upgraded slave, upgrading the old master, and then switching back