Skip to content

Commit

Permalink
DOC-3707 - Attributes replacement and nav fixes (#193)
Browse files Browse the repository at this point in the history
* begin attribute replacement

* continuing find and replace

* finish replacement

* add one page missing from nav

* separate nav
  • Loading branch information
aimurphy authored Feb 11, 2025
1 parent 126ad97 commit b510c20
Show file tree
Hide file tree
Showing 47 changed files with 822 additions and 838 deletions.
30 changes: 17 additions & 13 deletions antora.yml
Original file line number Diff line number Diff line change
Expand Up @@ -8,19 +8,23 @@ nav:

asciidoc:
attributes:
company: 'DataStax'
product: 'Zero Downtime Migration'
zdm-product: 'Zero Downtime Migration'
zdm-shortproduct: 'ZDM'
zdm-proxy: 'ZDM Proxy'
zdm-utility: 'ZDM Utility'
zdm-automation: 'ZDM Proxy Automation'
cstar-data-migrator: 'Cassandra Data Migrator'
product-short: 'ZDM'
product-proxy: 'ZDM Proxy'
product-utility: 'ZDM Utility'
product-automation: 'ZDM Proxy Automation'
product-demo: 'ZDM Demo Client'
dsbulk-migrator: 'DSBulk Migrator'
dsbulk-loader: 'DSBulk Loader'
db-serverless: 'Serverless (Non-Vector)'
db-serverless-vector: 'Serverless (Vector)'
db-classic: 'Classic'
astra-cli: 'Astra CLI'
url-astra: 'https://astra.datastax.com'
link-astra-portal: '{url-astra}[{astra_ui}]'
astra-db-serverless: 'Astra DB Serverless'
cass: 'Apache Cassandra'
cass-short: 'Cassandra'
cass-reg: 'Apache Cassandra(R)'
cass-migrator: 'Cassandra Data Migrator'
cass-migrator-short: 'CDM'
dse: 'DataStax Enterprise (DSE)'
dse-short: 'DSE'
astra-db: 'Astra DB'
astra-ui: 'Astra Portal'
astra-url: 'https://astra.datastax.com'
support-url: 'https://support.datastax.com'
82 changes: 39 additions & 43 deletions modules/ROOT/nav.adoc
Original file line number Diff line number Diff line change
@@ -1,56 +1,52 @@
* Zero Downtime Migration
** xref:introduction.adoc[]
** xref:components.adoc[]
.{product}
* xref:introduction.adoc[]
* xref:components.adoc[]
* Planning
** xref:preliminary-steps.adoc[]
*** xref:feasibility-checklists.adoc[]
*** xref:deployment-infrastructure.adoc[]
*** xref:create-target.adoc[]
*** xref:rollback.adoc[]
//phase 1
** xref:feasibility-checklists.adoc[]
** xref:deployment-infrastructure.adoc[]
** xref:create-target.adoc[]
** xref:rollback.adoc[]
* Phase 1
** xref:phase1.adoc[]
*** xref:setup-ansible-playbooks.adoc[]
*** xref:deploy-proxy-monitoring.adoc[]
*** xref:tls.adoc[]
*** xref:connect-clients-to-proxy.adoc[]
*** xref:metrics.adoc[]
*** xref:manage-proxy-instances.adoc[]
//phase 2
** xref:setup-ansible-playbooks.adoc[]
** xref:deploy-proxy-monitoring.adoc[]
** xref:tls.adoc[]
** xref:connect-clients-to-proxy.adoc[]
** xref:metrics.adoc[]
** xref:manage-proxy-instances.adoc[]
* Phase 2
** xref:migrate-and-validate-data.adoc[]
*** xref:cassandra-data-migrator.adoc[]
*** https://docs.datastax.com/en/dsbulk/overview/dsbulk-about.html[DSBulk Loader]
//phase 3
** xref:cassandra-data-migrator.adoc[{cass-migrator}]
** xref:dsbulk-migrator.adoc[{dsbulk-migrator}]
** https://docs.datastax.com/en/dsbulk/overview/dsbulk-about.html[{dsbulk-loader}]
* Phase 3
** xref:enable-async-dual-reads.adoc[]
//phase 4
* Phase 4
** xref:change-read-routing.adoc[]
//phase 5
* Phase 5
** xref:connect-clients-to-target.adoc[]
* References
** Troubleshooting
*** xref:troubleshooting.adoc[]
*** xref:troubleshooting.adoc[]
*** xref:troubleshooting-tips.adoc[]
*** xref:troubleshooting-scenarios.adoc[]
** xref:contributions.adoc[]
** xref:faqs.adoc[]
** xref:glossary.adoc[]
** xref:contributions.adoc[]
** xref:release-notes.adoc[]
* {cstar-data-migrator}
** xref:cdm-overview.adoc[]
** xref:cdm-steps.adoc[Migrate data]
* {dsbulk-loader}
** https://docs.datastax.com/en/dsbulk/overview/dsbulk-about.html[Overview]
** https://docs.datastax.com/en/dsbulk/installing/install.html[Installing DataStax Bulk Loader]
** Loading and unloading data
*** https://docs.datastax.com/en/dsbulk/getting-started/simple-load.html[Loading data without a configuration file]
*** https://docs.datastax.com/en/dsbulk/getting-started/simple-unload.html[Unloading data without a configuration file]
*** https://docs.datastax.com/en/dsbulk/developing/loading-unloading-vector-data.html[Loading and unloading vector data]
** Loading and unloading data examples
*** https://docs.datastax.com/en/dsbulk/reference/load.html[Loading data examples]
*** https://docs.datastax.com/en/dsbulk/reference/unload.html[Unloading data examples]
** https://docs.datastax.com/en/dsbulk/reference/dsbulk-cmd.html#escaping-and-quoting-command-line-arguments[Escaping and quoting command line arguments]

.{cass-migrator}
* xref:cdm-overview.adoc[{cass-migrator-short} overview]
* xref:cdm-steps.adoc[Use {cass-migrator-short} to migrate data]
.{dsbulk-loader}
* https://docs.datastax.com/en/dsbulk/overview/dsbulk-about.html[{dsbulk-loader}]
* https://docs.datastax.com/en/dsbulk/installing/install.html[Installing {dsbulk-loader}]
* Loading and unloading data
** https://docs.datastax.com/en/dsbulk/getting-started/simple-load.html[Loading data without a configuration file]
** https://docs.datastax.com/en/dsbulk/getting-started/simple-unload.html[Unloading data without a configuration file]
** https://docs.datastax.com/en/dsbulk/developing/loading-unloading-vector-data.html[Loading and unloading vector data]
** https://docs.datastax.com/en/dsbulk/reference/load.html[Loading data examples]
** https://docs.datastax.com/en/dsbulk/reference/unload.html[Unloading data examples]
* https://docs.datastax.com/en/dsbulk/reference/dsbulk-cmd.html#escaping-and-quoting-command-line-arguments[Escaping and quoting command line arguments]
16 changes: 8 additions & 8 deletions modules/ROOT/pages/cassandra-data-migrator.adoc
Original file line number Diff line number Diff line change
@@ -1,35 +1,35 @@
= {cstar-data-migrator}
= {cass-migrator}
:page-aliases: cdm-parameters.adoc

Use {cstar-data-migrator} to migrate and validate tables between origin and target Cassandra clusters, with available logging and reconciliation support.
Use {cass-migrator} to migrate and validate tables between origin and target {cass-short} clusters, with available logging and reconciliation support.

[[cdm-prerequisites]]
== {cstar-data-migrator} prerequisites
== {cass-migrator} prerequisites

include::partial$cdm-prerequisites.adoc[]

[[cdm-install-as-container]]
== Install {cstar-data-migrator} as a Container
== Install {cass-migrator} as a Container

include::partial$cdm-install-as-container.adoc[]

[[cdm-install-as-jar]]
== Install {cstar-data-migrator} as a JAR file
== Install {cass-migrator} as a JAR file

include::partial$cdm-install-as-jar.adoc[]

[[cdm-build-jar-local]]
== Build {cstar-data-migrator} JAR for local development (optional)
== Build {cass-migrator} JAR for local development (optional)

include::partial$cdm-build-jar-local.adoc[]

[[cdm-steps]]
== Use {cstar-data-migrator}
== Use {cass-migrator}

include::partial$use-cdm-migrator.adoc[]

[[cdm-validation-steps]]
== Use {cstar-data-migrator} steps in validation mode
== Use {cass-migrator} steps in validation mode

include::partial$cdm-validation-steps.adoc[]

Expand Down
14 changes: 7 additions & 7 deletions modules/ROOT/pages/cdm-overview.adoc
Original file line number Diff line number Diff line change
@@ -1,25 +1,25 @@
= Overview
= {cass-migrator} ({cass-migrator-short}) overview

Cassandra Data Migrator (CDM) is a tool designed for migrating and validating data between origin and target Apache Cassandra-compatible clusters. It facilitates the transfer of data, creating multiple jobs at once that can access the Cassandra cluster concurrently. This tool is also useful when dealing with large datasets and requires careful configuration to balance performance impact and migration speed.
{cass-migrator} ({cass-migrator-short}) is a tool designed for migrating and validating data between origin and target {cass-reg}-compatible clusters. It facilitates the transfer of data, creating multiple jobs at once that can access the {cass-short} cluster concurrently. This tool is also useful when dealing with large datasets and requires careful configuration to balance performance impact and migration speed.

The information below explains how to get started with CDM. Review your prerequisites and decide between the two installation options: as a container or as a JAR file.
The information below explains how to get started with {cass-migrator-short}. Review your prerequisites and decide between the two installation options: as a container or as a JAR file.

[[cdm-prerequisites]]
== {cstar-data-migrator} prerequisites
== {cass-migrator} prerequisites

include::partial$cdm-prerequisites.adoc[]

== {cstar-data-migrator} installation methods
== {cass-migrator} installation methods

Both installation methods require attention to version compatibility, especially with the `cdm.properties` files.
Both environments also use `spark-submit` to run the jobs.

[[cdm-install-as-container]]
=== Install {cstar-data-migrator} as a Container
=== Install {cass-migrator} as a Container

include::partial$cdm-install-as-container.adoc[]

[[cdm-install-as-jar]]
=== Install {cstar-data-migrator} as a JAR file
=== Install {cass-migrator} as a JAR file

include::partial$cdm-install-as-jar.adoc[]
8 changes: 4 additions & 4 deletions modules/ROOT/pages/cdm-steps.adoc
Original file line number Diff line number Diff line change
@@ -1,14 +1,14 @@
= {cstar-data-migrator}
= {cass-migrator}

Use {cstar-data-migrator} to migrate and validate tables between the origin and target Cassandra clusters, with available logging and reconciliation support.
Use {cass-migrator} to migrate and validate tables between the origin and target {cass-short} clusters, with available logging and reconciliation support.

[[cdm-steps]]
== Use {cstar-data-migrator}
== Use {cass-migrator}

include::partial$use-cdm-migrator.adoc[]

[[cdm-validation-steps]]
== Use {cstar-data-migrator} steps in validation mode
== Use {cass-migrator} steps in validation mode

include::partial$cdm-validation-steps.adoc[]

Expand Down
24 changes: 12 additions & 12 deletions modules/ROOT/pages/change-read-routing.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -3,11 +3,11 @@
ifdef::env-github,env-browser,env-vscode[:imagesprefix: ../images/]
ifndef::env-github,env-browser,env-vscode[:imagesprefix: ]

This topic explains how you can configure the {zdm-proxy} to route all reads to Target instead of Origin.
This topic explains how you can configure the {product-proxy} to route all reads to Target instead of Origin.

//include::partial$lightbox-tip.adoc[]

image::{imagesprefix}migration-phase4ra9.png["Phase 4 diagram shows read routing on ZDM Proxy was switched to Target."]
image::{imagesprefix}migration-phase4ra9.png["Phase 4 diagram shows read routing on {product-proxy} was switched to Target."]

For illustrations of all the migration phases, see the xref:introduction.adoc#_migration_phases[Introduction].

Expand All @@ -28,7 +28,7 @@ Example:
read_mode: PRIMARY_ONLY
----
Otherwise, if you don't disable async dual reads, {zdm-proxy} instances would continue to send async reads to Origin, which, although harmless, is unnecessary.
Otherwise, if you don't disable async dual reads, {product-proxy} instances would continue to send async reads to Origin, which, although harmless, is unnecessary.
====

== Changing the read routing configuration
Expand Down Expand Up @@ -56,16 +56,16 @@ Now open the configuration file `vars/zdm_proxy_core_config.yml` for editing.

Change the variable `primary_cluster` to `TARGET`.

Run the playbook that changes the configuration of the existing {zdm-proxy} deployment:
Run the playbook that changes the configuration of the existing {product-proxy} deployment:

[source,bash]
----
ansible-playbook rolling_update_zdm_proxy.yml -i zdm_ansible_inventory
----

Wait for the {zdm-proxy} instances to be restarted by Ansible, one by one.
Wait for the {product-proxy} instances to be restarted by Ansible, one by one.
All instances will now send all reads to Target instead of Origin.
In other words, Target is now the primary cluster, but the {zdm-proxy} is still keeping Origin up-to-date via dual writes.
In other words, Target is now the primary cluster, but the {product-proxy} is still keeping Origin up-to-date via dual writes.

== Verifying the read routing change

Expand All @@ -74,21 +74,21 @@ This is not a required step, but you may wish to do it for peace of mind.

[TIP]
====
Issuing a `DESCRIBE` or a read to any system table through the {zdm-proxy} is *not* a valid verification.
Issuing a `DESCRIBE` or a read to any system table through the {product-proxy} is *not* a valid verification.
The {zdm-proxy} handles reads to system tables differently, by intercepting them and always routing them to Origin, in some cases partly populating them at proxy level.
The {product-proxy} handles reads to system tables differently, by intercepting them and always routing them to Origin, in some cases partly populating them at proxy level.
This means that system reads are *not representative* of how the {zdm-proxy} routes regular user reads: even after you switched the configuration to read from Target as the primary cluster, all system reads will still go to Origin.
This means that system reads are *not representative* of how the {product-proxy} routes regular user reads: even after you switched the configuration to read from Target as the primary cluster, all system reads will still go to Origin.
Although `DESCRIBE` requests are not system requests, they are also generally resolved in a different way to regular requests, and should not be used as a means to verify the read routing behavior.
====

Verifying that the correct routing is taking place is a slightly cumbersome operation, due to the fact that the purpose of the ZDM process is to align the clusters and therefore, by definition, the data will be identical on both sides.
Verifying that the correct routing is taking place is a slightly cumbersome operation, due to the fact that the purpose of the {product-short} process is to align the clusters and therefore, by definition, the data will be identical on both sides.

For this reason, the only way to do a manual verification test is to force a discrepancy of some test data between the clusters.
To do this, you could consider using the xref:connect-clients-to-proxy.adoc#_themis_client[Themis sample client application].
This client application connects directly to Origin, Target and the {zdm-proxy}, inserts some test data in its own table and allows you to view the results of reads from each source.
This client application connects directly to Origin, Target and the {product-proxy}, inserts some test data in its own table and allows you to view the results of reads from each source.
Please refer to its README for more information.

Alternatively, you could follow this manual procedure:
Expand All @@ -99,5 +99,5 @@ For example `CREATE TABLE test_keyspace.test_table(k TEXT PRIMARY KEY, v TEXT);`
Insert a row with any key, and with a value specific to Origin, for example `INSERT INTO test_keyspace.test_table(k, v) VALUES ('1', 'Hello from Origin!');`.
* Now, use `cqlsh` to connect *directly to Target*.
Insert a row with the same key as above, but with a value specific to Target, for example `INSERT INTO test_keyspace.test_table(k, v) VALUES ('1', 'Hello from Target!');`.
* Now, use `cqlsh` to connect to the {zdm-proxy} (see xref:connect-clients-to-proxy.adoc#_connecting_cqlsh_to_the_zdm_proxy[here] for how to do this) and issue a read request for this test table: `SELECT * FROM test_keyspace.test_table WHERE k = '1';`.
* Now, use `cqlsh` to connect to the {product-proxy} (see xref:connect-clients-to-proxy.adoc#_connecting_cqlsh_to_the_zdm_proxy[here] for how to do this) and issue a read request for this test table: `SELECT * FROM test_keyspace.test_table WHERE k = '1';`.
The result will clearly show you where the read actually comes from.
Loading

0 comments on commit b510c20

Please sign in to comment.