B.4. Tungsten Replicator 4.0.4 GA (24 Feb 2016)

Tungsten Replicator 4.0.4 is a bugfix release that contains critical fixes and improvements to the Tungsten Replicator 4.0.3 release.

Known Issues

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

  • Installation and Deployment

    • 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.

      Issues: CONT-1343

  • Core Replicator

    • Due to a bug within the Drizzle JDBC driver when communicating with MySQL, using the optimizeRowEvents options could lead to significant memory usage and subsequent failure. To alleviate the problem. For more information, see Drizzle JDBC Issue 38.

      Issues: CONT-1115

Bug Fixes

  • Installation and Deployment

    • When validating the existence of MyISAM tables within a MySQL database, tpm would use an incorrect method for identifying MyISAM tables. This could lead to MyISAM tables not being located, or legitimate system-related MyISAM tables triggering the alert.

      Issues: CONT-938

  • Command-line Tools

  • Core Replicator

    • When events are filtered on a master, and a slave replicator reconnects to the master, it is possible to get the error server does not have seqno expected by client. The replicator has been updated to correctly supply the sequence number during reconnection.

      Issues: CONT-1384, CONT-1525

    • Binary data contained within an SQL variable and inserted into a table would not be converted correctly during replication.

      Issues: CONT-1412

    • In some situations, statements that would be unsafe for parallel execution were not serializing into a single threaded execution properly during the applier phase of the target connection.

      Issues: CONT-1489

    • CSV files generated during batch loading into datawarehouses would be created within a directory structure within the /tmp. On long-running replictors, automated processes that would clean up the /tmp directory could delete the files causing replication to fail temporarily due to the missing directory.

      The location where staging CSV files are created has now been updated. Files are now stored within the $CONTINUENT_HOME/tmp/staging/$SERVICE directory, following the same naming structure. For example, if Tungsten Replicator has been installed in /opt/continuent, then CSV files for the service alpha, CSV files for the first active applier channel will be stored in /opt/continuent/tmp/staging/alpha/staging0.

      Issues: CONT-1500

    • The timeout used to read information from the MySQL binary logs has been changed from a fixed period of 120 seconds to a configurable parameter. This can be set by using the --property=replicator.extractor.dbms.binlogReadTimeout=180 property during configuration tpm.

      Issues: CONT-1528

    • When reconnecting within a multi-site multi-master deployment, the session level logging of updates would not be configured correctly in the re-opened session.

      Issues: CONT-1544

    • Within an SOR cluster, an isolated relay site would not resume replication correctly.

      Issues: CONT-1549

  • Filters

    • The pkey filter could force table metadata to be updated when the update was not required.

      Issues: CONT-1162

    • When using the dropcolumn filter in combination with the colnames, an issue could arise where differences in the incoming Schema and target schema could result in incorrect SQL statements. The solution is to reconfigure the colnames on the slave not to extract the schema information from the database but instead to use the incoming data from the source database and the translated THL.

      Issues: CONT-1495