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
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
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
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
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.
Upgrade from Older Replicator Versions
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
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
For more information, see Section F.3, “Understanding Replication of Date/Time Values”.