diff --git a/antora.yml b/antora.yml index bf54a64c..cf676316 100644 --- a/antora.yml +++ b/antora.yml @@ -57,8 +57,7 @@ asciidoc: dsbulk-migrator: 'DSBulk Migrator' cass-migrator: 'Cassandra Data Migrator (CDM)' cass-migrator-short: 'CDM' - cass-migrator-repo: 'https://github.com/datastax/cassandra-data-migrator' - cass-migrator-shield: 'image:https://img.shields.io/github/v/release/datastax/cassandra-data-migrator?label=latest[alt="Latest cassandra-data-migrator release on GitHub",link="{cass-migrator-repo}/packages"]' + cass-migrator-repo-url: 'https://github.com/datastax/cassandra-data-migrator' sstable-sideloader: '{astra-db} Sideloader' # Astra role attributes (compare with astra-vector-docs antora.yml) diff --git a/modules/ROOT/nav.adoc b/modules/ROOT/nav.adoc index cb350533..418c2b69 100644 --- a/modules/ROOT/nav.adoc +++ b/modules/ROOT/nav.adoc @@ -40,8 +40,7 @@ * xref:sideloader:troubleshoot-sideloader.adoc[] .{cass-migrator} -* xref:ROOT:cassandra-data-migrator.adoc[] -* {cass-migrator-repo}/releases[{cass-migrator-short} release notes] +* {cass-migrator-repo-url}[About {cass-migrator}] .{dsbulk} * xref:dsbulk:overview:dsbulk-about.adoc[] \ No newline at end of file diff --git a/modules/ROOT/pages/cassandra-data-migrator.adoc b/modules/ROOT/pages/cassandra-data-migrator.adoc deleted file mode 100644 index 205d39e8..00000000 --- a/modules/ROOT/pages/cassandra-data-migrator.adoc +++ /dev/null @@ -1,317 +0,0 @@ -= Use {cass-migrator} with {product-proxy} -:navtitle: Use {cass-migrator-short} -:description: You can use {cass-migrator} for data migration and validation between {cass-reg}-based databases. -:page-aliases: cdm-parameters.adoc, ROOT:cdm-steps.adoc, ROOT:cdm-overview.adoc - -{description} - -[IMPORTANT] -==== -To use {cass-migrator-short} successfully, your origin and target clusters must be {cass-short}-based databases with matching schemas. -==== - -{cass-migrator-short} is best for large or complex migrations that benefit from advanced features and configuration options, such as the following: - -* Logging and run tracking -* Automatic reconciliation -* Performance tuning -* Record filtering -* Column renaming -* Support for advanced data types, including sets, lists, maps, and UDTs -* Support for SSL, including custom cipher algorithms -* Use `writetime` timestamps to maintain chronological write history -* Use Time To Live (TTL) values to maintain data lifecycles - -For more information and a complete list of features, see the {cass-migrator-repo}?tab=readme-ov-file#features[{cass-migrator-short} GitHub repository]. - -== {cass-migrator-short} last-write-wins with {product-proxy} - -You can use {cass-migrator-short} alone, with {product-proxy}, or for data validation after using another data migration tool. - -When using {cass-migrator-short} with {product-proxy}, {cass-short}'s last-write-wins semantics ensure that new, real-time writes accurately take precedence over historical writes. - -Last-write-wins compares the `writetime` of conflicting records, and then retains the most recent write. - -For example, if a new write occurs in your target cluster with a `writetime` of `2023-10-01T12:05:00Z`, and then {cass-migrator-short} migrates a record against the same row with a `writetime` of `2023-10-01T12:00:00Z`, the target cluster retains the data from the new write because it has the most recent `writetime`. - -== Install {cass-migrator-short} - -{company} recommends that you always install the latest version of {cass-migrator-short} to get the latest features, dependencies, and bug fixes. - -=== Install as a container - -Get the latest `cassandra-data-migrator` image that includes all dependencies from https://hub.docker.com/r/datastax/cassandra-data-migrator[DockerHub]. -The container's `assets` directory includes all required migration tools: `cassandra-data-migrator`, `dsbulk`, and `cqlsh`. - -=== Install as a JAR file on a single VM - -For one-off migrations, you can install the {spark-short} binary on a single VM where you will run the {cass-migrator-short} job: - -. Install Java 11 or later, which includes {spark-short} binaries. - -. Install https://spark.apache.org/downloads.html[{spark-reg}] version 3.5.x with Scala 2.13 and {hadoop-reg} 3.3 and later: -+ -.. Get the {spark-reg} tarball from the {spark} archive: -+ -[source,bash,subs="+quotes"] ----- -wget https://archive.apache.org/dist/spark/spark-3.5.**PATCH**/spark-3.5.**PATCH**-bin-hadoop3-scala2.13.tgz ----- -+ -Replace `**PATCH**` with your {spark-short} patch version. -+ -.. Change to the directory where you want install {spark-short}, and then extract the tarball: -+ -[source,bash,subs="+quotes"] ----- -tar -xvzf spark-3.5.**PATCH**-bin-hadoop3-scala2.13.tgz ----- -+ -Replace `**PATCH**` with your {spark-short} patch version. - -. Download the latest {cass-migrator-repo}/packages/1832128/versions[cassandra-data-migrator JAR file] {cass-migrator-shield}. - -. Add the `cassandra-data-migrator` dependency to `pom.xml`: -+ -[source,xml,subs="+quotes"] ----- - - datastax.cdm - cassandra-data-migrator - **VERSION** - ----- -+ -Replace `**VERSION**` with your {cass-migrator-short} version. - -. Run `mvn install`. - -=== Install as a JAR file on a {spark} cluster or {spark-short} Serverless platform - -For large (several terabytes) migrations, complex migrations, and use of {cass-migrator-short} as a long-term data transfer utility, {company} recommends that you use an {spark} cluster or {spark-short} Serverless platform. - -. Install Java 11 or later, which includes {spark-short} binaries. - -. Deploy a https://spark.apache.org/downloads.html[{spark-reg} cluster or {spark-short} Serverless instance] running version 3.5.x with Scala 2.13 and {hadoop-reg} 3.3 and later. -+ -[IMPORTANT] -==== -If you deploy {cass-migrator-short} on a {spark-short} cluster, you must modify your `spark-submit` commands as follows: - -* Replace `--master "local[*]"` with the host and port for your {spark-short} cluster, as in `--master "spark://**MASTER_HOST**:**PORT**"`. -* Remove parameters related to single-VM installations, such as `--driver-memory` and `--executor-memory`. -==== - -. Download the latest {cass-migrator-repo}/packages/1832128/versions[cassandra-data-migrator JAR file] {cass-migrator-shield}. - -. Add the `cassandra-data-migrator` dependency to `pom.xml`: -+ -[source,xml,subs="+quotes"] ----- - - datastax.cdm - cassandra-data-migrator - **VERSION** - ----- -+ -Replace `**VERSION**` with your {cass-migrator-short} version. - -. Run `mvn install`. - -=== Build for local development or Scala 2.12.x environments - -If you need to build the JAR for local development, or your environment only has Scala version 2.12.x, see the alternative installation instructions in the {cass-migrator-repo}?tab=readme-ov-file[{cass-migrator-short} README]. - -== Configure {cass-migrator-short} - -. Create a `cdm.properties` file. -+ -If you use a different name, make sure you specify the correct filename in your `spark-submit` commands. - -. Configure the properties for your environment. -+ -In the {cass-migrator-short} repository, you can find a {cass-migrator-repo}/blob/main/src/resources/cdm.properties[sample properties file with default values], as well as a {cass-migrator-repo}/blob/main/src/resources/cdm-detailed.properties[fully annotated properties file]. -+ -{cass-migrator-short} jobs process all uncommented parameters. -Any parameters that are commented out are ignored or use default values. -+ -If you want to reuse a properties file created for a previous {cass-migrator-short} version, make sure it is compatible with the version you are currently using. -Check the {cass-migrator-repo}/releases[{cass-migrator-short} release notes] for possible breaking changes in interim releases. -For example, the 4.x series of {cass-migrator-short} isn't backwards compatible with earlier properties files. - -. Store your properties file where it can be accessed while running {cass-migrator-short} jobs using `spark-submit`. - -[#migrate] -== Run a {cass-migrator-short} data migration job - -A data migration job copies data from a table in your origin cluster to a table with the same schema in your target cluster. - -To optimize large-scale migrations, {cass-migrator-short} can run multiple concurrent migration jobs on the same table. - -The following `spark-submit` command migrates one table from the origin to the target cluster, using the configuration in your properties file. -The migration job is specified in the `--class` argument. - -.Migration job using a local installation -[source,bash,subs="+quotes,+attributes"] ----- -./spark-submit --properties-file cdm.properties \ ---conf spark.cdm.schema.origin.keyspaceTable="**KEYSPACE_NAME**.**TABLE_NAME**" \ ---master "local[{asterisk}]" --driver-memory 25G --executor-memory 25G \ ---class com.datastax.cdm.job.Migrate cassandra-data-migrator-**VERSION**.jar &> logfile_name_$(date +%Y%m%d_%H_%M).txt ----- - -.Migration job using a {spark-reg} cluster -[source,bash,subs="+quotes"] ----- -./spark-submit --properties-file cdm.properties \ ---conf spark.cdm.schema.origin.keyspaceTable="**KEYSPACE_NAME**.**TABLE_NAME**" \ ---master "spark://**MASTER_HOST**:**PORT**" \ ---class com.datastax.cdm.job.Migrate cassandra-data-migrator-**VERSION**.jar &> logfile_name_$(date +%Y%m%d_%H_%M).txt ----- - -Replace or modify the following, if needed: - -* `--properties-file cdm.properties`: If your properties file has a different name, specify the actual name of your properties file. -+ -Depending on where your properties file is stored, you might need to specify the full or relative file path. - -* `**KEYSPACE_NAME**.**TABLE_NAME**`: Specify the name of the table that you want to migrate and the keyspace that it belongs to. -+ -You can also set `spark.cdm.schema.origin.keyspaceTable` in your properties file using the same format of `**KEYSPACE_NAME**.**TABLE_NAME**`. - -* `--driver-memory` and `--executor-memory` (local installations only): Specify the appropriate memory settings for your environment. - -* `--master` ({spark-short} cluster deployments only): Provide the URL of your {spark-short} cluster. - -* `**VERSION**`: Specify the full {cass-migrator-short} version that you installed, such as `5.2.1`. - -This command generates a log file (`logfile_name_**TIMESTAMP**.txt`) instead of logging output to the console. -For additional modifications to this command, see <>. - -[#cdm-validation-steps] -== Run a {cass-migrator-short} data validation job - -After migrating data, use {cass-migrator-short}'s data validation mode to identify any inconsistencies between the origin and target tables, such as missing or mismatched records. - -Optionally, {cass-migrator-short} can automatically correct discrepancies in the target cluster during validation. - -. Use the following `spark-submit` command to run a data validation job using the configuration in your properties file. -The data validation job is specified in the `--class` argument. -+ -.Validation job using a local installation -[source,bash,subs="+quotes,+attributes"] ----- -./spark-submit --properties-file cdm.properties \ ---conf spark.cdm.schema.origin.keyspaceTable="**KEYSPACE_NAME**.**TABLE_NAME**" \ ---master "local[{asterisk}]" --driver-memory 25G --executor-memory 25G \ ---class com.datastax.cdm.job.DiffData cassandra-data-migrator-**VERSION**.jar &> logfile_name_$(date +%Y%m%d_%H_%M).txt ----- -+ -.Validation job using a {spark-reg} cluster -[source,bash,subs="+quotes"] ----- -./spark-submit --properties-file cdm.properties \ ---conf spark.cdm.schema.origin.keyspaceTable="**KEYSPACE_NAME**.**TABLE_NAME**" \ ---master "spark://**MASTER_HOST**:**PORT**" \ ---class com.datastax.cdm.job.DiffData cassandra-data-migrator-**VERSION**.jar &> logfile_name_$(date +%Y%m%d_%H_%M).txt ----- -+ -Replace or modify the following, if needed: -+ --- -* `--properties-file cdm.properties`: If your properties file has a different name, specify the actual name of your properties file. -+ -Depending on where your properties file is stored, you might need to specify the full or relative file path. - -* `**KEYSPACE_NAME**.**TABLE_NAME**`: Specify the name of the table that you want to validate and the keyspace that it belongs to. -+ -You can also set `spark.cdm.schema.origin.keyspaceTable` in your properties file using the same format of `**KEYSPACE_NAME**.**TABLE_NAME**`. - -* `--driver-memory` and `--executor-memory` (local installations only): Specify the appropriate memory settings for your environment. - -* `--master` ({spark-short} cluster deployments only): Provide the URL of your {spark-short} cluster. - -* `**VERSION**`: Specify the full {cass-migrator-short} version that you installed, such as `5.2.1`. --- - -. Allow the command some time to run, and then open the log file (`logfile_name_**TIMESTAMP**.txt`) and look for `ERROR` entries. -+ -The {cass-migrator-short} validation job records differences as `ERROR` entries in the log file, listed by primary key values. -For example: -+ -[source,plaintext] ----- -23/04/06 08:43:06 ERROR DiffJobSession: Mismatch row found for key: [key3] Mismatch: Target Index: 1 Origin: valueC Target: value999) -23/04/06 08:43:06 ERROR DiffJobSession: Corrected mismatch row in target: [key3] -23/04/06 08:43:06 ERROR DiffJobSession: Missing target row found for key: [key2] -23/04/06 08:43:06 ERROR DiffJobSession: Inserted missing row in target: [key2] ----- -+ -When validating large datasets or multiple tables, you might want to extract the complete list of missing or mismatched records. -There are many ways to do this. -For example, you can grep for all `ERROR` entries in your {cass-migrator-short} log files or use the `log4j2` example provided in the {cass-migrator-repo}?tab=readme-ov-file#steps-for-data-validation[{cass-migrator-short} repository]. - -=== Run a validation job in AutoCorrect mode - -Optionally, you can run {cass-migrator-short} validation jobs in **AutoCorrect** mode, which offers the following functions: - -* `autocorrect.missing`: Add any missing records in the target with the value from the origin. - -* `autocorrect.mismatch`: Reconcile any mismatched records between the origin and target by replacing the target value with the origin value. -+ -[IMPORTANT] -==== -Timestamps have an effect on this function. - -If the `writetime` of the origin record (determined with `.writetime.names`) is before the `writetime` of the corresponding target record, then the original write won't appear in the target cluster. - -This comparative state can be challenging to troubleshoot if individual columns or cells were modified in the target cluster. -==== - -* `autocorrect.missing.counter`: By default, counter tables are not copied when missing, unless explicitly set. - -In your `cdm.properties` file, use the following properties to enable (`true`) or disable (`false`) autocorrect functions: - -[source,properties] ----- -spark.cdm.autocorrect.missing false|true -spark.cdm.autocorrect.mismatch false|true -spark.cdm.autocorrect.missing.counter false|true ----- - -The {cass-migrator-short} validation job never deletes records from either the origin or target. -Data validation only inserts or updates data on the target. - -For an initial data validation, consider disabling AutoCorrect so that you can generate a list of data discrepancies, investigate those discrepancies, and then decide whether you want to rerun the validation with AutoCorrect enabled. - -[#advanced] -== Additional {cass-migrator-short} options - -You can modify your properties file or append additional `--conf` arguments to your `spark-submit` commands to customize your {cass-migrator-short} jobs. -For example, you can do the following: - -* Check for large field guardrail violations before migrating. -* Use the `partition.min` and `partition.max` parameters to migrate or validate specific token ranges. -* Use the `track-run` feature to monitor progress and rerun a failed migration or validation job from point of failure. - -For all options, see the {cass-migrator-repo}[{cass-migrator-short} repository]. -Specifically, see the {cass-migrator-repo}/blob/main/src/resources/cdm-detailed.properties[fully annotated properties file]. - -== Troubleshoot {cass-migrator-short} - -Java NoSuchMethodError:: -If you installed {spark-short} as a JAR file, and your {spark-short} and Scala versions aren't compatible with your installed version of {cass-migrator-short}, {cass-migrator-short} jobs can throw exceptions such a the following: -+ -[source,console] ----- -Exception in thread "main" java.lang.NoSuchMethodError: 'void scala.runtime.Statics.releaseFence()' ----- -+ -Make sure that your {spark-short} binary is compatible with your {cass-migrator-short} version. -If you installed an earlier version of {cass-migrator-short}, you might need to install an earlier {spark-short} binary. - -Rerun a failed or partially completed job:: -You can use the `track-run` feature to track the progress of a migration or validation, and then, if necessary, use the `run-id` to rerun a failed job from the last successful migration or validation point. -+ -For more information, see the {cass-migrator-repo}[{cass-migrator-short} repository] and the {cass-migrator-repo}/blob/main/src/resources/cdm-detailed.properties[fully annotated properties file]. \ No newline at end of file diff --git a/modules/ROOT/pages/components.adoc b/modules/ROOT/pages/components.adoc index 474b602a..cb1d839d 100644 --- a/modules/ROOT/pages/components.adoc +++ b/modules/ROOT/pages/components.adoc @@ -163,7 +163,7 @@ It offers extensive functionality and configuration options to support large and You can use {cass-migrator-short} by itself, with {product-proxy}, or for data validation after using another data migration tool. -For more information, see xref:ROOT:cassandra-data-migrator.adoc[]. +For more information, see the {cass-migrator-repo-url}[{cass-migrator-short} repository]. === {dsbulk} diff --git a/modules/ROOT/pages/faqs.adoc b/modules/ROOT/pages/faqs.adoc index 94c27096..1216d307 100644 --- a/modules/ROOT/pages/faqs.adoc +++ b/modules/ROOT/pages/faqs.adoc @@ -109,7 +109,7 @@ For any observed problems with {product-proxy} or the other open-source {product * {product-proxy-repo}[{product-proxy} repository] * {product-automation-repo}[{product-automation} repository] (includes {product-automation} and {product-utility}) -* {cass-migrator-repo}[{cass-migrator-short} repository] +* {cass-migrator-repo-url}[{cass-migrator-short} repository] * {dsbulk-repo}[{dsbulk-short} repository] == Can I contribute to {product-proxy}? diff --git a/modules/ROOT/pages/feasibility-checklists.adoc b/modules/ROOT/pages/feasibility-checklists.adoc index 85c8eb0e..25881fd4 100644 --- a/modules/ROOT/pages/feasibility-checklists.adoc +++ b/modules/ROOT/pages/feasibility-checklists.adoc @@ -153,7 +153,7 @@ By design, a {product-short} migration involves two separate clusters, and it is If you use non-idempotent operations, {company} recommends adding a reconciliation phase to your migration before and after xref:ROOT:change-read-routing.adoc[Phase 4]. This allows you an additional opportunity to resolve any data inconsistencies that are produced by non-idempotent operations. -The xref:ROOT:cassandra-data-migrator.adoc[{cass-migrator-short}] is ideal for detecting and reconciling these types of inconsistencies. +{cass-migrator-repo-url}[{cass-migrator-short}] is ideal for detecting and reconciling these types of inconsistencies. However, if your application workloads can tolerate inconsistencies produced by LWTs and non-idempotent operations, you might not need to perform any additional validation or reconciliation steps. This depends entirely on your application business logic and requirements. diff --git a/modules/ROOT/pages/hcd-migration-paths.adoc b/modules/ROOT/pages/hcd-migration-paths.adoc index f793e25c..4110dc08 100644 --- a/modules/ROOT/pages/hcd-migration-paths.adoc +++ b/modules/ROOT/pages/hcd-migration-paths.adoc @@ -25,7 +25,7 @@ During the {product-short} process, you use a xref:ROOT:migrate-and-validate-dat {company} recommends that you do the following: -* Choose a data migration tool that also includes strong validation capabilities, such as xref:ROOT:cassandra-data-migrator.adoc[{cass-migrator}]. +* Choose a data migration tool that also includes strong validation capabilities, such as {cass-migrator-repo-url}[{cass-migrator}]. * Be aware of incompatible data types that can fail to migrate from your old cluster. Data validation tools can identify inconsistencies as missing or mismatched data, but you still need to have a plan to resolve them. diff --git a/modules/ROOT/pages/index.adoc b/modules/ROOT/pages/index.adoc index 65997e64..a31647da 100644 --- a/modules/ROOT/pages/index.adoc +++ b/modules/ROOT/pages/index.adoc @@ -73,7 +73,7 @@ svg::sideloader:astra-migration-toolkit.svg[role="absolute bottom-1/2 translate-

