4.1.5. Parallel Replication and Offline Operation
184.108.40.206. Clean Offline Operation
When you issue a trepctl offline command, Tungsten Replicator will bring
all channels to the same point in the log and then go offline. This is
known as going offline cleanly. When a slave has been taken offline
cleanly the following are true:
When parallel replication is not enabled, you can take the replicator
offline by stopping the replicator process. There is no need to issue a
trepctl offline command first.
220.127.116.11. Tuning the Time to Go Offline Cleanly
Putting a replicator offline may take a while if the slowest and fastest
channels are far apart, i.e., if one channel gets far ahead of another.
The separation between channels is controlled by the
maxOfflineInterval parameter, which defaults to 5
seconds. This sets the allowable distance between commit timestamps
processed on different channels. You can adjust this value at
installation or later. The following example shows how to change it
after installation. This can be done at any time and does not require
the replicator to go offline cleanly.
./tools/tpm update alpha \
The offline interval is only the the approximate time that
Tungsten Replicator will take to go offline. Up to a point, larger values
(say 60 or 120 seconds) allow the replicator to parallelize in spite of
a few operations that are relatively slow. However, the down side is
that going offline cleanly can become quite slow.
If you need to take a replicator offline quickly, you can either stop
the replicator process or issue the following command:
trepctl offline -immediate
Both of these result in an unclean shutdown. However, parallel
replication is completely crash-safe provided you use transactional
table types like InnoDB, so you will be able to restart without causing
slave consistency problems.
You must take the replicator offline cleanly to change the number of
channels or when reverting to MySQL native replication. Failing to do
so can result in errors when you restart replication.