Enable asynchronous dual reads
In this optional phase, you can enable the asynchronous dual reads feature to test the secondary (target) cluster’s ability to handle a production workload before you permanently redirect read requests in phase 4.
By default, ZDM Proxy sends all reads to the primary (origin) cluster, and then returns the result to the client application.
When you enable asynchronous dual reads, ZDM Proxy sends asynchronous read requests to the secondary cluster in addition to the synchronous read requests that are sent to the primary cluster.
At this point in the migration process, the secondary cluster is typically the target cluster. Because this feature is intended to test your target cluster’s ability to handle a simulated production workload, there is no reason to run it against the origin cluster that is already capable of handling production workloads.
This allows you to assess the target cluster’s performance and make any adjustments before permanently switching your workloads to the target cluster.
Response and error handling with asynchronous dual reads
With or without asynchronous dual reads, the client application only receives results from synchronous reads on the primary cluster. The client never receives results from asynchronous reads on the secondary cluster because these results are used only for ZDM Proxy’s asynchronous dual read metrics.
By design, if an asynchronous read fails or times out, it has no impact on client operations and the client application doesn’t receive an error. However, the increased workload from read requests can cause write requests to fail or time out on the secondary cluster. With or without asynchronous dual reads, a failed write on either cluster returns an error to the client application and potentially triggers a retry.
This functionality is intentional so you can simulate production-scale read traffic on the secondary cluster, in addition to the existing write traffic from ZDM Proxy’s dual writes, with the least impact to your applications.
To avoid unnecessary failures due to unmigrated data, enable asynchronous dual reads only after you migrate, validate, and reconcile all data from the origin cluster to the target cluster.
Configure asynchronous dual reads
Use the read_mode variable to enable or disable asynchronous dual reads.
Then, perform rolling restarts of your ZDM Proxy instances to apply the configuration change.
-
In
vars/zdm_proxy_core_config.yml, edit theread_modevariable:-
Enable asynchronous dual reads
-
Disable asynchronous dual reads (default)
read_mode: DUAL_ASYNC_ON_SECONDARYread_mode: PRIMARY_ONLY -
-
Perform rolling restarts to apply the configuration change to your ZDM Proxy instances.
-
With ZDM Proxy Automation
-
Without ZDM Proxy Automation
If you use ZDM Proxy Automation to manage your ZDM Proxy deployment, run the following command:
ansible-playbook rolling_update_zdm_proxy.yml -i zdm_ansible_inventoryIf you don’t use ZDM Proxy Automation, you must manually restart each instance.
To avoid downtime, wait for each instance to fully restart and begin receiving traffic before restarting the next instance.
For more information about rolling restarts and changing ZDM Proxy configuration variables, see Manage your ZDM Proxy instances.
-
Monitor the target cluster’s performance
After enabling asynchronous dual reads, observe the target cluster’s performance to determine how well it performs under the expected production workload.
To assess performance, you can monitor the following:
-
Cluster health metrics like latency, throughput, and error rate
-
ZDM Proxy’s asynchronous read requests metrics
If needed, adjust the target cluster’s configuration and continue monitoring until the cluster reaches your performance targets.
Next steps
When you are confident that the target cluster is prepared to handle production workloads, you can disable asynchronous dual reads, and then permanently route read requests to the target cluster.
