You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
*** https://docs.datastax.com/en/dsbulk/getting-started/simple-load.html[Loading data without a configuration file]
50
-
*** https://docs.datastax.com/en/dsbulk/getting-started/simple-unload.html[Unloading data without a configuration file]
51
-
*** https://docs.datastax.com/en/dsbulk/developing/loading-unloading-vector-data.html[Loading and unloading vector data]
52
-
** Loading and unloading data examples
53
-
*** https://docs.datastax.com/en/dsbulk/reference/load.html[Loading data examples]
54
-
*** https://docs.datastax.com/en/dsbulk/reference/unload.html[Unloading data examples]
55
-
** https://docs.datastax.com/en/dsbulk/reference/dsbulk-cmd.html#escaping-and-quoting-command-line-arguments[Escaping and quoting command line arguments]
** https://docs.datastax.com/en/dsbulk/getting-started/simple-load.html[Loading data without a configuration file]
48
+
** https://docs.datastax.com/en/dsbulk/getting-started/simple-unload.html[Unloading data without a configuration file]
49
+
** https://docs.datastax.com/en/dsbulk/developing/loading-unloading-vector-data.html[Loading and unloading vector data]
50
+
** https://docs.datastax.com/en/dsbulk/reference/load.html[Loading data examples]
51
+
** https://docs.datastax.com/en/dsbulk/reference/unload.html[Unloading data examples]
52
+
* https://docs.datastax.com/en/dsbulk/reference/dsbulk-cmd.html#escaping-and-quoting-command-line-arguments[Escaping and quoting command line arguments]
Copy file name to clipboardExpand all lines: modules/ROOT/pages/cassandra-data-migrator.adoc
+8-8Lines changed: 8 additions & 8 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,35 +1,35 @@
1
-
= {cstar-data-migrator}
1
+
= {cass-migrator}
2
2
:page-aliases: cdm-parameters.adoc
3
3
4
-
Use {cstar-data-migrator} to migrate and validate tables between origin and target Cassandra clusters, with available logging and reconciliation support.
4
+
Use {cass-migrator} to migrate and validate tables between origin and target {cass-short} clusters, with available logging and reconciliation support.
5
5
6
6
[[cdm-prerequisites]]
7
-
== {cstar-data-migrator} prerequisites
7
+
== {cass-migrator} prerequisites
8
8
9
9
include::partial$cdm-prerequisites.adoc[]
10
10
11
11
[[cdm-install-as-container]]
12
-
== Install {cstar-data-migrator} as a Container
12
+
== Install {cass-migrator} as a Container
13
13
14
14
include::partial$cdm-install-as-container.adoc[]
15
15
16
16
[[cdm-install-as-jar]]
17
-
== Install {cstar-data-migrator} as a JAR file
17
+
== Install {cass-migrator} as a JAR file
18
18
19
19
include::partial$cdm-install-as-jar.adoc[]
20
20
21
21
[[cdm-build-jar-local]]
22
-
== Build {cstar-data-migrator} JAR for local development (optional)
22
+
== Build {cass-migrator} JAR for local development (optional)
23
23
24
24
include::partial$cdm-build-jar-local.adoc[]
25
25
26
26
[[cdm-steps]]
27
-
== Use {cstar-data-migrator}
27
+
== Use {cass-migrator}
28
28
29
29
include::partial$use-cdm-migrator.adoc[]
30
30
31
31
[[cdm-validation-steps]]
32
-
== Use {cstar-data-migrator} steps in validation mode
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.
3
+
{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.
4
4
5
-
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.
5
+
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.
6
6
7
7
[[cdm-prerequisites]]
8
-
== {cstar-data-migrator} prerequisites
8
+
== {cass-migrator} prerequisites
9
9
10
10
include::partial$cdm-prerequisites.adoc[]
11
11
12
-
== {cstar-data-migrator} installation methods
12
+
== {cass-migrator} installation methods
13
13
14
14
Both installation methods require attention to version compatibility, especially with the `cdm.properties` files.
15
15
Both environments also use `spark-submit` to run the jobs.
Copy file name to clipboardExpand all lines: modules/ROOT/pages/cdm-steps.adoc
+4-4Lines changed: 4 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,14 +1,14 @@
1
-
= {cstar-data-migrator}
1
+
= {cass-migrator}
2
2
3
-
Use {cstar-data-migrator} to migrate and validate tables between the origin and target Cassandra clusters, with available logging and reconciliation support.
3
+
Use {cass-migrator} to migrate and validate tables between the origin and target {cass-short} clusters, with available logging and reconciliation support.
4
4
5
5
[[cdm-steps]]
6
-
== Use {cstar-data-migrator}
6
+
== Use {cass-migrator}
7
7
8
8
include::partial$use-cdm-migrator.adoc[]
9
9
10
10
[[cdm-validation-steps]]
11
-
== Use {cstar-data-migrator} steps in validation mode
This topic explains how you can configure the {zdm-proxy} to route all reads to Target instead of Origin.
6
+
This topic explains how you can configure the {product-proxy} to route all reads to Target instead of Origin.
7
7
8
8
//include::partial$lightbox-tip.adoc[]
9
9
10
-
image::{imagesprefix}migration-phase4ra9.png["Phase 4 diagram shows read routing on ZDM Proxy was switched to Target."]
10
+
image::{imagesprefix}migration-phase4ra9.png["Phase 4 diagram shows read routing on {product-proxy} was switched to Target."]
11
11
12
12
For illustrations of all the migration phases, see the xref:introduction.adoc#_migration_phases[Introduction].
13
13
@@ -28,7 +28,7 @@ Example:
28
28
read_mode: PRIMARY_ONLY
29
29
----
30
30
31
-
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.
31
+
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.
32
32
====
33
33
34
34
== Changing the read routing configuration
@@ -56,16 +56,16 @@ Now open the configuration file `vars/zdm_proxy_core_config.yml` for editing.
56
56
57
57
Change the variable `primary_cluster` to `TARGET`.
58
58
59
-
Run the playbook that changes the configuration of the existing {zdm-proxy} deployment:
59
+
Run the playbook that changes the configuration of the existing {product-proxy} deployment:
Wait for the {zdm-proxy} instances to be restarted by Ansible, one by one.
66
+
Wait for the {product-proxy} instances to be restarted by Ansible, one by one.
67
67
All instances will now send all reads to Target instead of Origin.
68
-
In other words, Target is now the primary cluster, but the {zdm-proxy} is still keeping Origin up-to-date via dual writes.
68
+
In other words, Target is now the primary cluster, but the {product-proxy} is still keeping Origin up-to-date via dual writes.
69
69
70
70
== Verifying the read routing change
71
71
@@ -74,21 +74,21 @@ This is not a required step, but you may wish to do it for peace of mind.
74
74
75
75
[TIP]
76
76
====
77
-
Issuing a `DESCRIBE` or a read to any system table through the {zdm-proxy} is *not* a valid verification.
77
+
Issuing a `DESCRIBE` or a read to any system table through the {product-proxy} is *not* a valid verification.
78
78
79
-
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.
79
+
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.
80
80
81
-
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.
81
+
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.
82
82
83
83
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.
84
84
85
85
====
86
86
87
-
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.
87
+
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.
88
88
89
89
For this reason, the only way to do a manual verification test is to force a discrepancy of some test data between the clusters.
90
90
To do this, you could consider using the xref:connect-clients-to-proxy.adoc#_themis_client[Themis sample client application].
91
-
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.
91
+
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.
92
92
Please refer to its README for more information.
93
93
94
94
Alternatively, you could follow this manual procedure:
@@ -99,5 +99,5 @@ For example `CREATE TABLE test_keyspace.test_table(k TEXT PRIMARY KEY, v TEXT);`
99
99
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!');`.
100
100
* Now, use `cqlsh` to connect *directly to Target*.
101
101
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!');`.
102
-
* 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';`.
102
+
* 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';`.
103
103
The result will clearly show you where the read actually comes from.
0 commit comments