{"componentChunkName":"component---src-templates-tags-js","path":"/tags/migration/1","result":{"pageContext":{"tag":"migration","urlTag":"migration","chunk":[{"content":"

\"GitHub \"Go

\"cql-proxy\"

cql-proxy is designed to forward your application's CQL traffic to an appropriate database service. It listens on a local address and securely forwards that traffic.

The cql-proxy sidecar enables unsupported CQL drivers to work with DataStax Astra. These drivers include both legacy DataStax drivers and community-maintained CQL drivers, such as the gocql driver and the rust-driver.

cql-proxy also enables applications that are currently using Apache Cassandra or DataStax Enterprise (DSE) to use Astra without requiring any code changes. Your application just needs to be configured to use the proxy.

If you're building a new application using DataStax drivers, cql-proxy is not required, as the drivers can communicate directly with Astra. DataStax drivers have excellent support for Astra out-of-the-box, and are well-documented in the driver-guide guide.

Use the -h or --help flag to display a listing all flags and their corresponding descriptions and environment variables (shown below as items starting with $):

$ ./cql-proxy -h\nUsage: cql-proxy\nFlags:\n  -h, --help                                              Show context-sensitive help.\n  -b, --astra-bundle=STRING                               Path to secure connect bundle for an Astra database. Requires '--username' and '--password'. Ignored if using the\n                                                          token or contact points option ($ASTRA_BUNDLE).\n  -t, --astra-token=STRING                                Token used to authenticate to an Astra database. Requires '--astra-database-id'. Ignored if using the bundle path\n                                                          or contact points option ($ASTRA_TOKEN).\n  -i, --astra-database-id=STRING                          Database ID of the Astra database. Requires '--astra-token' ($ASTRA_DATABASE_ID)\n      --astra-api-url=\"https://api.astra.datastax.com\"    URL for the Astra API ($ASTRA_API_URL)\n      --astra-timeout=10s                                 Timeout for contacting Astra when retrieving the bundle and metadata ($ASTRA_TIMEOUT)\n  -c, --contact-points=CONTACT-POINTS,...                 Contact points for cluster. Ignored if using the bundle path or token option ($CONTACT_POINTS).\n  -u, --username=STRING                                   Username to use for authentication ($USERNAME)\n  -p, --password=STRING                                   Password to use for authentication ($PASSWORD)\n  -r, --port=9042                                         Default port to use when connecting to cluster ($PORT)\n  -n, --protocol-version=\"v4\"                             Initial protocol version to use when connecting to the backend cluster (default: v4, options: v3, v4, v5, DSEv1,\n                                                          DSEv2) ($PROTOCOL_VERSION)\n  -m, --max-protocol-version=\"v4\"                         Max protocol version supported by the backend cluster (default: v4, options: v3, v4, v5, DSEv1, DSEv2)\n                                                          ($MAX_PROTOCOL_VERSION)\n  -a, --bind=\":9042\"                                      Address to use to bind server ($BIND)\n  -f, --config=CONFIG                                     YAML configuration file ($CONFIG_FILE)\n      --debug                                             Show debug logging ($DEBUG)\n      --health-check                                      Enable liveness and readiness checks ($HEALTH_CHECK)\n      --http-bind=\":8000\"                                 Address to use to bind HTTP server used for health checks ($HTTP_BIND)\n      --heartbeat-interval=30s                            Interval between performing heartbeats to the cluster ($HEARTBEAT_INTERVAL)\n      --idle-timeout=60s                                  Duration between successful heartbeats before a connection to the cluster is considered unresponsive and closed\n                                                          ($IDLE_TIMEOUT)\n      --readiness-timeout=30s                             Duration the proxy is unable to connect to the backend cluster before it is considered not ready\n                                                          ($READINESS_TIMEOUT)\n      --idempotent-graph                                  If true it will treat all graph queries as idempotent by default and retry them automatically. It may be\n                                                          dangerous to retry some graph queries -- use with caution ($IDEMPOTENT_GRAPH).\n      --num-conns=1                                       Number of connection to create to each node of the backend cluster ($NUM_CONNS)\n      --proxy-cert-file=STRING                            Path to a PEM encoded certificate file with its intermediate certificate chain. This is used to encrypt traffic\n                                                          for proxy clients ($PROXY_CERT_FILE)\n      --proxy-key-file=STRING                             Path to a PEM encoded private key file. This is used to encrypt traffic for proxy clients ($PROXY_KEY_FILE)\n      --rpc-address=STRING                                Address to advertise in the 'system.local' table for 'rpc_address'. It must be set if configuring peer proxies\n                                                          ($RPC_ADDRESS)\n      --data-center=STRING                                Data center to use in system tables ($DATA_CENTER)\n      --tokens=TOKENS,...                                 Tokens to use in the system tables. It's not recommended ($TOKENS)

To pass configuration to cql-proxy, either command-line flags, environment variables, or a configuration file can be used. Using the docker method as an example, the following samples show how the token and database ID are defined with each method.

docker run -p 9042:9042 \\\n  --rm datastax/cql-proxy:v0.1.5 \\\n  --astra-token <astra-token> --astra-database-id <astra-datbase-id>
docker run -p 9042:9042  \\\n  --rm datastax/cql-proxy:v0.1.5 \\\n  -e ASTRA_TOKEN=<astra-token> -e ASTRA_DATABASE_ID=<astra-datbase-id>

Proxy settings can also be passed using a configuration file with the --config /path/to/proxy.yaml flag. This can be mixed and matched with command-line flags and environment variables. Here are some example configuration files:

contact-points:\n  - 127.0.0.1\nusername: cassandra\npassword: cassandra\nport: 9042\nbind: 127.0.0.1:9042\n# ...

or with a Astra token:

astra-token: <astra-token>\nastra-database-id: <astra-database-id>\nbind: 127.0.0.1:9042\n# ...

All configuration keys match their command-line flag counterpart, e.g. --astra-bundle is astra-bundle:, --contact-points is contact-points: etc.

Multi-region failover with DC-aware load balancing policy is the most useful case for a multiple proxy setup.

When configuring peers: it is required to set --rpc-address (or rpc-address: in the yaml) for each proxy and it must match is corresponding peers: entry. Also, peers: is only available in the configuration file and cannot be set using a command-line flag.

Here's an example of configuring multi-region failover with two proxies. A proxy is started for each region of the cluster connecting to it using that region's bundle. They all share a common configuration file that contains the full list of proxies.

Note: Only bundles are supported for multi-region setups.

cql-proxy --astra-bundle astra-region1-bundle.zip --username token --password <astra-token> \\\n  --bind 127.0.0.1:9042 --rpc-address 127.0.0.1 --data-center dc-1 --config proxy.yaml
cql-proxy ---astra-bundle astra-region2-bundle.zip --username token --password <astra-token> \\\n  --bind 127.0.0.2:9042 --rpc-address 127.0.0.2 --data-center dc-2 --config proxy.yaml

The peers settings are configured using a yaml file. It's a good idea to explicitly provide the --data-center flag, otherwise; these values are pulled from the backend cluster and would need to be pulled from the system.local and system.peers table to properly setup the peers data-center: values. Here's an example proxy.yaml:

peers:\n  - rpc-address: 127.0.0.1\n    data-center: dc-1\n  - rpc-address: 127.0.0.2\n    data-center: dc-2

Note: It's okay for the peers: to contain entries for the current proxy itself because they'll just be omitted.

There are three methods for using cql-proxy:

  1. \n

    Build cql-proxy.

    \n
    go build
    \n
    2. \n
  2. \n

    Run with your desired database.

    \n
    3. \n
  1. \n

    Run with your desired database.

    \n
    2. \n

If you wish to have the docker image removed after you are done with it, add --rm before the image name datastax/cql-proxy:v0.1.5.

Using Kubernetes with cql-proxy requires a number of steps:

  1. \n

    Generate a token following the Astra instructions. This step will display your Client ID, Client Secret, and Token; make sure you download the information for the next steps. Store the secure bundle in /tmp/scb.zip to match the example below.

    \n
    2. \n
  2. \n

    Create cql-proxy.yaml. You'll need to add three sets of information: arguments, volume mounts, and volumes. A full example can be found here.

    \n
    3. \n
  1. \n

    Create a configmap. Use the same secure bundle that was specified in the cql-proxy.yaml.

    \n
    kubectl create configmap cql-proxy-configmap --from-file /tmp/scb.zip
    \n
    2. \n
  2. \n

    Check the configmap that was created.

    \n
    kubectl describe configmap cql-proxy-configmap\n  Name:         cql-proxy-configmap\n  Namespace:    default\n  Labels:       <none>\n  Annotations:  <none>\n  Data\n  ====\n  BinaryData\n  ====\n  scb.zip: 12311 bytes
    \n
    3. \n
  3. \n

    Create a Kubernetes deployment with the YAML file you created:

    \n
    kubectl create -f cql-proxy.yaml
    \n
    4. \n
  4. \n

    Check the logs:

    \n
    kubectl logs <deployment-name>
    \n
    5. \n

Drivers that use token-aware load balancing may print a warning or may not work when using cql-proxy. Because cql-proxy abstracts the backend cluster as a single endpoint this doesn't always work well with token-aware drivers that expect there to be at least \"replication factor\" number of nodes in the cluster. Many drivers print a warning (which can be ignored) and fallback to something like round-robin, but other drivers might fail with an error. For the drivers that fail with an error it is required that they disable token-aware or configure the round-robin load balancing policy.

","id":"515fda8f-d1a1-5d7c-bfc6-6d72984fb6c1","title":"GitHub - datastax/cql-proxy: A client-side CQL proxy/sidecar.","origin_url":"https://github.com/datastax/cql-proxy","url":"https://github.com/datastax/cql-proxy","wallabag_created_at":"2024-11-01T17:26:01+00:00","published_at":null,"published_by":"['datastax']","reading_time":8,"domain_name":"github.com","preview_picture":"https://opengraph.githubassets.com/c2528e3426d98910ed27819e048b4c1081fab2ed2c7adbea6e6a3b1872deb30a/datastax/cql-proxy","tags":["migration","proxy","cassandra","cql"],"description":" cql-proxy is designed to forward your application's CQL traffic to an appropriate database service. It listens on a local address and securely forwards that traffic.The cql-proxy sidecar enables unsu..."},{"content":"
\n

Zero Downtime Migration (ZDM) Proxy is an open-source component developed in Go and based on client-server architecture. It enables you to migrate from one Apache Cassandra® cluster to another without downtime or code changes in the application client.

For details on ZDM Proxy, see zdm-proxy GitHub.

When using ZDM Proxy, the client connects to the proxy rather than to the source cluster. The proxy connects both to the source cluster and the target cluster. It sends read requests to the source cluster only, while write requests are forwarded to both clusters.

For details on how ZDM Proxy works, see Introduction to Zero Downtime Migration.

Connect to your Aiven for Apache Cassandra service using cqlsh, for example.

cqlsh --ssl-u avnadmin -p YOUR_SECRET_PASSWORD cassandra-target-cluster-name.a.avns.net 12345

You can expect to receive output similar to the following:

Connected to a1b2c3d4-1a2b-3c4d-5e6f-a1b2c3d4e5f6 at cassandra-target-cluster-name.a.avns.net:12345
[cqlsh 6.1.0 | Cassandra 4.0.11 | CQL spec 3.4.5 | Native protocol v5]

In your target service, create the same keyspaces and tables you have in your source Apache Cassandra cluster.

create keyspace KEYSPACE_NAME with replication ={'class':'SimpleStrategy', 'replication_factor':3};
create table KEYSPACE_NAME.TABLE_NAME (n_id int, value int, primary key (n_id));

Download the ZDM Proxy's binary from ZDM Proxy releases.

wget https://github.com/datastax/zdm-proxy/releases/download/v2.1.0/zdm-proxy-linux-amd64-v2.1.0.tgz
tar xf zdm-proxy-linux-amd64-v2.1.0.tgz

Check if the binary has been downloaded successfully using ls in the relevant directory. You can expect to receive output similar to the following:

LICENSE  zdm-proxy-linux-amd64-v2.1.0.tgz  zdm-proxy-v2.1.0
  1. \n

    Specify connection information by setting ZDM_TARGET_* and ZDM_ORIGIN_* environment variables using the export command.

    \n

    note

    ORIGIN refers to the source service.

    \n
    2. \n
  2. \n

    Run the binary.

    \n
    3. \n
exportZDM_ORIGIN_CONTACT_POINTS=localhost
exportZDM_ORIGIN_USERNAME=cassandra
exportZDM_ORIGIN_PASSWORD=cassandra
exportZDM_ORIGIN_PORT=1234
exportZDM_TARGET_CONTACT_POINTS=cassandra-target-cluster-name.a.avns.net
exportZDM_TARGET_USERNAME=avnadmin
exportZDM_TARGET_PASSWORD=YOUR_SECRET_PASSWORD
exportZDM_TARGET_PORT=12345
exportZDM_TARGET_TLS_SERVER_CA_PATH=\"/tmp/ca.pem\"
exportZDM_TARGET_ENABLE_HOST_ASSIGNMENT=false
# ZDM_ORIGIN_ENABLE_HOST_ASSIGNMENT=false  # (may be needed, see note)
./zdm-proxy-v2.1.0

ENABLE_HOST_ASSIGNMENT

Make sure you set the ZDM_TARGET_ENABLE_HOST_ASSIGNMENT variable. Otherwise, ZDM Proxy tries to connect to one of internal addresses of the cluster nodes, which are unavailable from outside. If this occurs to your source cluster, set ZDM_ORIGIN_ENABLE_HOST_ASSIGNMENT=false.

To connect to ZDM Proxy, use, for example, cqlsh. Provide connection details and, if your source or target require authentication, specify target username and password.

Check more details on using the credentials in Client application credentials.

The port that ZDM Proxy uses is 14002, which can be overridden.

  1. \n

    Connect using ZDM Proxy.

    \n
    cqlsh -u avnadmin -p YOUR_SECRET_PASSWORD localhost 14002
    \n

    You can expect to receive output similar to the following:

    \n
    Connected to CLUSTER_NAME at localhost:14002
    [cqlsh 6.1.0 | Cassandra 4.1.3 | CQL spec 3.4.6 | Native protocol v4]
    \n
    2. \n
  2. \n

    Check data in the table.

    \n
    select * from KEYSPACE_NAME.TABLE_NAME;
    \n

    You can expect to receive output similar to the following:

    \n
    n_id | value
    ------+-------
    1|42
    2|44
    3|46
    (3 rows)
    \n
    3. \n
  3. \n

    Insert more data into the table to test how ZDM Proxy handles write request.

    \n
    insert into KEYSPACE_NAME.TABLE_NAME (n_id, value) values (4, 48);
    insert into KEYSPACE_NAME.TABLE_NAME (n_id, value) values (5, 50);
    \n
    4. \n
  4. \n

    Check again data inside the table.

    \n
    select * from KEYSPACE_NAME.TABLE_NAME;
    \n

    You can expect to receive output similar to the following:

    \n
    n_id | value
    ------+-------
    5|50
    1|42
    2|44
    4|48
    3|46
    (5 rows)
    \n
    5. \n
  1. \n

    Connect to the source:

    \n
    cqlsh localhost 1234
    \n

    You can expect to receive output similar to the following:

    \n
    Connected to SOURCE_CLUSTER_NAME at localhost:1234
    [cqlsh 6.1.0 | Cassandra 4.1.3 | CQL spec 3.4.6 | Native protocol v5]
    \n
    2. \n
  2. \n

    Check data in the table:

    \n
    select * from KEYSPACE_NAME.TABLE_NAME;
    \n

    You can expect to receive output similar to the following:

    \n
    n_id | value
    ------+-------
    5|50
    1|42
    2|44
    4|48
    3|46
    (5 rows)
    \n

    ZDM Proxy has forwarded both the write request and the read request to the source cluster. As a result, all the values are there: both newly-added ones (50 and 48) and previously added ones (42, 44, and 46).

    \n
    3. \n
  1. \n

    Connect to the target service.

    \n
    cqlsh --ssl-u avnadmin -p YOUR_SECRET_PASSWORD cassandra-target-cluster-name.a.avns.net 12345
    \n

    You can expect to receive output similar to the following:

    \n
    Connected to a1b2c3d4-1a2b-3c4d-5e6f-a1b2c3d4e5f6 at cassandra-target-cluster-name.a.avns.net:12345
    [cqlsh 6.1.0 | Cassandra 4.0.11 | CQL spec 3.4.5 | Native protocol v5]
    \n
    2. \n
  2. \n

    Check data in the table.

    \n
    select * from KEYSPACE_NAME.TABLE_NAME;
    \n

    You can expect to receive output similar to the following:

    \n
    n_id | value
    ------+-------
    5|50
    4|48
    (2 rows)
    \n

    50 and 48 are there in the target table since ZDM Proxy has forwarded the write request to the target service. 42, 44, and 46 are not there since ZDM Proxy has not sent the read request to the target service.

    \n
    3. \n
","id":"c5cf2b78-00ff-560c-a008-3227fd0643b3","title":"Migrate to Aiven for Apache Cassandra® with no downtime | Aiven docs","origin_url":"https://aiven.io/docs/products/cassandra/howto/zdm-proxy","url":"https://aiven.io/docs/products/cassandra/howto/zdm-proxy","wallabag_created_at":"2024-11-01T17:25:08+00:00","published_at":null,"published_by":null,"reading_time":4,"domain_name":"aiven.io","preview_picture":"https://aiven.io/docs/images/site-preview.png","tags":["migration","proxy","cassandra","aiven"],"description":"\nZero Downtime Migration (ZDM) Proxy is an open-source component developed in Go and based on client-server architecture. It enables you to migrate from one Apache Cassandra® cluster to another withou..."},{"content":"

The ZDM Proxy is client-server component written in Go that enables users to migrate with zero downtime from an Apache Cassandra® cluster to another (which may be an Astra cluster) and not requiring code changes in the application client.

The only change to the client is pointing it to the proxy rather than directly to the original cluster (Origin). In turn, the proxy connects to both Origin and Target clusters.

By default, the proxy will forward read requests only to the Origin cluster, though you can optionally configure it to forward reads to both clusters asynchronously, while writes will always be sent to both clusters concurrently.

An overview of the proxy architecture and logical flow can be viewed here.

In order to run the proxy, you'll need to set some environment variables or pass reference to YAML configuration file. Below you'll find a list with the most important variables along with their default values. The required ones are marked with a comment. Variable names for YAML configuration file do not have ZDM_ prefix and are lower-cased.

ZDM_ORIGIN_CONTACT_POINTS=10.0.0.1  #required\nZDM_ORIGIN_USERNAME=cassandra       #required\nZDM_ORIGIN_PASSWORD=cassandra       #required\nZDM_ORIGIN_PORT=9042\nZDM_TARGET_CONTACT_POINTS=10.0.0.2  #required\nZDM_TARGET_USERNAME=cassandra       #required\nZDM_TARGET_PASSWORD=cassandra       #required\nZDM_TARGET_PORT=9042\nZDM_PROXY_LISTEN_PORT=14002\nZDM_PROXY_LISTEN_ADDRESS=127.0.0.1\nZDM_PRIMARY_CLUSTER=ORIGIN\nZDM_READ_MODE=PRIMARY_ONLY\nZDM_LOG_LEVEL=INFO

The environment variables (or YAM configuration file) must be set for the proxy to work.

In order to get started quickly, in your local environment, grab a copy of the binary distribution in the Releases page. For the recommended installation in a production environment, check the Production Setup section below.

Now, suppose you have two clusters running at 10.0.0.1 and 10.0.0.2 with cassandra/cassandra credentials and the same key-value schema. You can start the proxy and connect it to these clusters like this:

$ export ZDM_ORIGIN_CONTACT_POINTS=10.0.0.1 \\ \nexport ZDM_TARGET_CONTACT_POINTS=10.0.0.2 \\\nexport ZDM_ORIGIN_USERNAME=cassandra \\\nexport ZDM_ORIGIN_PASSWORD=cassandra \\\nexport ZDM_TARGET_USERNAME=cassandra \\\nexport ZDM_TARGET_PASSWORD=cassandra \\\n./zdm-proxy-v2.0.0 # run the ZDM proxy executable

If you prefer to use YAML configuration file, an equivalent setup would look like:

$ cat zdm-config.yml\norigin_contact_points: 10.0.0.1\ntarget_contact_points: 10.0.0.2\norigin_username: cassandra\norigin_password: cassandra\ntarget_username: cassandra\ntarget_password: cassandra\n$ ./zdm-proxy-v2.0.0 --config=./zdm-config.yml # run the ZDM proxy executable

At this point, you should be able to connect some client such as CQLSH to the proxy and write data to it and the proxy will take care of forwarding the requests to both clusters concurrently.

$ cqlsh <proxy-ip-address> 14002 # this is the proxy's default listen port

From the CQLSH prompt:

cqlsh> INSERT INTO test.keyvalue (key, value) VALUES (1, 'ABC');\ncqlsh> INSERT INTO test.keyvalue (key, value) VALUES (2, 'DEF');\ncqlsh> SELECT * FROM test.keyvalue;\ncqlsh> UPDATE test.keyvalue SET value='GYEKJF' WHERE key = 1;\ncqlsh> DELETE FROM test.keyvalue WHERE key = 2;

You can confirm that the data is stored in both clusters by querying them directly in other cqlsh sessions.

Note: For the moment, the keyspace must be specified when accessing a table, even after using USE <keyspace>.

If you don't have test clusters readily available to try with, check the alternative method with docker-compose in the Contributor's guide, which will set up all the dependencies, including two test clusters and a proxy instance, in a containerized sandbox environment.

ZDM Proxy supports protocol versions v2, v3, v4, DSE_V1 and DSE_V2.

It technically doesn't support v5, but handles protocol negotiation so that the client application properly downgrades the protocol version to v4 if v5 is requested. This means that any client application using a recent driver that supports protocol version v5 can be migrated using the ZDM Proxy (as long as it does not use v5-specific functionality).

ZDM Proxy requires origin and target clusters to have at least one protocol version in common. It is therefore not feasible to configure Apache Cassandra 2.0 as origin and 3.x / 4.x as target. Below table displays protocol versions supported by various C* versions:

\n\n\n\n\n\n\n\n\n\n\n\n
Apache CassandraProtocol Version
2.0V2
2.1V2, V3
2.2V2, V3, V4
3.xV3, V4
4.xV3, V4, V5

⚠️ Thrift is not supported by ZDM Proxy. If you are using a very old driver or cluster version that only supports Thrift then you need to change your client application to use CQL and potentially upgrade your cluster before starting the migration process.

In practice this means that ZDM Proxy supports the following cluster versions (as Origin and / or Target):

The setup we described above is only for testing in a local environment. It is NOT recommended for a production installation where the minimum number of proxy instances is 3.

For a comprehensive guide with the recommended production setup check the documentation available at Datastax Migration.

There you'll find information about an Ansible-based tool that automates most of the process.

For information on the packaged dependencies of the Zero Downtime Migration (ZDM) Proxy and their licenses, check out our open source report.

For frequently asked questions, please refer to our separate FAQ page.

","id":"b5e34283-1bc1-59b3-890c-c53a44c6cf98","title":"GitHub - datastax/zdm-proxy: An open-source component designed to seamlessly handle the real-time client application activity while a migration is in progress.","origin_url":"https://github.com/datastax/zdm-proxy","url":"https://github.com/datastax/zdm-proxy","wallabag_created_at":"2024-11-01T17:23:20+00:00","published_at":null,"published_by":"['datastax']","reading_time":4,"domain_name":"github.com","preview_picture":"https://opengraph.githubassets.com/2d9ec70e3a53cb00af12aa2c8f6c9f9568324cfe693483d667268c95dc17d22b/datastax/zdm-proxy","tags":["migration","proxy","datastax","cassandra"],"description":"The ZDM Proxy is client-server component written in Go that enables users to migrate with zero downtime from an Apache Cassandra® cluster to another (which may be an Astra cluster) and not requiring c..."},{"content":"

{{ message }}

\n

/ cquill Public

Versioned CQL migrations for Cassandra and ScyllaDB

License

MIT license

1 star 2 forks Activity

Star

Notifications

\n

You can’t perform that action at this time.

\n\n
","id":"224ccef4-d879-51af-856a-02ba457a8730","title":"GitHub - eighty4/cquill: Versioned CQL migrations for Cassandra and ScyllaDB","origin_url":"https://github.com/eighty4/cquill","url":"https://github.com/eighty4/cquill","wallabag_created_at":"2023-12-02T16:52:29+00:00","published_at":null,"published_by":"['eighty4']","reading_time":null,"domain_name":"github.com","preview_picture":"https://opengraph.githubassets.com/00886de67360da230128871de2a210c368c15ce47adec6af8125c20688f7a6d0/eighty4/cquill","tags":["migration","schema","scylladb","cassandra","schema.managements"],"description":"{{ message }}\n / cquill PublicNotifications\nFork 2\n\n Star 1 \n\nVersioned CQL migrations for Cassandra and ScyllaDBLicense MIT license 1 star 2 forks Activity Star Notifications\n You can’t perform tha..."},{"content":"

{{ message }}

\n
\n

You can’t perform that action at this time.

\n\n
","id":"6a67fb02-1f67-546f-9b11-bf0908226c91","title":"GitHub - embulk/embulk: Embulk: Pluggable Bulk Data Loader.","origin_url":"https://github.com/embulk/embulk","url":"https://github.com/embulk/embulk","wallabag_created_at":"2023-12-01T02:40:41+00:00","published_at":null,"published_by":"['embulk']","reading_time":null,"domain_name":"github.com","preview_picture":"https://opengraph.githubassets.com/710726da5afbe5bac1b38fd385c4e7c1e62d1ee9a922a947bbc3f958828f9974/embulk/embulk","tags":["hive","elasticsearch","cassandra","data.processing","elastic","migration","mysql","etl","redis"],"description":"{{ message }}\n / embulk PublicNotifications\nFork 205\n\n Star 1.7k \n\nEmbulk: Pluggable Bulk Data Loader.www.embulk.org/License Apache-2.0 and 4 other licenses found\nLicenses found\n\nApache-2.0LICENSE\n \nA..."},{"content":"

{{ message }}

\n
\n
\n

\n You can’t perform that action at this time.

\n \n
","id":"147c0a49-bc35-52b1-bf83-313db9594f8a","title":"GitHub - datastax/dsbulk-migrator","origin_url":"https://github.com/datastax/dsbulk-migrator","url":"https://github.com/datastax/dsbulk-migrator","wallabag_created_at":"2023-11-29T16:29:48+00:00","published_at":null,"published_by":"['datastax']","reading_time":null,"domain_name":"github.com","preview_picture":"https://opengraph.githubassets.com/70a4f3f9f9136c4594ab14ccf9bebd688f1fcfa48020f7ca19db5d95af4a417b/datastax-archive/dsbulk-migrator","tags":["migration","datastax","astra","cassandra","datastax.astra","dsbulk"],"description":"{{ message }}\n \n /\n \ndsbulk-migrator\n\n Public\n Notifications\n\n\n\n Fork\n 8\n\n\n\n \n Star\n 8\n \n\nLicense\n \n Apache-2.0 license\n \n \n 8\n ..."},{"content":"

Author: Alexander Dejanovski

\"DataStax\"
\"Building
Published in
·
8 min read
·
Feb 23, 2022

--

K8ssandra is a cloud-native distribution of the Apache Cassandra® database that runs on Kubernetes, with a suite of tools to ease and automate operational tasks. In this post, we’ll walk you through a database migration from a Cassandra cluster running in AWS Amazon Elastic Compute Cloud (EC2) to a K8ssandra cluster running in Kubernetes on AWS Elastic Kubernetes Service (EKS), with zero downtime.

As a Cassandra user, your expectation should be that migrating to K8ssandra would happen without downtime. To achieve zero downtime, you can use “classic” clusters running on virtual machines or bare metal instances and the data center (DC) switch technique, commonly used in the Cassandra community, to transfer clusters to different hardware or environments. The good news is that it’s not very different for clusters running in Kubernetes because most Container Network Interfaces (CNI) will provide routable pod IPs.

Routable pod IPs in Kubernetes

A common misconception about Kubernetes networking is that services are the only way to expose pods outside the cluster and that pods themselves are only reachable directly from within the cluster.

Looking at the Calico documentation, we can read the following:

“If the pod IP addresses are routable outside of the cluster then pods can connect to the outside world without Source Network Address Translation (SNAT), and the outside world can connect directly to pods without going via a Kubernetes service or Kubernetes ingress.”

The same documentation tells us that the default CNI used in AWS EKS, Azure AKS, and GCP GKE provide routable pod IPs within a virtual private cloud (VPC).

A VPC is necessary because Cassandra nodes in both data centers will need to communicate without going through services. Each Cassandra node stores the list of all the other nodes in the cluster in the system.peers(_v2) table and communicates with them using the IP addresses stored there. If pod IPs aren’t routable, there’s no (easy) way to create a hybrid Cassandra cluster that would span outside a Kubernetes cluster’s boundaries.

Database migration using Cassandra data center switch

The traditional technique to migrate a cluster to a different set of hardware or environment is to:

  • Locate nodes in the target infrastructure and add a new data center to the cluster
  • Configure keyspaces so that Cassandra replicates data to the new data center
  • Switch traffic to the new data center once it’s up to date
  • Decommission the old infrastructure

While this procedure was brilliantly documented by my co-worker Alain Rodriguez on the TLP blog, there are some subtleties related to running our new data center in Kubernetes, and more precisely, using K8ssandra, which we’ll cover in detail here.

Here are the steps we’ll go through to perform the migration:

  1. Restrict traffic to the existing data center
  2. Expand the Cassandra cluster by adding a new data center in a Kubernetes cluster using K8ssandra
  3. Rebuild the newly created data center
  4. Switch traffic over to the K8ssandra data center
  5. Decommission the original Cassandra data center

Performing the migration

Initial state

Our starting point is a Cassandra 4.0-rc1 cluster running in AWS on EC2 instances:

In the AWS console, we can access the details of a node in the EC2 service and locate its VPC id, which we’ll need later to create a peering connection with the EKS cluster VPC:

Figure 1. Finding the VPC id.

The next step is to create an EKS cluster with the correct settings so that pod IPs will be reachable from the existing EC2 instances.

Creating the EKS cluster

We’ll use the k8ssandra-terraform project to spin up an EKS cluster with three nodes (see the guide on how to install K8ssandra on EKS for help).

After cloning the project locally, we initialize a few env variables to get started:

Then, we go to the env directory and initialize our Terraform files:

We can then update the variables.tf file and adjust it to our needs:

Ensure the private classless inter-domain routing (CIDR) blocks are different from those used in the EC2 cluster VPC otherwise, you may end up with IP addresses conflicts.

Now create the EKS cluster and the three worker nodes:

The operation will take a few minutes to complete and output something similar to this:

Note the connect_cluster command, which will allow us to create the kubeconfig context entry to interact with the cluster using kubectl:

We can now check the list of worker nodes in our Kubernetes cluster:

VPC peering and security groups

Our Terraform scripts will create a specific VPC for the EKS cluster. For our Cassandra nodes to communicate with the K8ssandra nodes, we’ll need to create a peering connection between both VPCs. Follow the documentation provided by AWS on this topic to create the peering connection: VPC Peering Connection.

Once the VPC peering connection is created, and the route tables are updated in both VPCs, update the inbound rules of the security groups for both the EC2 Cassandra nodes and the EKS worker nodes. You’ll want to accept all TCP traffic on ports 7000 and 7001, which Cassandra nodes use to communicate with each other (unless configured otherwise).

Preparing the Cassandra cluster for the expansion

When expanding a Cassandra cluster to another data center, assuming you haven’t created your cluster with the SimpleSnitch (otherwise, you’ll have to switch snitches first), you need to make sure your keyspaces use the NetworkTopologyStrategy (NTS). This replication strategy is the only one that is DC and rack aware. The default SimpleStrategy will not consider DCs and behave as if all nodes were collocated in the same DC and rack.

Figure 2. Original Cassandra cluster.

We’ll use cqlsh on one of the EC2 Cassandra nodes to list the existing keyspaces and update their replication strategy.

Several system keyspaces use the special LocalStrategy and are not replicated across nodes. They contain only node-specific information and cannot be altered in any way.

We’ll alter the following keyspaces to make them use NTS and only put replicas on the existing data center:

  • system_auth (contains user credentials for authentication purposes)
  • system_distributed (contains repair history data and MV build status)
  • system_traces (contains probabilistic tracing data)
  • tlp_stress (user-created keyspace)

Add any other user-created keyspace to the list. Here we only have the tlp_stress keyspace, created by the tlp-stress tool to generate some data for this migration.

We’ll now run the following command on all the above keyspaces using the existing data center name, in our case us-west-2:

You should make sure to pin client traffic to the us-west-2 data center by specifying it as the local data center. You can do this by using the DCAwareRoundRobinPolicy in some older versions of the DataStax drivers or by specifying it as a local data center when creating a new CqlSession object in the 4.x branch of the Java Driver:

You can find more information in the driver’s documentation.

Deploying K8ssandra as a new data center

​​K8ssandra ships with cass-operator, which orchestrates the Cassandra nodes and handles their configuration. Cass-operator exposes an additionalSeeds setting which allows us to add seed nodes that are not managed by the local instance of cass-operator and, by doing so, create a new data center that will expand an existing cluster.

Figure 3. Creating a K8ssandra deployment for the new data center.

We’ll put all our existing Cassandra nodes as additional seeds, and you shouldn’t need more than three nodes in this list, even if your original cluster is larger. The following migration.yaml values file will be used for our K8ssandra Helm chart:

Note that the cluster name must match the value used for the EC2 Cassandra nodes, and the data center should be named differently than the existing one(s). We’ll only install Cassandra in our K8ssandra data center, but you could deploy other components during this phase.

Let’s deploy K8ssandra and have it join the Cassandra cluster:

You can monitor the logs of the Cassandra pods to see if they’re joining appropriately:

Cass-operator will only start one node at a time. So, if you get a message that looks like the following, try checking the logs of another pod:

If VPC peering is done appropriately, the nodes should join the cluster one by one, and after a while, nodetool status should give an output that looks like this:

Rebuilding the new data center

Now that our K8ssandra data center has joined the cluster, we’ll alter the replication strategies to create replicas in the k8s-1 DC for the keyspaces we previously altered:

Figure 4. Replicating data to the new data center by rebuilding.

After altering all required keyspaces, rebuild the newly added nodes by running the following command for each Cassandra pod:

Once all three nodes are rebuilt, the load should be similar on all nodes:

Note that K8ssandra will create a new superuser and that the existing users in the cluster will be retained as well after the migration. You can forcefully recreate the existing superuser credentials in the K8ssandra data center by adding the following block in the “cassandra” section of the Helm values file:

Switching traffic to the new data center

Client traffic can now be directed at the k8s-1 data center, the same way we previously restricted it to us-west-2. If your clients are running from within the Kubernetes cluster, use the Cassandra service exposed by K8ssandra as a contact point for the driver.

If the clients are running outside of the Kubernetes cluster, you’ll need to enable Ingress and configure it appropriately (which is outside the scope of this blog post).

Figure 5. Redirecting client traffic to the new data center.

Decommissioning the old data center and finishing the migration

Once all the client apps/services have been restarted, we can alter our keyspaces to only replicate them on k8s-1:

Figure 6. Decommission the original data center.

Then ssh into each of the Cassandra nodes in us-west-2 and run the following command to decommission them:

They will appear as leaving (UL) while the decommission is running:

The operation should be fairly fast as no streaming will take place since we no longer have keyspaces replicated on us-west-2.

Once all three nodes were decommissioned, we should be left with the k8s-1 data center only:

As a final step, we can now delete the VPC peering connection as it is no longer necessary.

Note that the cluster can run in hybrid mode for as long as necessary. There’s no requirement to delete the us-west-2 data center if it makes sense to keep it alive.

Conclusion

In this post, I’ve illustrated that it’s indeed possible to migrate existing Cassandra clusters to K8ssandra without downtime by leveraging flat networking. This allows Cassandra nodes running in VMs to connect to Cassandra pods running in Kubernetes directly. If you haven’t explored K8ssandra yet, I strongly encourage you to check it out!

Follow the DataStax Tech Blog for more developer stories. Check out our YouTube channel for tutorials and DataStax Developers on Twitter for the latest news about our dev community.

Resources

  1. K8ssandra
  2. Calico — Determining Best Networking Option
  3. Apache Cassandra — Data Center Switch
  4. K8ssandra Terraform
  5. TLP-Stress
  6. Cass Operator
  7. K8ssandra Discord Community
  8. K8ssandra Forum
\"What’s
\"DataStax\"

in

What’s a Vector Database?

By Bill McLane

8 min read·Sep 18

--

\"7
\"DataStax\"

in

7 Reasons to Choose Apache Pulsar over Apache Kafka

By Chris Bartholomew, Streaming Engineering, DataStax

6 min read·May 13, 2021

--

\"A
\"DataStax\"

in

A Vector Primer: Understanding the Basics of Generative AI

By Charna Parkey

4 min read·Oct 19

--

\"Reclaiming
\"DataStax\"

in

Reclaiming Persistent Volumes in Kubernetes

Author: Frank Rosner

8 min read·Sep 29, 2021

--

\"Mastering
\"Extio

Mastering Kubernetes Pod-to-Pod Communication: A Comprehensive Guide

Introduction

6 min read·Jun 16

--

\"MongoDB
\"ScyllaDB\"

MongoDB vs ScyllaDB: Architecture Comparison

benchANT compares MongoDB and ScyllaDB architectures, with a focus on what the differences mean for performance and scalability

11 min read·6 days ago

--

\"Bing
\"Hugo

Pulumi after years of Terraform

Is it worth changing IaC tool?

7 min read·Oct 27

--

\"Installing
\"Sairam

Installing Clickhouse on a kubernetes cluster

Clickhouse is the fastest and most resource efficient open-source database for real-time apps and analytics. Installing clickhouse on a…

3 min read·Jun 6

--

\"Demystifying
\"Yakuphan\"

Demystifying Kubernetes Ingress: ALB vs. Nginx

Introduction: In the dynamic world of Kubernetes, efficiently managing incoming traffic to your services is paramount. Two popular…

4 min read·Aug 12

--

\"Boosting
\"Tommer

Boosting Your Kubernetes Productivity: Essential kubectl Plugins for Efficient Cluster Management

Intro

3 min read·Oct 30

--

","id":"a5bb7282-c872-58a8-8f53-5755c93aeef4","title":"How to Migrate Your Cassandra Database to Kubernetes with Zero Downtime","origin_url":"https://medium.com/building-the-open-data-stack/how-to-migrate-your-cassandra-database-to-kubernetes-with-zero-downtime-f824f5bbf50b","url":"https://medium.com/building-the-open-data-stack/how-to-migrate-your-cassandra-database-to-kubernetes-with-zero-downtime-f824f5bbf50b","wallabag_created_at":"2023-11-15T19:59:15+00:00","published_at":"2022-02-23T14:06:03+00:00","published_by":"['DataStax']","reading_time":10,"domain_name":"medium.com","preview_picture":"https://miro.medium.com/v2/resize:fit:1200/1*5yg7lSEpN9Qvi44eLqGE2w.jpeg","tags":["migration","cassandra","kubernetes"],"description":"Author: Alexander DejanovskiDataStax·FollowPublished inBuilding Real-World, Real-Time AI·8 min read·Feb 23, 2022--K8ssandra is a cloud-native distribution of the Apache Cassandra® database that runs o..."},{"content":"
\n

500kops/s

Transfer 1 terabyte of data in less than 30 minutes

100+

Deployments over 3 continents and counting

150TB

Moved securely, reliably & in real-time every month

And also includes 3 new connectors:

Read more

Explore industriesExplore use cases

Cloud security leader. Arcion consolidates data from MongoDB instances with 250 shards, all at once, in real-time.

Fortune 500 investment bank. Arcion replicates transactional data to a real-time data analytics platform for real-time fraud analytics, consolidates data from 10+ databases to a distributed real-time target.

Global consumer-electronics vendor. Arcion unifies 3 data sources to power real-time analytics to increase sales team productivity, streaming 300 million rows per day.

Top 5 global bank. Arcion migrates 70TB of data from Oracle to MySQL with zero downtime to power one of the most critical applications.

One of three credit reporting agencies. Arcion streams data from Informix to Kafka and processes 200 million events per day, powering real-time fraud detection.

The biggest digital payment provider in China. Uses Arcion to migrate petabyte-scale account data from Oracle to Cassandra across three data centers in different regions.

\"Arcion

Deploy production-ready change data capture pipelines for high-volume, real-time data replication - without a single line of code. 

\n

Learn more about Arcion Cloud

\n
\"Arcion

No code, no hassle, no limit to scale

\n

Supercharged Change Data Capture. Enjoy automatic schema conversion, end-to-end replication, flexible deployment, and more with Arcion’s distributed Change Data Capture (CDC).

Transactional integrity guaranteed. Leverage Arcion’s zero data loss architecture for guaranteed end-to-end data consistency, built-in checkpointing, and more without any custom code.

Limitless scalability. Leave scalability and performance concerns behind with a highly-distributed, highly parallel architecture supporting 10x faster data replication, 

\"\"\"\"
\"\"

Fully managed CDC in the cloud. Reduce DevOps overhead with Arcion Cloud, the only fully-managed CDC offering. Enjoy autoscaling, built-in high availability, monitoring console, and more.

One solution for all OLTP & OLAP systems. Simplify & standardize data pipelines architecture, and zero downtime workload migration from on-prem to cloud.

Lower total cost of ownership. Arcion’s zero-maintenance data pipelines reduce the total cost of ownership through log-based CDC, efficient data compression, and Read Once, Write Multiple technology.

Everything you need for enterprise-grade data replication

See all supported connectors

Financial services

In a competitive landscape where every second counts, Arcion helps financial institutions and companies save weeks and months while maintaining enterprise-grade security and compliance standards.

Read why financial services love ArcionExplore all industries

\"Arcion

Take Arcion for a Spin

Deploy the only cloud-native data replication platform you’ll ever need. Get real-time, high-performance data pipelines today.

\"ArcionGet started for free
\"\"

5 connectors: Oracle, MySQL, Databricks, Snowflake, SingleStore

\"\"

Pre-configured enterprise instance

\"\"

Available in four US AWS regions

\"\"
Free download
\"\"

20+ enterprise source and target connectors

\"\"

Deploy on-prem or VPC

\"\"

Satisfy security requirements

","id":"e62be533-3e2f-51d0-9126-87cda55c371b","title":"Real-time Database Replication Platform | Arcion","origin_url":"https://www.arcion.io/","url":"https://www.arcion.io/","wallabag_created_at":"2022-08-22T16:00:20+00:00","published_at":null,"published_by":null,"reading_time":2,"domain_name":"www.arcion.io","preview_picture":"https://assets.website-files.com/61acd54a60fc632b98cbac1a/6256792469e58455de14d602_OpenGraph.svg","tags":["migration","cassandra","cosmos"],"description":"\n500kops/sTransfer 1 terabyte of data in less than 30 minutes100+Deployments over 3 continents and counting150TBMoved securely, reliably & in real-time every monthAnd also includes 3 new connectors:Re..."}],"skip":0,"limit":8,"totalCount":17,"currentPage":1,"url":"/tags/migration"}},"staticQueryHashes":[]}