A.7. Continuent Tungsten 4.0.1 GA (20 Jul 2015)
Continuent Tungsten 4.0.1 is a bugfix release that
contains critical fixes and improvements.
The following issues may affect the operation of Continuent Tungsten
and should be taken into account when deploying or updating to
For security purposes you should ensure that you secure the
following areas of your deployment:
Ensure that you create a unique installation and deployment
user, such as tungsten, and set the correct file permissions
on installed directories. See
Section B.2.3, “Directory Locations and Configuration”.
When using ssh and/or SSL, ensure that the ssh key or
certificates are suitably protected. See
Section B.2.2.2, “SSH Configuration”.
Use a firewall, such as iptables to
protect the network ports that you need to use. The best
solution is to ensure that only known hosts can connect to
the required ports for Continuent Tungsten. For more information
on the network ports required for Continuent Tungsten operation,
see Section B.2.2.1, “Network Ports”.
If possible, use authentication and SSL connectivity between
hosts to protext your data and authorisation for the tools
used in your deployment. See
Section 2.7, “Deploying SSL Secured Replication and Administration” for more information.
Under certain circumstances, the
rsync process can
randomly fail during the installation/ deployment process when
using the staging method of deployment. The error code returned
by rsync may be
The error is transient and non-specific and deployment should be
Improvements, new features and functionality
The manager would incorrectly shun the entire remote service
when the site appears to be unreachable, shunning the remote
composite datasource including the physical datasources. This
has been updated so that only the composite data source and not
underlying physical data sources are shunned.
The manager would not put relay replicators
ONLINE after being
When running the trepctl reset command on a
master, DDL statements could be placed into the binary log that
would delete corresponding management tables within slaves.
Binary logging for these operations is now suppressed for these
The timezone information for the
would be incorrect when using parallel replication with a server
timezone other than GMT.