Appendix G. Frequently Asked Questions (FAQ)

G.1. Do we support a 3-node cluster spread across three AWS Availability Zones?
G.2. What are the best settings for the Tungsten connector intelligent proxy?
G.3. Do you handle bandwidth/traffic management to the DB servers?
G.4. One of my hosts is regularly a number of seconds behind my other slaves?
G.5. How do you change the replicator heap size after installation?
G.6. What effect do triggers have on replication, either row or statement-based?

G.1.

Do we support a 3-node cluster spread across three AWS Availability Zones?

This is a normal deployment pattern for working in AWS reduce risk. A single cluster works quite well in this topology.

G.2.

What are the best settings for the Tungsten connector intelligent proxy?

Standard settings work out of the box. Fine tuning can be done by working with the specific customer application during a Proof-Of-Concept or Production roll-out.

G.3.

Do you handle bandwidth/traffic management to the DB servers?

This is not something we have looked at.

G.4.

One of my hosts is regularly a number of seconds behind my other slaves?

The most likely culprit for this issue is that the time is different on the machine in question. If you have ntp or a similar network time tool installed on your machine, use it to update the current time across all the hosts within your deployment:

shell> ntpdate pool.ntp.org

Once the command has been executed across all the hosts, trying sending a heartbeat on the master to slaves and checking the latency:

shell> trepctl heartbeat

G.5.

How do you change the replicator heap size after installation?

You can change the configuration by running the following command from the staging directory:

shell> ./tools/tpm --host=host1 --java-mem-size=2048

G.6.

What effect do triggers have on replication, either row or statement-based?

Tungsten Replicator does not automatically shut off triggers on slaves. This creates problems on slaves when using row-based replication (RBR) as the trigger will run twice. Tungsten cannot do this because the setting required to do so is not available to MySQL client applications. Typical symptoms are duplicate key errors, though other problems may appear. Consider the following fixes:

  • Drop triggers on slaves. This is practical in fan-in for reporting or other cases where you do not need to failover to the slave at a later time.

  • Create an "is_master()" function that triggers can use to decide whether they are on the master or slave.

  • Use statement replication; not an option for heterogeneous replication.

The is_master() approach is simple to implement. First, create a function like the following that returns 1 if we are using the Tungsten user, as would be the case on a slave.

create function is_master()
 returns boolean
 deterministic
 return if(substring_index(user(),'@',1) != 'tungsten',true, false);

Next add a check to triggers that should not run on the slave. This suppresses trigger action to insert into table bar except on the master.

delimiter //
create trigger foo_insert after insert on foo
 for each row begin
 if is_master() then 
 insert into bar set id=NEW.id; 
 end if; 
 end;
//

As long as applications do not use the Tungsten account on the master, the preceding approach will be sufficient to suppress trigger operation.