Version End of Life. Not Yet Set
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.
The following issues are known within this release but not considered critical, nor impact the operation of Tungsten Cluster. They will be addressed in a subsequent patch release.
In MySQL release 8.0.21 the behavior of
CREATE TABLE ... AS SELECT ...has changed, resulting in the transactions being logged differenly 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 separate
CREATE 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.
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
was enabled. In this case, all row-based events after a
statement based event would have the same timestamp value
This was most commonly seen when using the standalone replicator to replicate into a Cluster, either from a standlone source, or a cluster source.
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 (....