{"componentChunkName":"component---src-templates-tags-js","path":"/tags/proxy/1","result":{"pageContext":{"tag":"proxy","urlTag":"proxy","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":"

Where possible, we recommend using Apache Cassandra native replication to migrate data from your existing cluster into Azure Managed Instance for Apache Cassandra by configuring a hybrid cluster. This approach will use Apache Cassandra's gossip protocol to replicate data from your source data-center into your new managed instance datacenter. However, there may be some scenarios where your source database version isn't compatible, or a hybrid cluster setup is otherwise not feasible.

This tutorial describes how to migrate data to Migrate to Azure Managed Instance for Apache Cassandra in an offline fashion using the Cassandra Spark Connector, and Azure Databricks for Apache Spark.

Prerequisites

Provision an Azure Databricks cluster

We recommend selecting Databricks runtime version 7.5, which supports Spark 3.0.

\"Screenshot

Add dependencies

Add the Apache Spark Cassandra Connector library to your cluster to connect to both native and Azure Cosmos DB Cassandra endpoints. In your cluster, select Libraries > Install New > Maven, and then add com.datastax.spark:spark-cassandra-connector-assembly_2.12:3.0.0 in Maven coordinates.

\"Screenshot

Select Install, and then restart the cluster when installation is complete.

Note

Make sure that you restart the Databricks cluster after the Cassandra Connector library has been installed.

Create Scala Notebook for migration

Create a Scala Notebook in Databricks. Replace your source and target Cassandra configurations with the corresponding credentials, and source and target keyspaces and tables. Then run the following code:

import com.datastax.spark.connector._\nimport com.datastax.spark.connector.cql._\nimport org.apache.spark.SparkContext\n// source cassandra configs\nval sourceCassandra = Map( \n    \"spark.cassandra.connection.host\" -> \"<Source Cassandra Host>\",\n    \"spark.cassandra.connection.port\" -> \"9042\",\n    \"spark.cassandra.auth.username\" -> \"<USERNAME>\",\n    \"spark.cassandra.auth.password\" -> \"<PASSWORD>\",\n    \"spark.cassandra.connection.ssl.enabled\" -> \"false\",\n    \"keyspace\" -> \"<KEYSPACE>\",\n    \"table\" -> \"<TABLE>\"\n)\n//target cassandra configs\nval targetCassandra = Map( \n    \"spark.cassandra.connection.host\" -> \"<Source Cassandra Host>\",\n    \"spark.cassandra.connection.port\" -> \"9042\",\n    \"spark.cassandra.auth.username\" -> \"<USERNAME>\",\n    \"spark.cassandra.auth.password\" -> \"<PASSWORD>\",\n    \"spark.cassandra.connection.ssl.enabled\" -> \"true\",\n    \"keyspace\" -> \"<KEYSPACE>\",\n    \"table\" -> \"<TABLE>\",\n    //throughput related settings below - tweak these depending on data volumes. \n    \"spark.cassandra.output.batch.size.rows\"-> \"1\",\n    \"spark.cassandra.output.concurrent.writes\" -> \"1000\",\n    \"spark.cassandra.connection.remoteConnectionsPerExecutor\" -> \"10\",\n    \"spark.cassandra.concurrent.reads\" -> \"512\",\n    \"spark.cassandra.output.batch.grouping.buffer.size\" -> \"1000\",\n    \"spark.cassandra.connection.keep_alive_ms\" -> \"600000000\"\n)\n//Read from source Cassandra\nval DFfromSourceCassandra = sqlContext\n  .read\n  .format(\"org.apache.spark.sql.cassandra\")\n  .options(sourceCassandra)\n  .load\n//Write to target Cassandra\nDFfromSourceCassandra\n  .write\n  .format(\"org.apache.spark.sql.cassandra\")\n  .options(targetCassandra)\n  .mode(SaveMode.Append) // only required for Spark 3.x\n  .save\n

Note

If you have a need to preserve the original writetime of each row, refer to the cassandra migrator sample.

Next steps

Manage Azure Managed Instance for Apache Cassandra resources using Azure CLI

","id":"96345e36-1ce5-5da7-bac0-8e4ca8d24669","title":"Migrate to Azure Managed Instance for Apache Cassandra using Apache Spark","origin_url":"https://docs.microsoft.com/en-us/azure/managed-instance-apache-cassandra/spark-migration","url":"https://docs.microsoft.com/en-us/azure/managed-instance-apache-cassandra/spark-migration","wallabag_created_at":"2022-08-18T16:17:51+00:00","published_at":null,"published_by":"['TheovanKraay']","reading_time":2,"domain_name":"docs.microsoft.com","preview_picture":"https://learn.microsoft.com/en-us/media/open-graph-image.png","tags":["proxy","cassandra","spark","azure"],"description":"Article\n04/01/2022\nWhere possible, we recommend using Apache Cassandra native replication to migrate data from your existing cluster into Azure Managed Instance for Apache Cassandra by configuring a h..."},{"content":"

Where possible, we recommend using the Apache Cassandra native capability to migrate data from your existing cluster into Azure Managed Instance for Apache Cassandra by configuring a hybrid cluster. This capability uses Apache Cassandra's gossip protocol to replicate data from your source datacenter into your new managed-instance datacenter in a seamless way. However, there might be some scenarios where your source database version is not compatible, or a hybrid cluster setup is otherwise not feasible.

This tutorial describes how to migrate data to Azure Managed Instance for Apache Cassandra in a live fashion by using a dual-write proxy and Apache Spark. The dual-write proxy is used to capture live changes, while historical data is copied in bulk using Apache Spark. The benefits of this approach are:

The following image illustrates the approach.

\"Animation

Prerequisites

Provision a Spark cluster

We recommend selecting Azure Databricks runtime version 7.5, which supports Spark 3.0.

\"Screenshot

Add Spark dependencies

You need to add the Apache Spark Cassandra Connector library to your cluster to connect to any wire protocol compatible Apache Cassandra endpoints. In your cluster, select Libraries > Install New > Maven, and then add com.datastax.spark:spark-cassandra-connector-assembly_2.12:3.0.0 in Maven coordinates.

Important

If you have a requirement to preserve Apache Cassandra writetime for each row during the migration, we recommend using this sample. The dependency jar in this sample also contains the Spark connector, so you should install this instead of the connector assembly above. This sample is also useful if you want to perform a row comparison validation between source and target after historic data load is complete. See sections \"run the historical data load\" and \"validate the source and target\" below for more details.

\"Screenshot

Select Install, and then restart the cluster when installation is complete.

Note

Be sure to restart the Azure Databricks cluster after the Cassandra Connector library is installed.

Install the dual-write proxy

For optimal performance during dual writes, we recommend installing the proxy on all nodes in your source Cassandra cluster.

#assuming you do not have git already installed\nsudo apt-get install git \n#assuming you do not have maven already installed\nsudo apt install maven\n#clone repo for dual-write proxy\ngit clone https://github.com/Azure-Samples/cassandra-proxy.git\n#change directory\ncd cassandra-proxy\n#compile the proxy\nmvn package\n

Start the dual-write proxy

We recommend that you install the proxy on all nodes in your source Cassandra cluster. At minimum, run the following command to start the proxy on each node. Replace <target-server> with an IP or server address from one of the nodes in the target cluster. Replace <path to JKS file> with path to a local .jks file, and replace <keystore password> with the corresponding password.

java -jar target/cassandra-proxy-1.0-SNAPSHOT-fat.jar localhost <target-server> --proxy-jks-file <path to JKS file> --proxy-jks-password <keystore password>\n

Starting the proxy in this way assumes that the following are true:

If your source and target endpoints can't meet these criteria, read on for further configuration options.

Configure SSL

For SSL, you can either implement an existing keystore (for example, the one that your source cluster uses) or create a self-signed certificate by using keytool:

keytool -genkey -keyalg RSA -alias selfsigned -keystore keystore.jks -storepass password -validity 360 -keysize 2048\n

You can also disable SSL for source or target endpoints if they don't implement SSL. Use the --disable-source-tls or --disable-target-tls flags:

java -jar target/cassandra-proxy-1.0-SNAPSHOT-fat.jar localhost <target-server> --source-port 9042 --target-port 10350 --proxy-jks-file <path to JKS file> --proxy-jks-password <keystore password> --target-username <username> --target-password <password> --disable-source-tls true  --disable-target-tls true \n

Note

Make sure your client application uses the same keystore and password as the ones used for the dual-write proxy when you're building SSL connections to the database via the proxy.

Configure the credentials and port

By default, the source credentials will be passed through from your client app. The proxy will use the credentials for making connections to the source and target clusters. As mentioned earlier, this process assumes that the source and target credentials are the same. If necessary, you can specify a different username and password for the target Cassandra endpoint separately when starting the proxy:

java -jar target/cassandra-proxy-1.0-SNAPSHOT-fat.jar localhost <target-server> --proxy-jks-file <path to JKS file> --proxy-jks-password <keystore password> --target-username <username> --target-password <password>\n

The default source and target ports, when not specified, will be 9042. If either the target or the source Cassandra endpoint runs on a different port, you can use --source-port or --target-port to specify a different port number:

java -jar target/cassandra-proxy-1.0-SNAPSHOT-fat.jar localhost <target-server> --source-port 9042 --target-port 10350 --proxy-jks-file <path to JKS file> --proxy-jks-password <keystore password> --target-username <username> --target-password <password>\n

Deploy the proxy remotely

There might be circumstances in which you don't want to install the proxy on the cluster nodes themselves, and you prefer to install it on a separate machine. In that scenario, you need to specify the IP address of <source-server>:

java -jar target/cassandra-proxy-1.0-SNAPSHOT-fat.jar <source-server> <destination-server>\n

Warning

Installing and running the proxy remotely on a separate machine (rather than running it on all nodes in your source Apache Cassandra cluster) will impact performance while the live migration occurs. While it will work functionally, the client driver won't be able to open connections to all nodes within the cluster, and will rely on the single co-ordinator node (where the proxy is installed) to make connections.

Allow zero application code changes

By default, the proxy listens on port 29042. The application code must be changed to point to this port. However, you can change the port that the proxy listens on. You might do this if you want to eliminate application-level code changes by:

java -jar target/cassandra-proxy-1.0-SNAPSHOT-fat.jar source-server destination-server --proxy-port 9042\n

Note

Installing the proxy on cluster nodes does not require restart of the nodes. However, if you have many application clients and prefer to have the proxy running on the standard Cassandra port 9042 in order to eliminate any application-level code changes, you need to change the Apache Cassandra default port. You then need to restart the nodes in your cluster, and configure the source port to be the new port that you defined for your source Cassandra cluster.

In the following example, we change the source Cassandra cluster to run on port 3074, and we start the cluster on port 9042:

java -jar target/cassandra-proxy-1.0-SNAPSHOT-fat.jar source-server destination-server --proxy-port 9042 --source-port 3074\n

Force protocols

The proxy has functionality to force protocols, which might be necessary if the source endpoint is more advanced than the target or is otherwise unsupported. In that case, you can specify --protocol-version and --cql-version to force the protocol to comply with the target:

java -jar target/cassandra-proxy-1.0-SNAPSHOT-fat.jar source-server destination-server --protocol-version 4 --cql-version 3.11\n

After the dual-write proxy is running, you'll need to change the port on your application client and restart. (Or change the Cassandra port and restart the cluster if you've chosen that approach.) The proxy will then start forwarding writes to the target endpoint. You can learn about monitoring and metrics available in the proxy tool.

Run the historical data load

To load the data, create a Scala notebook in your Azure Databricks account. Replace your source and target Cassandra configurations with the corresponding credentials, and replace the source and target keyspaces and tables. Add more variables for each table as required to the following sample, and then run. After your application starts sending requests to the dual-write proxy, you're ready to migrate historical data.

import com.datastax.spark.connector._\nimport com.datastax.spark.connector.cql._\nimport org.apache.spark.SparkContext\n// source cassandra configs\nval sourceCassandra = Map( \n    \"spark.cassandra.connection.host\" -> \"<Source Cassandra Host>\",\n    \"spark.cassandra.connection.port\" -> \"9042\",\n    \"spark.cassandra.auth.username\" -> \"<USERNAME>\",\n    \"spark.cassandra.auth.password\" -> \"<PASSWORD>\",\n    \"spark.cassandra.connection.ssl.enabled\" -> \"true\",\n    \"keyspace\" -> \"<KEYSPACE>\",\n    \"table\" -> \"<TABLE>\"\n)\n//target cassandra configs\nval targetCassandra = Map( \n    \"spark.cassandra.connection.host\" -> \"<Source Cassandra Host>\",\n    \"spark.cassandra.connection.port\" -> \"9042\",\n    \"spark.cassandra.auth.username\" -> \"<USERNAME>\",\n    \"spark.cassandra.auth.password\" -> \"<PASSWORD>\",\n    \"spark.cassandra.connection.ssl.enabled\" -> \"true\",\n    \"keyspace\" -> \"<KEYSPACE>\",\n    \"table\" -> \"<TABLE>\",\n    //throughput related settings below - tweak these depending on data volumes. \n    \"spark.cassandra.output.batch.size.rows\"-> \"1\",\n    \"spark.cassandra.output.concurrent.writes\" -> \"1000\",\n    \"spark.cassandra.connection.remoteConnectionsPerExecutor\" -> \"1\",\n    \"spark.cassandra.concurrent.reads\" -> \"512\",\n    \"spark.cassandra.output.batch.grouping.buffer.size\" -> \"1000\",\n    \"spark.cassandra.connection.keep_alive_ms\" -> \"600000000\"\n)\n//set timestamp to ensure it is before read job starts\nval timestamp: Long = System.currentTimeMillis / 1000\n//Read from source Cassandra\nval DFfromSourceCassandra = sqlContext\n  .read\n  .format(\"org.apache.spark.sql.cassandra\")\n  .options(sourceCassandra)\n  .load\n//Write to target Cassandra\nDFfromSourceCassandra\n  .write\n  .format(\"org.apache.spark.sql.cassandra\")\n  .options(targetCassandra)\n  .option(\"writetime\", timestamp)\n  .mode(SaveMode.Append)\n  .save\n

Note

In the preceding Scala sample, you'll notice that timestamp is being set to the current time before reading all the data in the source table. Then, writetime is being set to this backdated time stamp. This ensures that records that are written from the historical data load to the target endpoint can't overwrite updates that come in with a later time stamp from the dual-write proxy while historical data is being read.

Important

If you need to preserve exact time stamps for any reason, you should take a historical data migration approach that preserves time stamps, such as this sample. The dependency jar in the sample also contains the Spark connector, so you do not need to install the Spark connector assembly mentioned in the earlier pre-requisites - having both installed in your Spark cluster will cause conflicts.

After the historical data load is complete, your databases should be in sync and ready for cutover. However, we recommend that you validate the source and target to ensure they match before finally cutting over.

Note

If you used the cassandra migrator sample mentioned above for preserving writetime, this includes the capability to validate the migration by comparing rows in source and target based on certain tolerances.

Next steps

Manage Azure Managed Instance for Apache Cassandra resources using Azure CLI

","id":"cc83865b-46de-5403-85e5-07e1672af9b1","title":"Live migration to Azure Managed Instance for Apache Cassandra using Apache Spark and a dual-write proxy","origin_url":"https://docs.microsoft.com/en-us/azure/managed-instance-apache-cassandra/dual-write-proxy-migration","url":"https://docs.microsoft.com/en-us/azure/managed-instance-apache-cassandra/dual-write-proxy-migration","wallabag_created_at":"2022-08-18T16:16:36+00:00","published_at":null,"published_by":"['TheovanKraay']","reading_time":10,"domain_name":"docs.microsoft.com","preview_picture":"https://learn.microsoft.com/en-us/media/open-graph-image.png","tags":["proxy","managed.services","cassandra","azure","cql"],"description":"Article\n11/29/2021\nWhere possible, we recommend using the Apache Cassandra native capability to migrate data from your existing cluster into Azure Managed Instance for Apache Cassandra by configuring ..."},{"content":"

\"GitHub \"Go

Table of Contents

What is cql-proxy?

\"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.

When to use cql-proxy

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.

Configuration

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  -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.

Using flags

docker run -p 9042:9042 \\\n  --rm datastax/cql-proxy:v0.1.3 \\\n  --astra-token <astra-token> --astra-database-id <astra-datbase-id>

Using environment variables

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

Using a configuration file

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.

Setting up peer proxies

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.

Multi-region setup

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.

Getting started

There are three methods for using cql-proxy:

Locally build and run

  1. \n

    Build cql-proxy.

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

    Run with your desired database.

    \n
    3. \n

Run a cql-proxy docker image

  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.3.

Use Kubernetes

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

Known issues

Token-aware load balancing

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":"f9307803-a14a-5395-be5c-7025a773a5fb","title":"cql-proxy/README.md at main · datastax/cql-proxy","origin_url":"https://github.com/datastax/cql-proxy/blob/main/README.md","url":"https://github.com/datastax/cql-proxy/blob/main/README.md","wallabag_created_at":"2022-07-13T21:05:55+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":["proxy","datastax","cassandra","cql"],"description":" Table of ContentsWhat is 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..."},{"content":"

{{ message }}

\n

/ cassandra-proxy Public

A dual write proxy for Apache Cassandra

License

Apache-2.0 license

11 stars 8 forks

Star

Notifications

\n
\n

You can’t perform that action at this time.

\n

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.

\n
\n\n
","id":"9eb68c23-743f-5366-9a75-2acb856b1a3f","title":"GitHub - Azure-Samples/cassandra-proxy: A dual write proxy for Apache Cassandra","origin_url":"https://github.com/Azure-Samples/cassandra-proxy","url":"https://github.com/Azure-Samples/cassandra-proxy","wallabag_created_at":"2022-06-08T20:35:28+00:00","published_at":null,"published_by":"['Azure-Samples']","reading_time":null,"domain_name":"github.com","preview_picture":"https://opengraph.githubassets.com/214e45c665bb2a7c7489426e39be89b9e891dc7ddb34f43ecd65485a696c07c5/Azure-Samples/cassandra-proxy","tags":["cassandra","proxy"],"description":"{{ message }}\n / cassandra-proxy PublicNotifications\nFork 8\n\n Star 11 \n\nA dual write proxy for Apache CassandraLicense Apache-2.0 license 11 stars 8 forks Star Notifications\n\n © 2022 GitHub, Inc.\n\n Y..."},{"content":"

{{ message }}

\n
\n
\n \n \n
\n \n
","id":"997b956d-1233-59ff-9a8a-9f6bf36b53f1","title":"CQL Proxy · datastaxdevs/awesome-astra Wiki","origin_url":"https://github.com/datastaxdevs/awesome-astra/wiki/CQL-Proxy","url":"https://github.com/datastaxdevs/awesome-astra/wiki/CQL-Proxy","wallabag_created_at":"2022-02-17T22:02:08+00:00","published_at":null,"published_by":"['datastaxdevs']","reading_time":null,"domain_name":"github.com","preview_picture":"https://opengraph.githubassets.com/32e78986b1811ed5058d6111a251c4d10ef3e9fa3a3f0c7e605247236f485c57/datastax-archive/awesome-astra","tags":["proxy","astra","cassandra","cql"],"description":"{{ message }}\n\n Notifications\n\n\n\n Fork\n 2\n\n\n\n \n Star\n 2\n\n\n\n\n\n\n\n \n © 2022 GitHub, Inc.\n \n \n\nYou can’t perform that action at this time.\n\n"}],"skip":0,"limit":8,"totalCount":9,"currentPage":1,"url":"/tags/proxy"}},"staticQueryHashes":[]}