Tungsten Clustering 6.1.5

Build: 20

Release Date: 5 Aug 2020

End of Life Date: 15 Aug 2024

Product End of Life

This release is past End of Life.

Release 6.1.5 is a small interim bug fix with a number of issues resolved within the Core Replicator, and a specific issue within Tungsten Connector in Multi-Cluster Environments.

Known Issue (1)

The following issues are known within this release but not considered critical, nor impact operation. They will be addressed in a subsequent patch release.

Core Replicator (1)

• In MySQL release 8.0.21 the behavior of CREATE TABLE ... AS SELECT ... has changed, resulting in the transactions being logged differently in the binary log. This change in behavior will cause the replicators to fail.

  Until a fix is implemented within the replicator, the workaround for this will be to split the action into separateCREATE TABLE ... followed by INSERT INTO ... SELECT FROM... statements.

  If this is not possible, then you will need to manually create the table on all nodes, and then skip the resulting error in the replicator, allowing the subsequent loading of the data to continue.

  Issue: CT-1301

Bug Fixes (4)

Core Replicator (3)

• Fixes a bug in the Drizzle Driver whereby a failing prepared statement that exceeds 1000 characters would report aString index out of range: 999 error rather than the actual error.
  Issue: CT-1303

• If filtering is in use, and a space appeared on either side of the delimiter in a "schema.table" definition in your SQL, the replicator would fail to parse the statement correctly.

  For example, all of the examples below are valid SQL but would cause a failure in the replicator:

  sql> CREATE TABLE myschema. mytable (....
  
  sql> CREATE TABLE myschema .mytable (....
  
  sql> CREATE TABLE myschema . mytable (....

  Issue: CT-1278

• When replicating data that included timestamps, the replicator would update the timestamp value to the time within the commit from the incoming THL. When using statement based replication times would be correctly replicated, but if using a mixture of statement and row based replication, the timestamp value would not be set back to the default time when switching between statement and row based events. This would not cause problems in the applied host, except when log-slave-updateswas enabled. In this case, all row-based events after a statement based event would have the same timestamp value applied.

  This was most commonly seen when using the standalone replicator to replicate into a Cluster, either from a standlone source, or a cluster source.

  Issue: CT-1255

Connector (1)

• Connector would fail to properly find appropriate data service for its auto-configuration. Now using the service provided in the user map when present.

  Note

  This fix is also available in build 51 of the 6.1.4 release.
  Issue: CT-1277