B.3. Continuent Tungsten 2.0.3 GA (1 Aug 2014)

This is a recommended release for all customers as it contains important updates and improvements to the stability of the manager component, specifically with respect to stalls and memory usage that would cause manager failures.

We recommend Java 7 for all Continuent Tungsten 2.0 installations. Continuent are aware of issues within Java 6 that cause memory leaks which may lead to excessive memory usage within the manager. This can cause the manager to run out of memory and restart, without affecting the operation of the dataservice. These problems do not exist within Java 7.

Behavior Changes

The following changes have been made to Continuent Tungsten 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:

  • Within composite clusters, TCP/IP port 7 connectivity is now required between managers on each site to confirm availability.

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.

  • The default behavior of the manager is to not fence a datasource for which a replicator has stopped or gone into an error state. This was implemented to prevent reducing the overall availability of the deployed service. There are cases and deployments where clusters should not operate with replicators in stopped or error states. This could be configure by changing the following properties to true according to the master or slave role requirements:

    policy.fence.slaveReplicator=false 
    policy.fence.masterReplicator=false

    If they are set to true, the manager should fence the datasource by setting it to a 'failed' state. When this happens, and the datasource is a master, failover will occur. If the datasource is a slave, the datasource will just stay in the failed state indefinitely or until the replicator is back in the online state, in which case the datasource will be recovered to online.

    At present the setting of these properties are not honored.

    Issues: TUC-2241

Improvements, new features and functionality

Bug Fixes

  • Installation and Deployment

    • To ensure that the correct number of the managers and witnesses are configured within the system, tpm has been updated to check and identify potential issues with the configuration. The installation and checks operate as follows:

      • If there are an even number of members in the cluster (i.e. provided to --members option):

        • If witnesses are provided through --witnesses, continue normally.

        • If witnesses are not provided through --witnesses, an error is thrown and installation stops.

      • If there are an odd number of members in the cluster (i.e. provided to --members option):

        • If witnesses are provided through --witnesses, a warning is raised and the witness declaration is ignored.

        • If witnesses are not provided through --witnesses, installation continues as normal.

      The number of members is calculated as follows:

      Issues: TUC-2105

    • If ping traffic was denied during installation, then installation could hang while the ping check was performed. A timeout has now been added to ensure that the operation completes successfully.

      Issues: TUC-2107

  • Backup and Restore

    • When using xtrabackup 2.2.x, backups would fail if the innodb_log_file_size option within my.cnf was not specified. tpm has been updated to check the value and existence of this option during installation and to provide a warning if it is not set, or set to the default.

      Issues: TUC-2224

  • Tungsten Connector

    • The connector will now re-connect to a MySQL server in the event that an opened connection is found closed between two requests (generally following a wait_timeout expiration).

      Issues: TUC-2163

    • When initially starting up, the connector would open a connection to the configured master to retreive configuration information, but the connection would never be closed, leading to open unused connections.

      Issues: TUC-2166

    • The cluster status output by the tungsten cluster status within a multi-site cluster would fail to display the correct states of different data sources when an entire data service was offline.

      Issues: TUC-2185

    • When the connector has been configured into read-only mode, for example using --application-readonly-port=9999, the connector would mistakenly route statements starting set autocommit=0 to the master, instead of being routed to a slave.

      Issues: TUC-2198

    • When operating in bridge mode, the connector would retain the client connection when the server had closed the connection. The connector has been updated to close all client connections when the corresponding server connection is closed.

      Issues: TUC-2231

  • Tungsten Manager

    • The manager could enter a situation where after switching a relay on one physical service, remote site relay is incorrectly reconfigured to point at the new relay. This has been corrected so that reconfiguration no longer occurs in this situation.

      Issues: TUC-2164

    • Recovery from a composite cluster failover could create a composite split-brain situation.

      Issues: TUC-2178

    • A statement of record (SOR) cluster would be unable to recover a failed dataservice.

      Issues: TUC-2194

    • A composite datasource would not go into failsafe mode if all the managers within the cluster were stopped.

      Issues: TUC-2206

    • If a composite datasource becomes isolated due to a network partition, the failed datasource would not go into failsafe mode correctly.

      Issues: TUC-2207

    • If a witness became isolated from the rest of the cluster, the rules would not exclude the failed witness and this could lead to memory exhaustion.

      Issues: TUC-2214

  • Documentation