- Difficulty: Advanced
- Duration: 80 minutes
This is a Katapod interactive lab. Expand for usage tips
This hands-on lab is built using the Katapod engine. If you have never encountered it before, this is how you use it:
- You will proceed through a series of steps on the left panel, advancing to the next step by the click of a button.
- On the right part of the lab, one or more consoles are spawned for you to execute commands and interact with the system.
- Each step provides instructions and explanations on what is going on.
- In particular, click on code blocks to execute them in their target console.
- Commands that are executed already are marked as such. Usually you can execute a command as many times as you want (though this might not always be what you want to do).
This is a guided end-to-end Zero-Downtime-Migration hands-on experience designed to run entirely in your browser. You will start with a running client application backed by a Cassandra installation, and will go through all steps required to migrate it to an Astra DB instance.
This interactive lab is designed after the phases described in detail in the ZDM Documentation pages, which is a recommended reading before starting a migration in production.
The migration is structured in five phases:
- Phase 1: Deploy ZDM Proxy and connect your client applications to it. This activates the dual-write logic: writes will be "bifurcated" (sent both to Origin and Target), while reads will be executed on Origin only.
- Phase 2: Migrate existing data using Cassandra Data Migrator and/or DSBulk Migrator. Validate that the migrated data is correct, while continuing to perform dual writes.
- Phase 3: Enable asynchronous dual reads (optional).
- Phase 4: Change the proxy configuration to route reads to Target, effectively using Target as the source-of-truth while still keeping Origin in sync.
- Phase 5: Move your client applications off the ZDM Proxy and connect them directly to Target.
About Origin and the client application:
In this lab, the Origin database is a Cassandra single-node cluster running locally, which is being
provisioned while you are reading this.
The lab provides a simple client application, a HTTP REST API used to read and write
the "status" of "users" (e.g. Away, Busy, Online). This is a simple Python FastAPI application.
Even though during the lab you will mostly query the API, getting back just the latest values,
by reading straight from DB you will be able to see the whole history of user status changes, as well as what data is on which database at various stages of the migration.
The application will initially connect to Origin, but is ready to adapt to the migration phases
with a simple restart as you progress, as long as you provide the required connection parameters in a configuration file.
Click to find out how this learning environment differs from a real migration
This is an ephemeral setup, designed to be bootstrapped quickly and in such a way as to be easily packaged into a single host machine. As a consequence, please mind that:
- you will have a single ZDM Proxy instance (as opposed to at least three as suggested for production migrations);
- All containers (including Origin!) will be running on a single machine. In a realistic setup this would put resiliency and availability at risk, and certainly hinder performance and throughput.