From ff170144a68afa6de89b75be746a13fc6caca7e0 Mon Sep 17 00:00:00 2001 From: April M <36110273+aimurphy@users.noreply.github.com> Date: Tue, 31 Mar 2026 08:33:59 -0700 Subject: [PATCH 1/2] update, remove attributes --- local-preview-playbook.yml | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/local-preview-playbook.yml b/local-preview-playbook.yml index 5097cae3..225a21d1 100644 --- a/local-preview-playbook.yml +++ b/local-preview-playbook.yml @@ -72,7 +72,7 @@ asciidoc: astra-ui: 'Astra Portal' astra-url: 'https://astra.datastax.com' astra-ui-link: '{astra-url}[{astra-ui}^]' - db-classic: 'Managed Cluster' + db-classic: 'Astra Managed Clusters' db-serverless: 'Serverless (non-vector)' db-serverless-vector: 'Serverless (vector)' scb: 'Secure Connect Bundle (SCB)' @@ -84,7 +84,6 @@ asciidoc: astra-stream: 'Astra Streaming' starlight-kafka: 'Starlight for Kafka' starlight-rabbitmq: 'Starlight for RabbitMQ' - astra-streaming-examples-repo: 'https://github.com/datastax/astra-streaming-examples' sstable-sideloader: '{astra-db} Sideloader' zdm: 'Zero Downtime Migration' zdm-short: 'ZDM' @@ -223,10 +222,6 @@ asciidoc: capacity-service: 'Capacity Service' lcm: 'Lifecycle Manager (LCM)' lcm-short: 'LCM' - cr: 'custom resource (CR)' - cr-short: 'CR' - crd: 'custom resource definition (CRD)' - crd-short: 'CRD' # Antora Atlas primary-site-url: https://docs.datastax.com/en primary-site-manifest-url: https://docs.datastax.com/en/site-manifest.json From c647f169cdef143935e1cc80fc0fb23ccebc76a7 Mon Sep 17 00:00:00 2001 From: April M <36110273+aimurphy@users.noreply.github.com> Date: Tue, 31 Mar 2026 14:36:44 -0700 Subject: [PATCH 2/2] re-create --- modules/ROOT/pages/create-target.adoc | 6 +++--- modules/ROOT/pages/deploy-proxy-monitoring.adoc | 4 ++-- modules/ROOT/pages/feasibility-checklists.adoc | 2 +- modules/ROOT/pages/manage-proxy-instances.adoc | 8 ++++---- modules/ROOT/pages/setup-ansible-playbooks.adoc | 2 +- modules/ROOT/pages/troubleshooting-tips.adoc | 8 ++++---- modules/sideloader/pages/migrate-sideloader.adoc | 4 ++-- modules/sideloader/pages/prepare-sideloader.adoc | 2 +- modules/sideloader/pages/troubleshoot-sideloader.adoc | 2 +- 9 files changed, 19 insertions(+), 19 deletions(-) diff --git a/modules/ROOT/pages/create-target.adoc b/modules/ROOT/pages/create-target.adoc index 9107357c..b10a77fd 100644 --- a/modules/ROOT/pages/create-target.adoc +++ b/modules/ROOT/pages/create-target.adoc @@ -5,7 +5,7 @@ After you review the xref:ROOT:feasibility-checklists.adoc[compatibility require This includes the following: * Create the new cluster that will be the target of your migration. -* Recreate the schema from your origin cluster on the target cluster. +* Re-create the schema from your origin cluster on the target cluster. * Gather authentication credentials and connection details for the target cluster. The preparation steps depend on your target platform. @@ -53,7 +53,7 @@ For example, you could use `scp`: scp -i some-key.pem /path/to/scb.zip user@client-ip-or-host: ---- -. Recreate your client application's schema on your {astra-db} database, including each keyspace and table that you want to migrate. +. Re-create your client application's schema on your {astra-db} database, including each keyspace and table that you want to migrate. + [IMPORTANT] ==== @@ -96,7 +96,7 @@ Store the authentication credentials securely for use by your client application . Note your cluster's connection details, including the contact points (IP addresses or hostnames) and port number. -. Recreate your origin cluster's schema on your new cluster, including each keyspace and table that you want to migrate. +. Re-create your origin cluster's schema on your new cluster, including each keyspace and table that you want to migrate. + [IMPORTANT] ==== diff --git a/modules/ROOT/pages/deploy-proxy-monitoring.adoc b/modules/ROOT/pages/deploy-proxy-monitoring.adoc index d1522d71..3cd1a4f0 100644 --- a/modules/ROOT/pages/deploy-proxy-monitoring.adoc +++ b/modules/ROOT/pages/deploy-proxy-monitoring.adoc @@ -232,7 +232,7 @@ Only modify the variables in `zdm_proxy_advanced_config.yml` if you have a speci ==== The following advanced configuration variables are immutable. If you need to change these variables, {company} recommends that you do so _before_ deploying {product-proxy}. -Future changes require you to recreate your entire {product-proxy} deployment. +Future changes require you to re-create your entire {product-proxy} deployment. For more information, see xref:ROOT:manage-proxy-instances.adoc#change-immutable-configuration-variables[Change immutable configuration variables]. ==== @@ -257,7 +257,7 @@ This can be changed by setting `metrics_port` to a different value if desired. All other advanced configuration variables in `zdm_proxy_advanced_config.yml` are mutable. You can seamlessly change them after deploying {product-proxy} with a rolling restart. -Immutable variables require you to recreate the entire deployment and result in downtime for your {product-proxy} deployment. +Immutable variables require you to re-create the entire deployment and result in downtime for your {product-proxy} deployment. For more information, see xref:manage-proxy-instances.adoc[]. [#enable-tls-encryption] diff --git a/modules/ROOT/pages/feasibility-checklists.adoc b/modules/ROOT/pages/feasibility-checklists.adoc index 9754afb2..32b72789 100644 --- a/modules/ROOT/pages/feasibility-checklists.adoc +++ b/modules/ROOT/pages/feasibility-checklists.adoc @@ -128,7 +128,7 @@ This means that any keyspace that your client application uses must exist on bot However, the keyspaces can have different replication strategies and durable write settings. At the column level, the schema doesn't need to be a one-to-one match as long as the CQL statements can be executed successfully on both clusters. -For example, if a table has 10 columns, and your client application uses only five of those columns, then you can recreate the table on the target cluster with only the five required columns. +For example, if a table has 10 columns, and your client application uses only five of those columns, then you can re-create the table on the target cluster with only the five required columns. However, the data from the other columns won't be migrated to the target cluster if those columns don't exist on the target cluster. Before you decide to omit a column from the target cluster, make sure that it is acceptable to permanently lose that data after the migration. diff --git a/modules/ROOT/pages/manage-proxy-instances.adoc b/modules/ROOT/pages/manage-proxy-instances.adoc index 73fc440e..4ffbd819 100644 --- a/modules/ROOT/pages/manage-proxy-instances.adoc +++ b/modules/ROOT/pages/manage-proxy-instances.adoc @@ -54,14 +54,14 @@ ubuntu@52772568517c:~$ ansible-playbook rolling_update_zdm_proxy.yml -i zdm_ansible_inventory ---- -The rolling restart playbook recreates each {product-proxy} container, one by one. +The rolling restart playbook re-creates each {product-proxy} container, one by one. The {product-proxy} deployment remains available at all times, and you can safely use it throughout this operation. If you modified mutable configuration variables, the new containers use the updated configuration files. The playbook performs the following actions automatically: . {product-automation} stops one container gracefully, and then waits for it to shut down. -. {product-automation} recreates the container, and then starts it. +. {product-automation} re-creates the container, and then starts it. . {product-automation} calls the xref:ROOT:metrics.adoc#call-the-liveliness-and-readiness-endpoints[readiness endpoint] to check the container's status: + * If the status check fails, {product-automation} repeats the check up to six times at 5-second intervals. @@ -271,7 +271,7 @@ ansible-playbook deploy_zdm_proxy.yml -i zdm_ansible_inventory ---- You can re-run the deployment playbook as many times as necessary. -However, this playbook decommissions and recreates _all_ {product-proxy} instances simultaneously. +However, this playbook decommissions and re-creates _all_ {product-proxy} instances simultaneously. This results in a brief period of time where the entire {product-proxy} deployment is offline because no instances are available. For more information, see xref:ROOT:troubleshooting-tips.adoc#configuration-changes-arent-applied-by-zdm-automation[Configuration changes aren't applied by {product-automation}]. @@ -280,7 +280,7 @@ For more information, see xref:ROOT:troubleshooting-tips.adoc#configuration-chan == Upgrade the proxy version The same playbook that you use for configuration changes can also be used to upgrade the {product-proxy} version in a rolling fashion. -All containers are recreated with the given image version. +All containers are re-created with the given image version. [IMPORTANT] ==== diff --git a/modules/ROOT/pages/setup-ansible-playbooks.adoc b/modules/ROOT/pages/setup-ansible-playbooks.adoc index f42f32db..ea849d8c 100644 --- a/modules/ROOT/pages/setup-ansible-playbooks.adoc +++ b/modules/ROOT/pages/setup-ansible-playbooks.adoc @@ -24,7 +24,7 @@ This infrastructure can be on-premise or in any cloud provider of your choice. + If your {product-proxy} machines use private IPs, which are recommended for production deployments, configure these before running {product-utility}. If you enable private IPs later, you must reconfigure and redeploy your {product-proxy} instances. -This is a disruptive operation that requires a small amount of downtime because the deployment playbook decommissions and recreates all {product-proxy} containers simultaneously. +This is a disruptive operation that requires a small amount of downtime because the deployment playbook decommissions and re-creates all {product-proxy} containers simultaneously. * https://docs.docker.com/engine/install/#server[Install Docker] on the machine that will run the Ansible Control Host container, and ensure that the `docker` command https://docs.docker.com/engine/install/linux-postinstall/#manage-docker-as-a-non-root-user[doesn't require superuser privileges]. + diff --git a/modules/ROOT/pages/troubleshooting-tips.adoc b/modules/ROOT/pages/troubleshooting-tips.adoc index 6d1e1852..240cf75e 100644 --- a/modules/ROOT/pages/troubleshooting-tips.adoc +++ b/modules/ROOT/pages/troubleshooting-tips.adoc @@ -54,7 +54,7 @@ To tail (stream) the logs as they are written, use the `--follow` (`-f`) option: docker container logs zdm-proxy-container -f ---- -Keep in mind that Docker logs are deleted if the container is recreated. +Keep in mind that Docker logs are deleted if the container is re-created. -- Collect logs for multiple instances:: @@ -116,7 +116,7 @@ For example, if you used Docker, you can use the following command to export a c docker logs my-container > log.txt ---- -Keep in mind that Docker logs are deleted if the container is recreated. +Keep in mind that Docker logs are deleted if the container is re-created. -- ====== @@ -270,8 +270,8 @@ Allowing these values to change from a rolling restart could propagate a misconf If you change the value of an immutable configuration variable, you must run the `deploy_zdm_proxy.yml` playbook again. You can run this playbook as many times as needed. -Each time, {product-automation} recreates your entire {product-proxy} deployment with the new configuration. -However, this doesn't happen in a rolling fashion: The existing {product-proxy} instances are torn down simultaneously, and then they are recreated. +Each time, {product-automation} re-creates your entire {product-proxy} deployment with the new configuration. +However, this doesn't happen in a rolling fashion: The existing {product-proxy} instances are torn down simultaneously, and then they are re-created. This results in a brief period of downtime where the entire {product-proxy} deployment is unavailable. === Client application throws unsupported protocol version error diff --git a/modules/sideloader/pages/migrate-sideloader.adoc b/modules/sideloader/pages/migrate-sideloader.adoc index 76c3390f..18755a7e 100644 --- a/modules/sideloader/pages/migrate-sideloader.adoc +++ b/modules/sideloader/pages/migrate-sideloader.adoc @@ -184,7 +184,7 @@ Snapshots have a specific directory structure, such as `*KEYSPACE_NAME*/*TABLE_N [#record-schema] == Configure the target database -To prepare your target database for the migration, you must record the schema for each table in your origin cluster that you want to migrate, recreate these schemas in your target database, and then set environment variables required to connect to your database. +To prepare your target database for the migration, you must record the schema for each table in your origin cluster that you want to migrate, re-create these schemas in your target database, and then set environment variables required to connect to your database. [WARNING] ==== @@ -229,7 +229,7 @@ CREATE TABLE smart_home.sensor_readings ( ) WITH CLUSTERING ORDER BY (room_id ASC, reading_timestamp DESC); ---- -. Recreate the schemas in your target database: +. Re-create the schemas in your target database: + .. In the {astra-ui-link} navigation menu, click *Databases*, and then click the name of your {astra-db} database. .. xref:astra-db-serverless:databases:manage-keyspaces.adoc#keyspaces[Create a keyspace] with the exact same name as your origin cluster's keyspace. diff --git a/modules/sideloader/pages/prepare-sideloader.adoc b/modules/sideloader/pages/prepare-sideloader.adoc index 881aa0af..8bd78d0a 100644 --- a/modules/sideloader/pages/prepare-sideloader.adoc +++ b/modules/sideloader/pages/prepare-sideloader.adoc @@ -266,7 +266,7 @@ If the schemas don't match, the migration fails. + You don't need to make any changes based on the number of nodes, as long as the keyspaces and table schemas are replicated in the target databases. + -If you want to migrate the same data to multiple databases, you must recreate the schemas in each of those databases. +If you want to migrate the same data to multiple databases, you must re-create the schemas in each of those databases. {sstable-sideloader} requires a schema to be present in the target database in order to migrate data. . For each target database, initialize a migration to prompt {sstable-sideloader} to create migration buckets for each database. diff --git a/modules/sideloader/pages/troubleshoot-sideloader.adoc b/modules/sideloader/pages/troubleshoot-sideloader.adoc index a1c12fe1..1b3ff5fd 100644 --- a/modules/sideloader/pages/troubleshoot-sideloader.adoc +++ b/modules/sideloader/pages/troubleshoot-sideloader.adoc @@ -89,7 +89,7 @@ There are two reasons you might need to do this: + ** The origin and target schemas don't match. ** The migration reached a point that some data was loaded to the target database. -This is unlikely, but, if this happens, you must xref:astra-db-serverless:databases:manage-collections.adoc#delete-a-table-in-the-astra-portal[drop the table] from your target database, and then recreate the table in the target database. +This is unlikely, but, if this happens, you must xref:astra-db-serverless:databases:manage-collections.adoc#delete-a-table-in-the-astra-portal[drop the table] from your target database, and then re-create the table in the target database. + In this case, if the migration _didn't_ fail due to a problem with the snapshot data, you can potentially reuse the existing snapshots for the new migration.