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 feature that is designed to test the target cluster’s ability to handle a production workload before you permanently switch to the target cluster at the end of the migration process.

When enabled, ZDM Proxy sends asynchronous read requests to the secondary cluster (typically the target cluster) in addition to the synchronous read requests that are sent to the primary cluster by default.

For more information, see 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 database that you are migrating away from. It is the opposite of the Target.

The database that is designated as the source of truth for read requests. It is the opposite of the Secondary cluster.

The primary cluster is set by ZDM Proxy Automation through the primary_cluster variable, or you can set it directly through the ZDM_PRIMARY_CLUSTER environment variable for ZDM Proxy.

For the majority of the migration process, the origin database is typically the primary cluster. Near the end of the migration, you shift the primary cluster to the target database.

For information about which cluster receives reads and writes during the migration process, see How ZDM Proxy handles reads and writes.

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.

The database that isn’t designated as the source of truth for read requests. It is the opposite of the Primary cluster.

For the majority of the migration process, the secondary cluster is the target database. Near the end of the migration, the target database becomes the Primary cluster, and then the origin database becomes the secondary cluster.

For information about which cluster receives reads and writes during the migration process, see How ZDM Proxy handles reads and writes.

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 database to which you are migrating your data and applications. It is the opposite of the Origin.

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 ZDM Utility. This interactive utility creates a Docker container acting as the Ansible Control Host. The Ansible playbooks constitute ZDM Proxy Automation.

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