3.3. Continuent Tungsten 4.0.6 GA (8 December 2016)

Version End of Life. 31 October 2018

Release Notes 4.0.6 is a bugfix release that contains critical fixes and improvements.

Known Issue

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 Directory Locations and Configuration (in [Continuent Tungsten 4.0 Manual]).

    • When using ssh and/or SSL, ensure that the ssh key or certificates are suitably protected. See SSH Configuration (in [Continuent Tungsten 4.0 Manual]).

    • 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 Network Ports (in [Continuent Tungsten 4.0 Manual]).

    • If possible, use authentication and SSL connectivity between hosts to protext your data and authorisation for the tools used in your deployment. See Deploying SSL Secured Replication and Administration (in [Continuent Tungsten 4.0 Manual]) for more information.

Improvements, new features and functionality

  • Installation and Deployment

    • The release has been updated to correctly operate with CentOS v7.0 and higher. This was related to the changes made to the operation of the systemd tool used to manage startup and shutdown scripts.

      Issues: CONT-211, CONT-1552

    • When performing a persmissions check within tpm (in [Continuent Tungsten 4.0 Manual]), changes to the way password and other information is confirmed has been updated to work correctly with MySQL 5.7. In particular, due to the way passwords are now stored and used, tpm (in [Continuent Tungsten 4.0 Manual]) will confirm the configured user and password by checking that login functions correctly.

      Issues: CONT-1578

    • During installation, tpm (in [Continuent Tungsten 4.0 Manual]) will no longer check the connector credentials if the connector has been configured to operate in bridge mode (in [Continuent Tungsten 4.0 Manual]) if application specific credentials are not supplied. If the --application-user (in [Continuent Tungsten 4.0 Manual]) and --application-password (in [Continuent Tungsten 4.0 Manual]) options are provided, tpm (in [Continuent Tungsten 4.0 Manual]) will run the same checks even if bridge mode has been selected.

      Issues: CONT-1580

Bug Fixes

  • Installation and Deployment

    • If the cluster is put into maintenance mode, but the coordinator node, or the terminal session that put the cluster into maintenance mode fails, the cluster would stay in maintenance mode. The node is now tracked, and if the node goes away for any reason, the cluster will be returned to the mode it was in before being placed into maintenance node.

      Issues: CONT-1535

    • Running tpm connector (in [Continuent Tungsten 4.0 Manual]) while multi_trepctl (in [Continuent Tungsten 4.0 Manual]) is running on the same host would fail with the error:

      ERROR >> db2 >> There is already another Tungsten installation script running

      Issues: CONT-1572

  • Tungsten Connector

    • In the event of a statement being explicitly requested to execute on a slave and there being an error, it's possible that the Connector will not retry the statement. The behaviour has been updated to retry and/or reconnect to execute the statement on the slave.

      Issues: CT-22

  • Tungsten Manager

    • It was possible for a race condition within the manager to create a cluster that starts up with a shunned master service.

      Issues: CT-2

    • The generated mysql_read_only script would use password on the command line, and could execute a query that returned multiple rows. Both issues could cause issues during executation, particularly for MySQL 5.6 and later.

      Issues: CONT-1570

Continuent Tungsten 4.0.6 Includes the following changes made in Tungsten Replicator 4.0.6

Continuent Tungsten 4.0.6 is a bugfix release that contains critical fixes and improvements to the Continuent Tungsten 4.0.5 release.

Behavior Changes

The following changes have been made to Release Notes and may affect existing scripts and integration tools. Any scripts or environment which make use of these tools should check and update for the new configuration:

  • For compatibility with MySQL 5.7, the tpm (in [Tungsten Replicator 4.0 Manual]) command will now check for the super_read_only setting and warn if this setting is enabled.

    Issues: CONT-1039

  • For compatibility with MySQL 5.7, the tpm (in [Tungsten Replicator 4.0 Manual]) command will use the authentication_string field for validating passwords.

    Issues: CONT-1058

  • For compatibility with MySQL 5.7, the tpm (in [Tungsten Replicator 4.0 Manual]) command will now ignore the sys schema.

    Issues: CONT-1059

Known Issues

