To upgrade an existing installation on Tungsten Clustering, the new distribution
must be downloaded and unpacked, and the included tpm
command used to update the installation. The upgrade process implies a small
period of downtime for the cluster as the updated versions of the tools are
restarted, but downtime is deliberately kept to a minimum, and the cluster
should be in the same operation state once the upgrade has finished as it
was when the upgrade was started.

4.4.1. Upgrading using the Staging Method (with
ssh Access)

Note

Warning

Before performing and upgrade, please ensure that you have checked the
Appendix B, Prerequisites, as software and system requirements may
have changed between versions and releases.

To perform an upgrade of an entire cluster from a staging directory
installation, where you have ssh access to the other
hosts in the cluster:

On your staging server, download the release package.

Unpack the release package:

shell> tar zxf tungsten-clustering-5.3.2-525.tar.gz

Change to the extracted directory:

shell> cd tungsten-clustering5.3.2-525

The next step depends on your existing deployment:

If you are upgrading a Multi-Site,
Multi-Master deployment:

If you installed the original service by making use of the
$CONTINUENT_PROFILESand$REPLICATOR_PROFILES environment variables, no
further action needs to be taken to update the configuration
information. Confirm that these variables are set before
performing the validation and update.

If you did not use these environment variables when deploying the
solution, you must load the existing configuration from the
current hosts in the cluster before continuing by using
tpm fetch:

Note

During the update process, tpm may report errors
or warnings that were not previously reported as problems. This is
due to new features or functionality in different MySQL releases and
Tungsten Clustering updates. These issues should be addressed and the
tpm update command re-executed.

The following additional options are available when updating:

--no-connectors (optional)

By default, an update process will restart all services, including
the connector. Adding this option prevents the connectors from
being restarted. If this option is used, the connectors must be
manually updated to the new version during a quieter period. This
can be achieved by running on each host the command:

shell> tpm promote-connector

This will result in a short period of downtime (couple of seconds)
only on the host concerned, while the other connectors in your
configuration keep running. During the upgrade, the Connector is
restarted using the updated software and/or configuration.

A successful update will report the cluster status as determined from
each host in the cluster:

4.4.2. Upgrading when using INI-based configuration, or without
ssh Access

To perform an upgrade of an individual node, tpm can be
used on the individual host. The same method can be used to upgrade an
entire cluster without requiring tpm to have
ssh access to the other hosts in the dataservice.

Warning

Before performing and upgrade, please ensure that you have checked the
Appendix B, Prerequisites, as software and system requirements may
have changed between versions and releases.

Important

Application traffic to the nodes will be disconnected when the connector
restarts. Use the --no-connectorstpm option when you upgrade to prevent the connectors
from restarting until later when you want them to.

To upgrade a cluster using this method there are two methods, switch and
no-switch. The switch method employs a manual cluster failover to a new
master, the no-switch method does not. Which method you choose depends
upon your needs.

4.4.2.1. Upgrading Using the No-Switch Method

To use the no-switch method of upgrading:

Place the cluster into maintenance mode

Upgrade the slaves in the dataservice. Be sure to shun and welcome
each slave.

Upgrade the master node

Important

Replication traffic to the slaves will be delayed while the
replicator restarts. The delays will increase if there are a large
number of stored events in the THL. Old THL may be removed to
decrease the delay. Do NOT delete THL that has not been received
on all slave nodes or events will be lost.

Upgrade the connectors in the dataservice one-by-one

Important

Application traffic to the nodes will be disconnected when the
connector restarts.

Place the cluster into automatic mode

4.4.2.2. Upgrading Using the Switch Method

To use the switch method of upgrading:

Upgrade the slaves in the dataservice. Be sure to shun and welcome
each slave.

Switch the current master to one of the upgraded slaves

Important

Application and replication traffic will be delayed while the
switch occurs.

Upgrade the original master node which is now a slave. Be sure to
shun and welcome it.

Upgrade the connectors in the dataservice one-by-one

Important

Application traffic to the nodes will be disconnected when the
connector restarts.