Skip to content

Latest commit

 

History

History
113 lines (86 loc) · 4.99 KB

step2_astra_cli.md

File metadata and controls

113 lines (86 loc) · 4.99 KB
Zero Downtime Migration Lab ℹ️ For technical support, please contact us via email.
⬅️ Back Step 2 (astra-cli) Next ➡️
Preliminary step: set up Target

Phase 0b

🎯 Goal: creating the Target database (Astra DB instance) and verifying it is ready for the migration.

The Target database you are going to create is an Astra DB instance. This managed solution, built on Apache Cassandra™, frees you from worrying about operations; moreover, it is a serverless architecture that scales with your needs, avoiding unnecessary resource usage. If you don't have an Astra account, go create one: the Free Tier can cover much, much more I/O and storage than what's needed for this migration exercise.

Note: you are going to make use of the astra-cli utility to perform most of the required steps from the console. However, database creation and generation of an associated token are still done on the Astra Web UI:

  • Create your Astra account if you haven't yet.
  • Create a database called zdmtarget with a zdmapp keyspace (detailed instructions). for the Free Tier accounts, stick to the GCP cloud provider and choose a region without the "lock" icon). The DB will be ready to use in 2-3 minutes.
  • Get a "Database Administrator" database token from the Astra UI and store it in a safe place (detailed instructions). You will need it a few times throughout the exercise. For the migration process, a "R/W User" token would suffice, but a more powerful token is needed for the astra-cli automation.
I want to re-use an Astra DB instance I already have

If you already have a database (likely with a name other than zdmtarget) and want to use it, that's no problem at all! Just make sure you create a new keyspace called zdmapp in your database and, in case the DB is in the "hibernated" state, please resume it before moving to next step.

All you have to do then is replacing the name zdmtarget with your database the few times it appears in the console commands for the rest of this scenario.

Once this part is done, you can proceed in the "host" console. The Astra CLI is preinstalled for you: configure it with

### host
astra setup

and provide the AstraCS:... part of the token when prompted.

Have the CLI prepare a .env file, useful to later retrieve the database ID (edit the database name if different from zdmtarget):

### host
astra db create-dotenv zdmtarget -k zdmapp -d /workspace/zdm-scenario-katapod

During creation of this file, the "secure connect bundle" zipfile, needed by the sample application, has been downloaded as well at this path:

### host
grep ASTRA_DB_SECURE_BUNDLE_PATH /workspace/zdm-scenario-katapod/.env

Take a note of the zipfile full path, you'll need it later for the example API.

Finally, your Target database needs a schema matching the one in Origin. Check the contents of the script file with

### host
cat /workspace/zdm-scenario-katapod/target_config/target_schema.cql

and then execute it on the newly-created Astra DB instance (editing the database name if different from zdmtarget):

### host
cd /workspace/zdm-scenario-katapod/
astra db cqlsh zdmtarget -f target_config/target_schema.cql

🗒️ Your brand new database is created and has the right schema. Now you can start setting up the ZDM process, instructing it to use Astra DB as target.

Schema, phase 0b

⬅️ Back Next ➡️