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 this release.
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 12 or 23.
The error is transient and non-specific and deployment should be retried.
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 operations.
The timezone information for the
would be incorrect when using parallel replication with a server
timezone other than GMT.