To use Composite Dynamic Active/Active you need to have a Composite Active/Active cluster deployed, then it is simply a case of specifying the required affinity within the connectors.
For the purpose of this example we will assume we have two clusters
alpha
and beta
. Each cluster will
have two connectors and it is desired that the alpha
cluster be the primary write destination.
Within the configuration for the connectors, add the following:
=> On alpha nodes: connector-write-affinity=alpha connector-read-affinity=alpha => On beta nodes: connector-write-affinity=alpha connector-read-affinity=beta
This will have the effect of setting the write affinity to the
alpha
cluster primarily on both
alpha
and beta
clusters as follows:
alpha
cluster will get both read and write affinity
to alpha
beta
cluster will get write affinity to
alpha
, but maintain read affinity to
beta
After recovering a failed site
As outlined above, if the site that has write affinity fails, read-write traffic will failover to another site based on the affinity rules configured. Following recovery of the site that is configured as the primary write site, new connections will follow the write affinity rules, whereas existing connections will remain on the site that was promoted after failover.
To maintain data-integrity and to ensure writes continue to only be directed to a single site, it is therefore essential to also enable the following tpm property:
--connector-reset-when-affinity-back=true
With this enabled, following recovery of the primary write site, all connections (new and old) will revert to the original, intended, cluster configured with primary write affinity.
In the case of the alpha
cluster failing, the writes
will failover and redirect to the beta
cluster.
Testing DAA in Bridge Mode
When using Bridge mode (the default at install), all requests are routed to the Primary by default. To test query routing, run the following query when connected through the Connector:
Route to the Primary:
mysql> select @@hostname;
In Bridge mode, the only way to verify that reads are being directed to
replicas is to establish a read-only port and execute queries through it
to force the QoS RO_RELAXED
.
First, ensure that your INI file has the following option, then run tpm update
connector-readonly-listen-port=3307
To test, ensure you connect to the specified read-only port:
Route to a Replica: shell>Testing DAA in Proxy Mode with No R/W Splitting Enabledmysql -h... -P3307
mysql>select @@hostname;
To test Connector query routing in Proxy mode, you may use the URL-based R/W splitting to test query routing:
Route to the Primary: shell>Testing DAA in Proxy Mode with R/W Splitting Enabled (SmartScale or @direct)mysql -h... -Dtest@qos=RW_STRICT -e "select @@hostname;"
Route to a Replica: shell>mysql -h... -Dtest@qos=RO_RELAXED -e "select @@hostname;"
To test Connector query routing in Proxy mode when either SmartScale or @direct read/write splitting has been enabled, you may use the following:
Route to the Primary: mysql>select @@hostname for update;
Route to a Replica: mysql>select @@hostname;
Manual Site-Level Switch
For DAA to work properly, all writes must go to one cluster or another, no exceptions. When you want to move all writes to another site/cluster (like you would in a Composite Active/Passive cluster using the switch command at the composite level), there is no switch command available in Dynamic Active/Active.
As of version 7.0.2, we strongly recommend that you use the cctrl command datasource SERVICE drain [optional timeout in seconds] at the composite level to shun the currently selected Active cluster. This will allow the Connector to finish (drain) all in-flight queries, shun the composite dataservice once fully drained, and then move all writes to another cluster.
Please note that this is different than using the cctrl
command datasource SERVICE shun
(available prior to version 7.0.2) at the composite level to shun the
currently selected Active cluster. Using shun
instead
of drain
will force the Connector
to immediately sever/terminate all in-flight queries, then move
all writes to another cluster.
shell>cctrl -multi
Tungsten Clustering 7.0.2 build 145 beta: session established, encryption=true, authentication=true jgroups: encrypted, database: encrypted [LOGICAL] / >use world
[LOGICAL] /world >datasource alpha drain 30
WARNING: This is an expert-level command: Incorrect use may cause data corruption or make the cluster unavailable. Do you want to continue? (y/n)>y
composite data source 'alpha' is now SHUNNED [LOGICAL] /world >exit
Exiting...
When you are ready to resume writes to the originally-configured site, use
the composite-level cctrl command
datasource SERVICE welcome. If you
have set
--connector-reset-when-affinity-back=true
,
then writes will move back to the original site. If set to
false
, the writes will stay where they are.
shell>cctrl -multi
Tungsten Clustering 7.0.2 build 145 beta: session established, encryption=true, authentication=true jgroups: encrypted, database: encrypted [LOGICAL] / >use world
[LOGICAL] / >datasource alpha welcome
WARNING: This is an expert-level command: Incorrect use may cause data corruption or make the cluster unavailable. Do you want to continue? (y/n)>y
composite data source 'alpha' is now ONLINE [LOGICAL] /world >exit
Exiting...
For more information about the datasource shun command, please visit: Section 9.1.3.5.9, “cctrl datasource shun Command”
For more information about the datasource drain command, please visit: Section 9.1.3.5.3, “cctrl datasource drain Command”