Route reads to the target
This topic explains how you can configure ZDM Proxy to route all reads to the target cluster instead of the origin cluster.
For illustrations of all the migration phases, see the Introduction.
Steps
You would typically perform these steps once you have migrated all the existing data from the origin cluster, and completed all validation checks and reconciliation if necessary.
This operation is a configuration change that can be carried out as explained here.
|
If you enabled asynchronous dual reads to test your target cluster’s performance, make sure that you disable asynchronous dual reads when you’re done testing. To do this, edit the If you don’t disable asynchronous dual reads, ZDM Proxy instances send asynchronous, duplicate read requests to your origin cluster. This is harmless but unnecessary. |
Changing the read routing configuration
If you’re not there already, ssh back into the jumphost:
ssh -F ~/.ssh/zdm_ssh_config jumphostOn the jumphost, connect to the Ansible Control Host container:
docker exec -it zdm-ansible-container bashYou will see a prompt like:
ubuntu@52772568517c:~$Now open the configuration file vars/zdm_proxy_core_config.yml for editing.
Change the variable primary_cluster to TARGET.
Run the playbook that changes the configuration of the existing ZDM Proxy deployment:
ansible-playbook rolling_update_zdm_proxy.yml -i zdm_ansible_inventoryWait for the ZDM Proxy instances to be restarted by Ansible, one by one. All instances will now send all reads to the target cluster instead of the origin cluster.
At this point, the target cluster becomes the primary cluster, but ZDM Proxy still keeps the origin cluster up-to-date through dual writes.
Verifying the read routing change
Once the read routing configuration change has been rolled out, you may want to verify that reads are correctly sent to the target cluster, as expected. This is not a required step, but you may wish to do it for peace of mind.
|
Issuing a ZDM Proxy handles reads to system tables differently, by intercepting them and always routing them to the origin, in some cases partly populating them at the proxy level. This means that system reads don’t represent how ZDM Proxy routes regular user reads. Even after you switched the configuration to read the target cluster as the primary cluster, all system reads still go to the origin. Although |
Verifying that the correct routing is taking place is a slightly cumbersome operation, due to the fact that the purpose of the ZDM process is to align the clusters and therefore, by definition, the data will be identical on both sides.
For this reason, the only way to do a manual verification test is to force a discrepancy of some test data between the clusters. To do this, you could consider using the Themis sample client application. This client application connects directly to the origin cluster, the target cluster, and ZDM Proxy. It inserts some test data in its own table, and then you can view the results of reads from each source. Refer to the Themis README for more information.
Alternatively, you could follow this manual procedure:
-
Create a small test table on both clusters, for example a simple key/value table (it could be in an existing keyspace, or in one that you create specifically for this test). For example
CREATE TABLE test_keyspace.test_table(k TEXT PRIMARY KEY, v TEXT);. -
Use
cqlshto connect directly to the origin cluster. Insert a row with any key, and with a value specific to the origin cluster, for exampleINSERT INTO test_keyspace.test_table(k, v) VALUES ('1', 'Hello from the origin cluster!');. -
Now, use
cqlshto connect directly to the target cluster. Insert a row with the same key as above, but with a value specific to the target cluster, for exampleINSERT INTO test_keyspace.test_table(k, v) VALUES ('1', 'Hello from the target cluster!');. -
Now, use
cqlshto connect to ZDM Proxy, and then issue a read request for this test table:SELECT * FROM test_keyspace.test_table WHERE k = '1';. The result will clearly show you where the read actually comes from.
