Glossary

A repeatable, re-usable, simple configuration management and multi-machine deployment system, one that is well suited to deploying complex applications. For details about the playbooks available in ZDM Proxy Automation, see:

An optional testing phase in which reads are sent to both the origin and target clusters. This lets you check that the target cluster/database can handle the full workload of reads and writes before you finalize the migration and moving off the ZDM Proxy instances. For details, see Phase 3: Enable asynchronous dual reads.

Cassandra Query Language (CQL) is a query language for the Cassandra database. It includes DDL and DML statements. For details, see Develop with the Cassandra Query Language.

ZDM Proxy handles your client application’s real-time write requests and forwards them to two Cassandra-based origin and target clusters simultaneously. The dual-write logic in ZDM Proxy means that you do not need to modify your client application to perform dual writes manually during a migration: ZDM Proxy takes care of it for you. See the diagram in the workflow introduction.

Your existing Cassandra-based cluster, whether it’s Apache Cassandra®, DataStax Enterprise (DSE), or Astra DB.

The cluster that is currently considered the "primary" source of truth. While writes are always sent to both clusters, the primary cluster is the one to which all synchronous reads are always sent, and their results are returned to the client application. During a migration, the origin cluster is typically the primary cluster. Near the end of the migration, you shift the primary cluster to be the target cluster.

For more, see Secondary cluster.

See Ansible playbooks.

Generally speaking, a proxy is a software class functioning as an interface to something else. The proxy could interface to anything: a network connection, a large object in memory, a file, or some other resource. A proxy is a wrapper or agent object that is being called by the client to access the real serving object behind the scenes. In our context here, see ZDM Proxy.

See Asynchronous dual reads.

During a migration, the secondary cluster is the one that is currently not the source of truth.

When using the ZDM Proxy, all writes are synchronously sent to both the origin and target clusters. Reads operate differently: with the default read mode, reads are only sent to the primary cluster (Origin by default). In Phase 3 of a migration, you can optionally send the reads to both clusters temporarily if you want to verify that the target cluster can handle the full workload of reads and writes.

If you set the proxy’s read mode configuration variable (read_mode) to DUAL_ASYNC_ON_SECONDARY, then asynchronous dual reads are enabled. That change results in reads being additionally sent to the secondary cluster.

For more, see Primary cluster. Also see Phase 3: Enable asynchronous dual reads.

A ZIP file that contains connection metadata and TLS encryption certificates (but not the database credentials) for your Astra DB database. For more information, see Download and use a Secure Connect Bundle (SCB) with Astra DB Serverless.

The new cluster to which you want to migrate client applications and data with zero downtime.

An Ansible-based tool that allows you to deploy and manage the ZDM Proxy instances and associated monitoring stack. To simplify its setup, the suite includes the ZDM Utility. This interactive utility creates a Docker container acting as the Ansible Control Host. The Ansible playbooks constitute the ZDM Proxy Automation.

An open-source component designed to seamlessly handle the real-time client application activity while a migration is in progress.