Migration von Cassandra zu Bigtable mit einem Dual-Write-Proxy

Migration von Cassandra zu Bigtable mit einem Dual-Write-Proxy

Informationen zu diesem Codelab

subjectZuletzt aktualisiert: Apr. 15, 2025
account_circleVerfasst von Louis Cheynel

1. Einführung

Bigtable ist ein vollständig verwalteter, leistungsstarker NoSQL-Datenbankdienst für große analytische und operative Arbeitslasten. Die Migration von vorhandenen Datenbanken wie Apache Cassandra zu Bigtable erfordert oft eine sorgfältige Planung, um Ausfallzeiten und Auswirkungen auf die Anwendung zu minimieren.

In diesem Codelab wird eine Migrationsstrategie von Cassandra zu Bigtable mit einer Kombination aus Proxy-Tools veranschaulicht:

  1. Cassandra-Bigtable-Proxy: Ermöglicht es Cassandra-Clients und ‑Tools (z. B. cqlsh oder Treibern), mit Bigtable über das CQL-Protokoll (Cassandra Query Language) zu interagieren, indem Abfragen übersetzt werden.
  2. Datastax Zero Downtime Migration (ZDM) Proxy: Ein Open-Source-Proxy, der zwischen Ihrer Anwendung und Ihren Datenbankdiensten liegt (Ursprung Cassandra und Ziel Bigtable über den Cassandra-Bigtable-Proxy). Es orchestriert doppelte Schreibvorgänge und verwaltet das Traffic-Routing, sodass die Migration mit minimalen Anwendungsänderungen und Ausfallzeiten möglich ist.
  3. Cassandra Data Migrator (CDM): Ein Open-Source-Tool, mit dem Verlaufsdaten im Bulk-Verfahren aus dem Quell-Cassandra-Cluster in die Bigtable-Ziel-Instanz migriert werden.

Lerninhalte

  • Informationen zum Einrichten eines einfachen Cassandra-Clusters in der Compute Engine
  • Bigtable-Instanz erstellen
  • Informationen zum Bereitstellen und Konfigurieren des Cassandra-Bigtable-Proxys, um ein Cassandra-Schema zu Bigtable zuzuordnen.
  • Informationen zum Bereitstellen und Konfigurieren des Datastax ZDM-Proxys für doppelte Schreibvorgänge.
  • So migrieren Sie vorhandene Daten per Bulk-Migration mit dem Cassandra Data Migrator-Tool.
  • Der Gesamtablauf für eine proxybasierte Migration von Cassandra zu Bigtable.

Voraussetzungen

  • Google Cloud-Projekt mit aktivierter Abrechnungsfunktion. Neuen Nutzern steht ein kostenloser Testzeitraum zur Verfügung.
  • Grundkenntnisse in Google Cloud-Konzepten wie Projekten, Compute Engine, VPC-Netzwerken und Firewallregeln Grundkenntnisse zu Linux-Befehlszeilentools
  • Zugriff auf einen Computer mit installierter und konfigurierter gcloud-Befehlszeile oder Google Cloud Shell verwenden

In diesem Codelab verwenden wir hauptsächlich virtuelle Maschinen (VMs) in der Compute Engine innerhalb desselben VPC-Netzwerks und derselben Region, um die Netzwerkkonfiguration zu vereinfachen. Wir empfehlen die Verwendung interner IP-Adressen.

2. Umgebung einrichten

1. Google Cloud-Projekt auswählen oder erstellen

Rufen Sie die Google Cloud Console auf und wählen Sie ein vorhandenes Projekt aus oder erstellen Sie ein neues. Notieren Sie sich die Projekt-ID.

2. Erforderliche APIs aktivieren

Die Compute Engine API und die Bigtable API müssen für Ihr Projekt aktiviert sein.

gcloud services enable compute.googleapis.com bigtable.googleapis.com bigtableadmin.googleapis.com --project=<your-project-id>

Ersetzen Sie durch Ihre tatsächliche Projekt-ID.

3. Region und Zone auswählen

