How do I update the IP address of one or more hosts in the cluster?
To update the IP address used by one or more hosts in your cluster, you must perform the following steps:
How do I fix the mysql-connectorj to drizzle MySQL driver bug which prevents my application from connecting through the Connector?
When upgrading from version 2 to v4+, or simply just moving away from the mysql-connectorj driver to the Drizzle driver, the update process doesn't correctly remove all the connectorJ properties, causing a mismatch when connectors that did get the update try to make a connection to the cluster.
This is a known issue logged as CT-7
As yet, a fix has not been found, but the following workaround will correct the issue by hand:
To properly identify this issue, check the extended output of cctrl for the active driver. There will be one line of output for each node in the local cluster. Repeat once per cluster, on which node does not matter.
For example, for a three-node cluster, you may see something like this:
com.mysql.jdbc.Driver com.mysql.jdbc.Driver com.mysql.jdbc.Driver
If any line on any node in any cluster shows the
If you have multiple clusters, either MSMM, CMM or Composite HA/DR, always ensure you check ALL clusters. Especially in Composite clusters, the Master cluster, and especially the Master node, must be checked and corrected if necessary.
Ensure the tpm update was done with the
Review the tpm reverse output and analyze based on the following:
Repeat the following steps for all clusters, one by one:
Once the above has been completed, confirm that the procedure has worked as follows:
How do I update the password for the replication user in the cluster?
If you need to change the password used by Tungsten Cluster to connect to a dataserver and apply changes, the password can be updated first by changing the information within the your dataserver, and then by updating the configuration using tpm update. The new password is not checked until the Tungsten Replicator process is starting. Changing the password and then updating the configuration will keep replication from failing.
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:
Once the command has been executed across all the hosts, trying sending a heartbeat on the master to slaves and checking the latency:
Does the replicate filter (i.e. replicate.do and replicate.ignore) address both DML and DDL?
Both filters replicate.do and replicate.ignore will either do or ignore both DML and DDL
DDL is currently ONLY replicated for MySQL to MySQL or Oracle to Oracle topologies, or within MySQL Clusters, although it would be advisable not to use ignore/do filters in a clustered environment where data/structural integrity is key.
With replicate.do, all DML and DDL will be replicated ONLY for any database or table listed as part of the do filter.
With replicate.ignore, all DML and DDL will be replicated except for any database or table listed as part of the ignore filter.
How do you change the replicator heap size after installation?
You can change the configuration by running the following command from the staging directory:
On a Tungsten Replicator slave, how do I set both the local slave THL listener port and the upstream master's THL listener port?