{cass-migrator-short} can migrate and validate data between {cass-short}-based clusters, with optional logging and reconciliation support.

- xref:ROOT:cassandra-data-migrator.adoc[Get started with {cass-migrator-short}] + {cass-migrator-repo-url}[Get started with {cass-migrator-short}]
diff --git a/modules/ROOT/pages/migrate-and-validate-data.adoc b/modules/ROOT/pages/migrate-and-validate-data.adoc index 91abb545..71d50722 100644 --- a/modules/ROOT/pages/migrate-and-validate-data.adoc +++ b/modules/ROOT/pages/migrate-and-validate-data.adoc @@ -39,7 +39,7 @@ It offers extensive functionality and configuration options to support large and You can use {cass-migrator-short} alone, with {product-proxy}, or for data validation after using another data migration tool. -For more information, see xref:ROOT:cassandra-data-migrator.adoc[]. +For more information, see the {cass-migrator-repo-url}[{cass-migrator-short} repository]. == {dsbulk} diff --git a/modules/ROOT/pages/troubleshooting-tips.adoc b/modules/ROOT/pages/troubleshooting-tips.adoc index 72cf5d23..43a6e64a 100644 --- a/modules/ROOT/pages/troubleshooting-tips.adoc +++ b/modules/ROOT/pages/troubleshooting-tips.adoc @@ -491,7 +491,7 @@ To report an issue or get additional support, submit an issue in the {product-sh * {product-proxy-repo}/issues[{product-proxy} repository] * {product-automation-repo}/issues[{product-automation} repository] (includes {product-automation} and {product-utility}) -* {cass-migrator-repo}/issues[{cass-migrator-short} repository] +* {cass-migrator-repo-url}/issues[{cass-migrator-short} repository] * {dsbulk-repo}/issues[{dsbulk-short} repository] [IMPORTANT] diff --git a/modules/sideloader/pages/prepare-sideloader.adoc b/modules/sideloader/pages/prepare-sideloader.adoc index 1f3ce2d9..f3d0468f 100644 --- a/modules/sideloader/pages/prepare-sideloader.adoc +++ b/modules/sideloader/pages/prepare-sideloader.adoc @@ -161,7 +161,7 @@ If you choose the alternative option, you must modify the commands accordingly f * *{sstable-sideloader} doesn't support encrypted data*: If your origin cluster uses xref:6.9@dse:securing:transparent-data-encryption.adoc[{dse-short} Transparent Data Encryption], be aware that {sstable-sideloader} cannot migrate these SSTables. + If you have a mix of encrypted and unencrypted data, you can use {sstable-sideloader} to migrate the unencrypted data. -After the initial migration, you can use another strategy to move the encrypted data, such as {cass-migrator-repo}[{cass-migrator}] or a manual export and reupload. +After the initial migration, you can use another strategy to move the encrypted data, such as {cass-migrator-repo-url}[{cass-migrator}] or a manual export and reupload. * *{sstable-sideloader} doesn't support secondary indexes*: If you don't remove or replace these in your origin cluster, {sstable-sideloader} ignores these directories when importing the data to your {astra-db} database. @@ -173,7 +173,7 @@ Your administration server must have SSH access to each node in your origin clus {company} recommends that you install the following additional software on your administration server: -* {cass-migrator-repo}[{cass-migrator-short}] to validate imported data and, with {product-proxy}, reconcile it with the origin cluster. +* {cass-migrator-repo-url}[{cass-migrator-short}] to validate imported data and, with {product-proxy}, reconcile it with the origin cluster. * https://jqlang.github.io/jq/[jq] to format JSON responses from the {astra} {devops-api}. The {devops-api} commands in this guide use this tool. @@ -237,7 +237,7 @@ The number of node snapshots that you uploaded to the migration bucket doesn't d The success of the import depends primarily on the validity of the schemas and the data in the snapshots. . After the import, validate the migrated data to ensure that it matches the data in the origin cluster. -For example, you can xref:ROOT:cassandra-data-migrator.adoc#cdm-validation-steps[run {cass-migrator-short} in validation mode]. +For example, you can {cass-migrator-repo-url}?tab=readme-ov-file#steps-for-data-validation[run {cass-migrator-short} in validation mode]. ==== Migrate multiple nodes to multiple databases @@ -278,7 +278,7 @@ The number of node snapshots that you uploaded to the migration bucket doesn't d The success of the import depends primarily on the validity of the schemas and the data in the snapshots.\ . After the import, validate the migrated data to ensure that it matches the data in the origin cluster. -For example, you can xref:ROOT:cassandra-data-migrator.adoc#cdm-validation-steps[run {cass-migrator-short} in validation mode]. +For example, you can {cass-migrator-repo-url}?tab=readme-ov-file#steps-for-data-validation[run {cass-migrator-short} in validation mode]. === Multiple migrations to the same database @@ -297,7 +297,7 @@ For example, if you have 10 migration IDs for the same database, you must run 10 Each import must completely finish before starting the next import. After all of the imports are complete, validate the migrated data in your target database to ensure that it matches the data in the origin cluster. -For example, you can xref:ROOT:cassandra-data-migrator.adoc#cdm-validation-steps[run {cass-migrator-short} in validation mode]. +For example, you can {cass-migrator-repo-url}?tab=readme-ov-file#steps-for-data-validation[run {cass-migrator-short} in validation mode]. == Next steps diff --git a/modules/sideloader/pages/sideloader-overview.adoc b/modules/sideloader/pages/sideloader-overview.adoc index c6a9c73a..a1978222 100644 --- a/modules/sideloader/pages/sideloader-overview.adoc +++ b/modules/sideloader/pages/sideloader-overview.adoc @@ -4,7 +4,7 @@ {sstable-sideloader} is a service running in {astra-db} that directly imports data from snapshot backups that you've uploaded to {astra-db} from an existing {cass-reg}, {dse}, or {hcd} cluster. -Because it imports data directly, {sstable-sideloader} can offer several advantages over CQL-based tools like xref:dsbulk:overview:dsbulk-about.adoc[{dsbulk}] and xref:ROOT:cassandra-data-migrator.adoc[{cass-migrator}], including faster, more cost-effective data loading, and minimal performance impacts on your origin cluster and target database. +Because it imports data directly, {sstable-sideloader} can offer several advantages over CQL-based tools like xref:dsbulk:overview:dsbulk-about.adoc[{dsbulk}] and {cass-migrator-repo-url}[{cass-migrator}], including faster, more cost-effective data loading, and minimal performance impacts on your origin cluster and target database. == {sstable-sideloader} concepts diff --git a/modules/sideloader/partials/validate.adoc b/modules/sideloader/partials/validate.adoc index bac5da4d..df391ab1 100644 --- a/modules/sideloader/partials/validate.adoc +++ b/modules/sideloader/partials/validate.adoc @@ -1,4 +1,4 @@ After the migration is complete, you can query the migrated data using the xref:astra-db-serverless:cql:develop-with-cql.adoc#connect-to-the-cql-shell[{cql-shell}] (`cqlsh`) or xref:astra-db-serverless:api-reference:row-methods/find-many.adoc[{data-api}]. -You can xref:ROOT:cassandra-data-migrator.adoc#cdm-validation-steps[run {cass-migrator-short} in validation mode] for more thorough validation. +You can {cass-migrator-repo-url}?tab=readme-ov-file#steps-for-data-validation[run {cass-migrator-short} in validation mode] for more thorough validation. {cass-migrator-short} also offers an AutoCorrect mode to reconcile any differences that it detects. \ No newline at end of file