Wählen Sie eine Region und eine Zone für Ihre Ressourcen aus. Wir verwenden als Beispiele us-central1 und us-central1-c. Legen Sie diese der Einfachheit halber als Umgebungsvariablen fest:

export PROJECT_ID="<your-project-id>"
export REGION="us-central1"
export ZONE="us-central1-c"

gcloud config set project $PROJECT_ID
gcloud config set compute/region $REGION
gcloud config set compute/zone $ZONE

4. Firewallregeln konfigurieren

Wir müssen die Kommunikation zwischen unseren VMs innerhalb des Standard-VPC-Netzwerks über mehrere Ports zulassen:

  • CQL-Port für Cassandra/Proxys: 9042
  • Port für die ZDM-Proxy-Systemdiagnose: 14001
  • SSH: 22

Erstellen Sie eine Firewallregel, um internen Traffic auf diesen Ports zuzulassen. Wir verwenden ein Tag cassandra-migration, um diese Regel ganz einfach auf die entsprechenden VMs anzuwenden.

gcloud compute firewall-rules create allow-migration-internal \
--network=default \
--action=ALLOW \
--rules=tcp:22,tcp:9042,tcp:14001 \
--source-ranges=10.128.0.0/9 # Adjust if using a custom VPC/IP range \
--target-tags=cassandra-migration

3. Cassandra-Cluster bereitstellen (Ursprung)

In diesem Codelab richten wir einen einfachen Cassandra-Cluster mit einem einzelnen Knoten in der Compute Engine ein. In der Praxis würden Sie eine Verbindung zu Ihrem vorhandenen Cluster herstellen.

1. GCE-VM für Cassandra erstellen

gcloud compute instances create cassandra-origin \
--machine-type=e2-medium \
--image-family=ubuntu-2004-lts \
--image-project=ubuntu-os-cloud \
--tags=cassandra-migration \
--boot-disk-size=20GB

2. Cassandra installieren

# Install Java (Cassandra dependency)
sudo apt-get update
sudo apt-get install -y openjdk-11-jre-headless