The following issues may affect the operation of Continuent Tungsten and should be taken into account when deploying or updating to this release.

  • Installation and Deployment

    • When running tpm update (in [Tungsten Replicator 4.0 Manual]) preperties set during the initial install could be reset or changed to their default value.

      Issues: CONT-1579

  • Command-line Tools

    • Running multi_trepctl (in [Tungsten Replicator 4.0 Manual]) in a multi-site, multi-master (MSMM) deployment could fail to report all of the running replication processes.

      Issues: CONT-1585

  • Core Replicator

    • There is a limit in the communication protocal for the replicator which limits the number of fragments within a single transaction in the THL to 32768. Although this is not a limit in the THL format, it is a limit in the protocol used to exchanged the THL information between replicators.

      The size of this value, and therefore, the maximum number of fragments cannot be increased without creating an incompatible change within the replicator. This creates a limit to the maximum size of a single transaction that can be replicated. Although this figure cannot be altered, the size of each individual fragment can be increased. The default setting is 1,000,000, creating a limit of approximately 32GB.

      To increase the fragment size, set the value of the property replicator.extractor.dbms.transaction_frag_size (in [Tungsten Replicator 4.0 Manual]). For example, increasing the value to 2,000,000 would increase the maximum THL transaction size to approximately 64GB.

      Care should be taken when increasing this value, as it also increases the amount of memory required to handle the transaction.

      Issues: CONT-1574

  • Filters

    • There is a known issue with the fixmysqlstrings.js filter. When translating BINARY or VARBINARY datatypes into a hex value, if the encoding set for the MySQL and replicator instance is not UTF-8, an implied character set conversion can take place. This leads to a corruption of the information when it is turned into a hex string. This is due to limitations of the internal datatypes available within the JavaScript environment used for the translation.

      Issues: CONT-1508

Improvements, new features and functionality

  • Installation and Deployment

    • Due to changes in the datatypes available in MySQL 5.7 and the supported datatypes within Continuent Tungsten, and coinciding with changes to the way this information is available, the tpm (in [Tungsten Replicator 4.0 Manual]) checks for compatibility may no longer highlight important option changes. For example, virtual columns and JSON columns in MySQL 5.7 are not replicated. During installation, if tpm (in [Tungsten Replicator 4.0 Manual]) identifies that MySQL 5.7 is in use, the following message will be reported:

      IMPORTANT: The replicator is unable to replicate tables that have
      columns defined as type JSON or that utilise VIRTUAL GENERATED values!
      The use of these features will cause replication to fail. If you want
      tpm to check for these add --mysql-allow-intensive-checks to the
      configuration. Be aware that the checks will query the
      information_schema and if you have thousands of tables this may affect
      other queries while the check runs. Otherwise, if you have confirmed
      manually that JSON or VIRTUAL GENERATED columns are not being used,
      you can skip this check by
      adding --skip-validation-check=MySQLUnsopportedDataTypesCheck to your

      To address this issue, when using tpm (in [Tungsten Replicator 4.0 Manual]) during an installation, more intensive checks for tables with unsupported types can be performed. For example, when checking the special column types used in all tables within an existing installation, tpm (in [Tungsten Replicator 4.0 Manual]) must check each table individually. As this can increase the load on the server during installagtion, tpm (in [Tungsten Replicator 4.0 Manual]) by default does not perform these checks. Instead, these checks can be enabled by using the --mysql-allow-intensive-checks option during configuration. Enabling this option provides for a much more detailed check, but may cause the installation process to take longer.

      Issues: CONT-1551, CONT-1576

  • Core Replicator

    • If the slave THL file ends with an event that was ultimately filtered, and the the replicator master and slave roles are then switched, the new master could generate an incorrect sequence number.

      Issues: CONT-1545

Bug Fixes

  • Installation and Deployment

    • The Ruby Net::SSH libraries used by tpm (in [Tungsten Replicator 4.0 Manual]) have been updated to the latest version. This addresses issues with SSH and staging based deployments, including KEX algorithm errors.

      Issues: CT-16

    • The built-in check for InnoDB did not work for MySQL 5.6 and could fail to identify InnoDB support on the MySQL server.

      Issues: CONT-1577

  • Core Replicator

    • Extraction from the MySQL binary log would fail if the binary log event ID is bigger than a Java Int. This could be triggered if a large (greater than 2B) transaction is inserted into the binary log.

      Issues: CONT-1541