Version End of Life. 31 October 2018
Continuent Tungsten 2.0.5 is a bugfix release that contains critical improvements to the handling of times, dates, and timestamp values between servers, including during daylight savings time switches.
An issue was discovered that altered the way different date and time values were extracted, stored in THL, and applied into target databases. The issue was related to the way the value was stored; the data was not normalized within Continuent Tungsten during replication, particularly if different timezones were used and applied across the replication deployment.
Examples of the behaviour include:
TIMESTAMP values in
statements to UTC. Tungsten did not replicate the master
time zone, which meant that replicated statements would
when replicated to a server with a different time zone from
values are stored as UTC, which means that row changes are
extracted in UTC. Tungsten did not set the Java VM or MySQL
session time zone to UTC when applying such changes, which
could result in inconsistent values being applied to
Changes between standard and daylight savings time (DST) result in a short period in which master DBMS servers have a different time zone from replicas. This resulted in errors in applying time-related data generated at the time of the switch.
Heterogeneous replication, for example from relational DBMS like MySQL to data warehouses, would result in unexpected conversions to time-related data, again due to inconsistencies in time zones.
The replication has now been updated to normalize date and time values into UTC throughout the replication topology, including within the wrapper Java processes, databases and when storing the information in THL.
Replicator processes now default to UTC internally by setting the Java VM default time zone to UTC. This default can be changed by setting the replicator.time_zone property in the replicator services.propertiesx file but is not recommended other than for problem diagnosis or specialized testing.
Replicas store a time zone on statements and row changes extracted from MySQL.
Replicators use UTC as the session time zone when applying to MySQL replicas.
Replicators similarly default to UTC when applying transactions to data warehouses like Hadoop, Vertica, or Amazon Redshift.
The thl utility prints time-related data
using the default GMT time zone. This can be altered using
We recommend the following steps to ensure successful replication of time-related data.
Standardize all DBMS server and host time zones to UTC. This minimizes time zone inconsistencies between applications and data stores. The recommendation is particularly important when replicating between different DBMS types, such as MySQL to Hadoop.
Use the default time zone settings for Tungsten replicator. Do not change the time zones unless specifically recommended by VMware support.
If you cannot standardize on UTC at least ensure that time zones are set consistently on all hosts and applications.
Arbitrary time zone settings create a number of corner cases for database management beyond replication. Standardizing on UTC helps minimize them, hence is strongly recommended.
New Tungsten replicators tag THL records with an option to show that the transaction was extracted from a time zone-aware replicator. If a replicator sees that this property is not available, it will automatically switch to the older behavior when applying such transactions to MySQL replicas. This ensures that there is as simple process to upgrade from older replicator versions, which is especially important for Continuent Tungsten clusters.
There are two ways to upgrade a replication topology that extracts from MySQL to the new, time zone-aware behavior.
Put the master replicator offline, wait for slaves to catch up fully, then upgrade all replicators at once.
Upgrade slave replicators first, then upgrade the master. If the replicators are running in a Continuent Tungsten cluster, you must put the cluster in maintenance mode during the upgrade to prevent master failover.
You should not upgrade a master Tungsten Replicator before the slave replicas. This can generate transactions that may not be correctly applied by the slaves, since they are not time zone-aware.
For more information, see Section F.3, “Understanding Replication of Date/Time Values”.