# Add Cassandra repository
echo "deb [https://debian.cassandra.apache.org](https://debian.cassandra.apache.org) 41x main" | sudo tee -a /etc/apt/sources.list.d/cassandra.sources.list
curl [https://downloads.apache.org/cassandra/KEYS](https://downloads.apache.org/cassandra/KEYS) | sudo apt-key add -

# Install Cassandra
sudo apt-get update
sudo apt-get install -y cassandra

3. Schlüsselbereich und Tabelle erstellen

Wir verwenden eine Mitarbeitertabelle als Beispiel und erstellen einen Schlüsselbereich namens „zdmbigtable“.

cd ~/apache-cassandra
bin/cqlsh <your-localhost-ip? 9042  #starts the cql shell

In cqlsh:

-- Create keyspace (adjust replication for production)
CREATE KEYSPACE zdmbigtable WITH replication = {'class':'SimpleStrategy', 'replication_factor':1};

-- Use the keyspace
USE zdmbigtable;

-- Create the employee table
CREATE TABLE employee (
    name text PRIMARY KEY,
    age bigint,
    code int,
    credited double,
    balance float,
    is_active boolean,
    birth_date timestamp
);

-- Exit cqlsh
EXIT;

Lassen Sie die SSH-Sitzung geöffnet oder notieren Sie sich die IP-Adresse dieser VM (hostname -I).

4. Bigtable (Ziel) einrichten

Dauer: 0:01

Bigtable-Instanz erstellen. Wir verwenden „zdmbigtable“ als Instanz-ID.

gcloud bigtable instances create zdmbigtable \ 
--display-name="ZDM Bigtable Target" \ 
--cluster=bigtable-c1 \ 
--cluster-zone=$ZONE \ 
--cluster-num-nodes=1 # Use 1 node for dev/testing; scale as needed

Die Bigtable-Tabelle selbst wird später vom Cassandra-Bigtable-Proxy-Einrichtungsskript erstellt.

5. Cassandra-Bigtable-Proxy einrichten

1. Compute Engine-VM für Cassandra-Bigtable-Proxy erstellen

gcloud compute instances create bigtable-proxy-vm \ 
--machine-type=e2-medium \
--image-family=ubuntu-2004-lts \
--image-project=ubuntu-os-cloud \
--tags=cassandra-migration \
--boot-disk-size=20GB

Stellen Sie eine SSH-Verbindung zur bigtable-proxy-vm her:

gcloud compute ssh bigtable-proxy-vm

In der VM:

# Install Git and Go
sudo apt-get update
sudo apt-get install -y git golang-go

# Clone the proxy repository
# Replace with the actual repository URL if different
git clone https://github.com/GoogleCloudPlatform/cloud-bigtable-ecosystem.git
cd cassandra-to-bigtable-proxy/

# Set Go environment variables
export GOPATH=$HOME/go
export PATH=$PATH:/usr/local/go/bin:$GOPATH/bin

2. Proxy konfigurieren

nano config.yaml

Aktualisieren Sie die folgenden Variablen. Eine erweiterte Konfiguration finden Sie in diesem Beispiel auf GitHub.

#!/bin/bash
cassandraToBigtableConfigs:
  # Global default GCP Project ID
  projectId: <your-project-id>

listeners:
- name: cluster1
  port: 9042
  bigtable:
    #If you want to use multiple instances then pass the instance names by comma seperated
    #Instance name should not contain any special characters except underscore(_)
    instanceIds: zdmbigtable

    # Number of grpc channels to be used for Bigtable session.
    Session:
      grpcChannels: 4

otel:
  # Set enabled to true or false for OTEL metrics/traces/logs.
  enabled: False

  # Name of the collector service to be setup as a sidecar
  serviceName: cassandra-to-bigtable-otel-service

  healthcheck:
    # Enable the health check in this proxy application config only if the
    # "health_check" extension is added to the OTEL collector service configuration.
    #
    # Recommendation:
    # Enable the OTEL health check if you need to verify the collector's availability
    # at the start of the application. For development or testing environments, it can
    # be safely disabled to reduce complexity.

    # Enable/Disable Health Check for OTEL, Default 'False'.
    enabled: False
    # Health check endpoint for the OTEL collector service
    endpoint: localhost:13133
  metrics:
    # Collector service endpoint
    endpoint: localhost:4317

  traces:
    # Collector service endpoint
    endpoint: localhost:4317
    #Sampling ratio should be between 0 and 1. Here 0.05 means 5/100 Sampling ratio.
    samplingRatio: 1

loggerConfig:
  # Specifies the type of output, here it is set to 'file' indicating logs will be written to a file.
  # Value of `outputType` should be `file` for file type or `stdout` for standard output.
  # Default value is `stdout`.
  outputType: stdout
  # Set this only if the outputType is set to `file`.
  # The path and name of the log file where logs will be stored. For example, output.log, Required Key.
  # Default `/var/log/cassandra-to-spanner-proxy/output.log`.
  fileName: output/output.log
  # Set this only if the outputType is set to `file`.
  # The maximum size of the log file in megabytes before it is rotated. For example, 500 for 500 MB.
  maxSize: 10
  # Set this only if the outputType is set to `file`.
  # The maximum number of backup log files to keep. Once this limit is reached, the oldest log file will be deleted.
  maxBackups: 2
  # Set this only if the outputType is set to `file`.
  # The maximum age in days for a log file to be retained. Logs older than this will be deleted. Required Key.
  # Default 3 days
  maxAge: 1

  # Set this only if the outputType is set to `file`.
  # Default value is set to 'False'. Change the value to 'True', if log files are required to be compressed.
  compress: True

Speichern und schließen Sie die Datei (in nano: Strg + X, dann Y und dann die Eingabetaste).

3. Cassandra-Bigtable-Proxy starten

Starten Sie den Proxyserver.

# At the root of the cassandra-to-bigtable-proxy directory
go run proxy.go

Der Proxy wird gestartet und wartet auf eingehende CQL-Verbindungen an Port 9042. Lassen Sie diese Terminalsitzung geöffnet. Notieren Sie sich die IP-Adresse dieser VM (hostname -I).

4. Tabelle über CQL erstellen

Stellen Sie eine Verbindung zwischen cqlsh und der IP-Adresse der Cassandra-Bigtable-Proxy-VM her.

Führen Sie in cqlsh den folgenden Befehl aus:

-- Create the employee table
CREATE TABLE zdmbigtable.employee (
    name text PRIMARY KEY,
    age bigint,
    code int,
    credited double,
    balance float,
    is_active boolean,
    birth_date timestamp
);

Prüfen Sie in der Google Cloud Console, ob die Mitarbeitertabelle und die Metadatentabelle in Ihrer Bigtable-Instanz vorhanden sind.

6. ZDM-Proxy einrichten

Für den ZDM-Proxy sind mindestens zwei Maschinen erforderlich: ein oder mehrere Proxyknoten, die den Traffic verarbeiten, und ein Jumphost, der für die Bereitstellung und Orchestration über Ansible verwendet wird.

1. Compute Engine-VMs für den ZDM-Proxy erstellen

Wir benötigen zwei VMs: zdm-proxy-jumphost und zdm-proxy-node-1.

# Jumphost VM 
gcloud compute instances create zdm-jumphost \
--machine-type=e2-medium \
--image-family=ubuntu-2004-lts \
--image-project=ubuntu-os-cloud \
--tags=cassandra-migration \
--boot-disk-size=20GB

# Proxy Node VM 
gcloud compute instances create zdm-proxy-node-1 \
--machine-type=e2-standard-8 \
--image-family=ubuntu-2004-lts \
--image-project=ubuntu-os-cloud \
--tags=cassandra-migration \
--boot-disk-size=20GB

Notieren Sie sich die IP-Adressen beider VMs.

2. Jumphost vorbereiten

SSH-Verbindung zum zdm-Jumphost herstellen

gcloud compute ssh zdm-jumphost

# Install Git and Ansible

sudo apt-get update
sudo apt-get install -y git ansible

Im Jumphost

git clone https:\/\/github.com/datastax/zdm-proxy-automation.git 

cd zdm-proxy-automation/ansible/

Bearbeiten Sie die Hauptkonfigurationsdatei „vars/zdm_proxy_cluster_config.yml“:

Aktualisieren Sie die „origin_contact_points“ und „target_contact_points“ mit den internen IP-Adressen Ihrer Cassandra-VM bzw. Ihrer Cassandra-Bigtable-Proxy-VM. Lassen Sie die Authentifizierung auskommentiert, da wir sie nicht eingerichtet haben.

##############################
#### ORIGIN CONFIGURATION ####
##############################
## Origin credentials (leave commented if no auth)
# origin_username: ...
# origin_password: ...

## Set the following two parameters only if Origin is a self-managed, non-Astra cluster
origin_contact_points: <Your-Cassandra-VM-Internal-IP> # Replace!
origin_port: 9042

##############################
#### TARGET CONFIGURATION ####
##############################
## Target credentials (leave commented if no auth)
# target_username: ...
# target_password: ...

## Set the following two parameters only if Target is a self-managed, non-Astra cluster
target_contact_points: <Your-Bigtable-Proxy-VM-Internal-IP> # Replace!
target_port: 9042

# --- Other ZDM Proxy settings can be configured below ---
# ... (keep defaults for this codelab)

Speichern und schließen Sie diese Datei.

3. ZDM-Proxy mit Ansible bereitstellen

Führen Sie das Ansible-Playbook aus dem Verzeichnis „ansible“ auf dem Jumphost aus:

ansible-playbook deploy_zdm_proxy.yml -i zdm_ansible_inventory

Mit diesem Befehl wird die erforderliche Software (z. B. Docker) auf dem Proxyknoten (zdm-proxy-node-1) installiert, das ZDM-Proxy-Docker-Image abgerufen und der Proxycontainer mit der von Ihnen angegebenen Konfiguration gestartet.

4. ZDM-Proxy-Status prüfen

Prüfen Sie den Bereitschaftsendpunkt des ZDM-Proxys, der auf zdm-proxy-node-1 (Port 14001) ausgeführt wird, vom Jumphost aus:

# Replace <zdm-proxy-node-1-internal-ip> with the actual internal IP.
curl -G http://<zdm-proxy-node-1-internal-ip>:14001/health/readiness

Die Ausgabe sollte in etwa so aussehen und darauf hinweisen, dass sowohl der Ursprung (Cassandra) als auch das Ziel (Cassandra-Bigtable-Proxy) AKTIV sind:

{
  "OriginStatus": {
    "Addr": "<Your-Cassandra-VM-Internal-IP>:9042",
    "CurrentFailureCount": 0,
    "FailureCountThreshold": 1,
    "Status": "UP"
  },
  "TargetStatus": {
    "Addr": "<Your-Bigtable-Proxy-VM-Internal-IP>:9042",
    "CurrentFailureCount": 0,
    "FailureCountThreshold": 1,
    "Status": "UP"
  },
  "Status": "UP"
}

7. Anwendung konfigurieren und doppelte Schreibvorgänge starten

Dauer: 0:05

In dieser Phase einer echten Migration würden Sie Ihre Anwendungen so neu konfigurieren, dass sie auf die IP-Adresse des ZDM-Proxy-Knotens verweisen (z.B. :9042) statt eine direkte Verbindung zu Cassandra herzustellen.

Sobald die Anwendung eine Verbindung zum ZDM-Proxy herstellt: Lesevorgänge werden standardmäßig vom Ursprung (Cassandra) ausgeliefert. Schreibvorgänge werden sowohl an den Ursprung (Cassandra) als auch an das Ziel (Bigtable über den Cassandra-Bigtable-Proxy) gesendet. So kann Ihre Anwendung weiterhin normal funktionieren und gleichzeitig werden neue Daten gleichzeitig in beide Datenbanken geschrieben. Sie können die Verbindung mit cqlsh testen, das vom Jumphost oder einer anderen VM im Netzwerk auf den ZDM-Proxy zeigt:

Cqlsh <zdm-proxy-node-1-ip-address> 9042

Versuchen Sie, einige Daten einzufügen:

INSERT INTO zdmbigtable.employee (name, age, is_active) VALUES ('Alice', 30, true); 
SELECT * FROM employee WHERE name = 'Alice';

Diese Daten sollten sowohl in Cassandra als auch in Bigtable geschrieben werden. Sie können dies in Bigtable prüfen, indem Sie in der Google Cloud Console den Bigtable-Abfrageeditor für Ihre Instanz öffnen. Führen Sie die Abfrage „SELECT * FROM employee“ aus. Die kürzlich eingefügten Daten sollten sichtbar sein.

8. Verlaufsdaten mit dem Cassandra Data Migrator migrieren

Da jetzt doppelte Schreibvorgänge für neue Daten aktiv sind, können Sie mit dem Cassandra Data Migrator (CDM)-Tool die vorhandenen Verlaufsdaten aus Cassandra in Bigtable kopieren.

1. Compute Engine-VM für CDM erstellen

Diese VM benötigt ausreichend Arbeitsspeicher für Spark.

gcloud compute instances create cdm-migrator-vm \
--machine-type=e2-medium \
--image-family=ubuntu-2004-lts \
--image-project=ubuntu-os-cloud \
--tags=cassandra-migration \
--boot-disk-size=40GB

2. Vorabinstallationen (Java 11, Spark)

Stellen Sie eine SSH-Verbindung zur VM „cdm-migrator“ her:

gcloud compute ssh cdm-migrator-vm

In der VM:

# Install Java 11 
sudo apt-get update 
sudo apt-get install -y openjdk-11-jdk
 
# Verify Java installation 
java -version 

# Download and Extract Spark (Using version 3.5.3 as requested) 
# Check the Apache Spark archives for the correct URL if needed

wget  [https://archive.apache.org/dist/spark/spark-3.5.3/spark-3.5.3-bin-hadoop3-scala2.13.tgz](https://archive.apache.org/dist/spark/spark-3.5.3/spark-3.5.3-bin-hadoop3-scala2.13.tgz) tar -xvzf spark-3.5.3-bin-hadoop3-scala2.13.tgz
 
export SPARK_HOME=$PWD/spark-3.5.3-bin-hadoop3-scala2.13 
export PATH=$PATH:$SPARK_HOME/bin

3. Cassandra Data Migrator herunterladen

Laden Sie die JAR-Datei des CDM-Tools herunter. Suchen Sie auf der GitHub-Release-Seite des Cassandra Data Migrator nach der richtigen URL der gewünschten Version.

# Example using version 5.2.2 - replace URL if needed
wget https://github.com/datastax/cassandra-data-migrator/releases/download/v5.2.2/cassandra-data-migrator-5.2.2.jar)

4. CDM konfigurieren

Erstellen Sie eine Properties-Datei mit dem Namen „cdm.properties“.

Nano cdm.properties

Fügen Sie die folgende Konfiguration ein, ersetzen Sie die IP-Adressen und deaktivieren Sie die TTL-/Schreibzeitfunktionen, da sie von Bigtable nicht direkt unterstützt werden. Lassen Sie „auth“ auskommentiert.

# Origin Cassandra Connection 
spark.cdm.connect.origin.host <Your-Cassandra-VM-IP-Address> # Replace!
spark.cdm.connect.origin.port 9042
spark.cdm.connect.origin.username cassandra # Leave default, or set if auth is enabled # 
spark.cdm.connect.origin.password cassandra # Leave default, or set if auth is enabled #

# Target Bigtable (via Cassandra-Bigtable Proxy)
Connection spark.cdm.connect.target.host <Your-Bigtable-Proxy-VM-IP-Address> # Replace! 
spark.cdm.connect.target.port 9042
spark.cdm.connect.target.username cassandra # Leave default, or set if auth is enabled #
spark.cdm.connect.target.password cassandra # Leave default, or set if auth is enabled #

# Disable TTL/Writetime features (Important for Bigtable compatibility via Proxy)
spark.cdm.feature.origin.ttl.automatic false 
spark.cdm.feature.origin.writetime.automatic false 
spark.cdm.feature.target.ttl.automatic false 
spark.cdm.feature.target.writetime.automatic false

Speichern und schließen Sie die Datei.

5. Migrationsjob ausführen

Führen Sie die Migration mit spark-submit aus. Mit diesem Befehl wird Spark angewiesen, das CDM-JAR-File mithilfe Ihrer Properties-Datei auszuführen und den zu migrierenden Schlüsselbereich und die zu migrierende Tabelle anzugeben. Passen Sie die Arbeitsspeichereinstellungen (–driver-memory, –executor-memory) an die Größe der VM und das Datenvolumen an.

Sie müssen sich in dem Verzeichnis befinden, das die CDM-JAR-Datei und die Properties-Datei enthält. Ersetzen Sie „cassandra-data-migrator-5.2.2.jar“, wenn Sie eine andere Version heruntergeladen haben.

./spark-3.5.3-bin-hadoop3-scala2.13/bin/spark-submit \ --properties-file cdm.properties \ --master "local[*]" \ --driver-memory 4G \ --executor-memory 4G \ --class com.datastax.cdm.job.Migrate \ cassandra-data-migrator-5.2.2.jar &> cdm_migration_$(date +%Y%m%d_%H%M).log

Die Migration wird im Hintergrund ausgeführt und Protokolle werden in cdm_migration_... geschrieben. .log. Überwachen Sie die Protokolldatei auf Fortschritt und Fehler:

tail -f cdm_migration_*.log

6. Datenmigration prüfen

Prüfen Sie nach Abschluss des CDM-Jobs, ob die Verlaufsdaten in Bigtable vorhanden sind. Da der Cassandra-Bigtable-Proxy CQL-Lesungen zulässt, können Sie cqlsh wieder mit dem ZDM-Proxy verbinden (der Lesevorgänge nach der Migration an das Ziel weiterleitet oder so konfiguriert werden kann) oder direkt mit dem Cassandra-Bigtable-Proxy, um die Daten abzufragen. Über ZDM-Proxy verbinden:

cqlsh <zdm-proxy-node-1-ip-address> 9042

In cqlsh:

SELECT COUNT(*) FROM zdmbigtable.employee; -- Check row count matches origin 
SELECT * FROM employee LIMIT 10; -- Check some sample data

Alternativ können Sie das cbt-Tool verwenden (falls auf der CDM-VM oder in Cloud Shell installiert), um Daten direkt in Bigtable abzurufen:

# First, install cbt if needed
# gcloud components update
# gcloud components install cbt

# Then lookup a specific row (replace 'some_employee_name' with an actual primary key)
cbt -project $PROJECT_ID -instance zdmbigtable lookup employee some_employee_name

9. Umstellung (konzeptionell)

Nachdem Sie die Datenkonsistenz zwischen Cassandra und Bigtable gründlich geprüft haben, können Sie mit der endgültigen Umstellung fortfahren.

Beim ZDM-Proxy muss er so neu konfiguriert werden, dass er hauptsächlich vom Ziel (Bigtable) statt vom Ursprung (Cassandra) liest. Dies geschieht in der Regel über die Konfiguration des ZDM-Proxys, wodurch der Lesetraffic Ihrer Anwendung effektiv auf Bigtable umgeleitet wird.

Sobald Sie sicher sind, dass Bigtable den gesamten Traffic korrekt ausliefert, können Sie Folgendes tun:

  • Beenden Sie doppelte Schreibvorgänge, indem Sie den ZDM-Proxy neu konfigurieren.
  • Nehmen Sie den ursprünglichen Cassandra-Cluster außer Betrieb.
  • Entfernen Sie den ZDM-Proxy und lassen Sie die Anwendung direkt mit dem Cassandra-Bigtable-Proxy verbinden oder verwenden Sie den nativen Bigtable-CQL-Client für Java.

Die Details zur Neukonfiguration des ZDM-Proxys für die Umstellung gehen über dieses grundlegende Codelab hinaus, werden aber in der Datastax ZDM-Dokumentation ausführlich beschrieben.

10. Bereinigen

Löschen Sie die während dieses Codelabs erstellten Ressourcen, um Gebühren zu vermeiden.

1. Compute Engine-VMs löschen

gcloud compute instances delete cassandra-origin-vm zdm-proxy-jumphost zdm-proxy-node-1 bigtable-proxy-vm cdm-migrator-vm --zone=$ZONE --quiet

2. Bigtable-Instanz löschen

gcloud bigtable instances delete zdmbigtable

3. Firewallregeln löschen

gcloud compute firewall-rules delete allow-migration-internal

4. Cassandra-Datenbank löschen (falls lokal installiert oder persistent)

Wenn Sie Cassandra außerhalb einer hier erstellten Compute Engine-VM installiert haben, folgen Sie den entsprechenden Schritten, um die Daten zu entfernen oder Cassandra zu deinstallieren.

11. Glückwunsch!

Sie haben einen proxybasierten Migrationspfad von Apache Cassandra zu Bigtable eingerichtet.

Sie haben Folgendes gelernt:

Cassandra und Bigtable bereitstellen

  • Konfigurieren Sie den Cassandra-Bigtable-Proxy für die CQL-Kompatibilität.
  • Stellen Sie den Datastax ZDM-Proxy bereit, um doppelte Schreibvorgänge und Traffic zu verwalten.
  • Verwenden Sie den Cassandra Data Migrator, um Verlaufsdaten zu verschieben.

Dieser Ansatz ermöglicht Migrationen mit minimaler Ausfallzeit und ohne Codeänderungen, da die Proxyebene genutzt wird.

Nächste Schritte

  • Bigtable-Dokumentation
  • Informationen zu erweiterten Konfigurationen und Umstellungsverfahren finden Sie in der Dokumentation zum Datastax ZDM Proxy.
  • Weitere Informationen finden Sie im Cassandra-Bigtable-Proxy-Repository.
  • Im Cassandra Data Migrator-Repository finden Sie Informationen zur erweiterten Verwendung.
  • Weitere Google Cloud-Codelabs ausprobieren
bug_report Fehler melden