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 Origin and Target, enabling you to check that the intended Target of your migration can handle the full workload of reads and writes before finalizing 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 the CQL quick reference.

ZDM Proxy handles your client application’s real-time write requests and forwards them to two Cassandra-based clusters (Origin and Target) 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 open-source 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, Origin is typically the primary cluster. Near the end of the migration, you’ll shift the primary cluster to be Target.

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 async 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 Origin and Target. 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 may (optionally) want to temporarily send the reads to both clusters, to make sure that Target 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 generated in Astra Portal that contains connection metadata and TLS encryption certificates (but not the database credentials) for your Astra DB database. For details, see Working with the Secure Connect Bundle.

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.