Migracja z Cassandra do Bigtable z wykorzystaniem proxy z podwójnym zapisem
Informacje o tym ćwiczeniu (w Codelabs)
1. Wprowadzenie
Bigtable to w pełni zarządzana, wydajna usługa baz danych NoSQL zaprojektowana z myślą o dużych zbiorach zadań analitycznych i operacyjnych. Migracja z istniejących baz danych, takich jak Apache Cassandra, do Bigtable często wymaga starannego zaplanowania, aby zminimalizować czas przestoju i wpływ na aplikację.
To ćwiczenie z programowania pokazuje strategię migracji z Cassandra do Bigtable przy użyciu kombinacji narzędzi proxy:
- Pośrednik Cassandra-Bigtable: umożliwia klientom i narzędziom Cassandra (takim jak
cqlshlub sterowniki) interakcję z Bigtable za pomocą protokołu języka zapytań Cassandra (CQL) poprzez tłumaczenie zapytań. - Serwer proxy usługi migracji bez przestojów (ZDM) firmy Datastax: serwer proxy typu open source, który znajduje się między aplikacją a usługami bazy danych (źródło Cassandra i docelowy Bigtable za pomocą serwera proxy Cassandra-Bigtable). Zarządza on podwójnym zapisem i przekierowywaniem ruchu, umożliwiając migrację z minimalnymi zmianami w aplikacji i minimalnym czasem przestoju.
- Cassandra Data Migrator (CDM): narzędzie typu open source służące do zbiorczej migracji historycznych danych z źródłowego klastra Cassandra do docelowej instancji Bigtable.
Czego się nauczysz
- Jak skonfigurować podstawowy klaster Cassandra w Compute Engine.
- Jak utworzyć instancję Bigtable.
- Jak wdrożyć i skonfigurować serwer proxy Cassandra-Bigtable, aby zmapować schemat Cassandra na Bigtable.
- Jak wdrożyć i skonfigurować serwer proxy Datastax ZDM do podwójnego zapisu.
- Jak za pomocą narzędzia Cassandra Data Migrator przenieść istniejące dane zbiorczo.
- Ogólny proces migracji z Cassandra do Bigtable z wykorzystaniem serwera proxy
Czego potrzebujesz
- projekt Google Cloud z włączonymi płatnościami; Nowi użytkownicy mogą skorzystać z bezpłatnego okresu próbnego.
- podstawowa znajomość pojęć związanych z Google Cloud, takich jak projekty, Compute Engine, sieci VPC i reguły zapory sieciowej; podstawowa znajomość narzędzi wiersza poleceń w systemie Linux;
- Dostęp do maszyny z zainstalowanym i skonfigurowanym interfejsem wiersza poleceń
gcloudlub skorzystaj z Google Cloud Shell.
W tym laboratorium kodu będziemy głównie używać maszyn wirtualnych w Compute Engine w tej samej sieci VPC i regionie, aby uprościć konfigurację sieci. Zalecamy używanie wewnętrznych adresów IP.
2. Konfigurowanie środowiska
1. Wybierz lub utwórz projekt Google Cloud
Otwórz konsolę Google Cloud i wybierz istniejący projekt lub utwórz nowy. Zapisz identyfikator projektu.
2. Włącz wymagane interfejsy API
Sprawdź, czy w projekcie są włączone interfejsy Compute Engine API i Bigtable API.
gcloud services enable compute.googleapis.com bigtable.googleapis.com bigtableadmin.googleapis.com --project=<your-project-id>
Zastąp identyfikatorem projektu.
3. Wybieranie regionu i strefy
Wybierz region i strefę dla zasobów. Jako przykłady użyjemy regionów us-central1 i us-central1-c. Dla wygody zdefiniuj je jako zmienne środowiskowe:
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. Konfigurowanie reguł zapory sieciowej
Musimy zezwolić na komunikację między naszymi maszynami wirtualnymi w sieci VPC domyślnej na kilku portach:
- Cassandra/Proxies CQL Port: 9042
- Port ZDM Proxy Health Check: 14001
- SSH: 22
Utwórz regułę zapory sieciowej, która zezwala na ruch wewnętrzny na tych portach. Aby łatwo zastosować tę regułę do odpowiednich maszyn wirtualnych, użyjemy tagu cassandra-migration.
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. Wdrażanie klastra Cassandra (Origin)
W ramach tego ćwiczenia z programowania skonfigurujemy prosty klaster Cassandra z jednym węzłem w Compute Engine. W rzeczywistych warunkach połączysz się z dotychczasowym klastrem.
1. Tworzenie maszyny wirtualnej GCE dla Cassandra
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. Instalowanie systemu Cassandra
# 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. Tworzenie przestrzeni kluczy i tabeli
Użyjemy przykładowej tabeli pracowników i utworzymy przestrzeń kluczy o nazwie „zdmbigtable”.
cd ~/apache-cassandra bin/cqlsh <your-localhost-ip? 9042 #starts the cql shell
W 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;
Pozostaw sesję SSH otwartą lub zapisz adres IP tej maszyny wirtualnej (pole „hostname” –I).
4. Konfigurowanie Bigtable (Target)
Czas trwania: 0:01
Utwórz instancję Bigtable. Jako identyfikator instancji użyjemy zdmbigtable.
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
Sama tabela Bigtable zostanie utworzona później przez skrypt konfiguracji proxy Cassandra-Bigtable.
5. Konfigurowanie proxy Cassandra-Bigtable
1. Tworzenie maszyny wirtualnej Compute Engine dla serwera proxy Cassandra-Bigtable
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
Połącz się przez SSH z maszyną wirtualną bigtable-proxy:
gcloud compute ssh bigtable-proxy-vm
Wewnątrz maszyny wirtualnej:
# 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. Konfigurowanie serwera proxy
nano config.yaml
Zaktualizuj te zmienne. Aby uzyskać bardziej zaawansowaną konfigurację, skorzystaj z tego przykładu w 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
Zapisz i zamknij plik (Ctrl+X, a potem Y, a następnie Enter w nano).
3. Uruchamianie serwera proxy Cassandra-Bigtable
Uruchom serwer proxy.
# At the root of the cassandra-to-bigtable-proxy directory go run proxy.go
Serwer proxy uruchomi się i będzie nasłuchiwać na porcie 9042, aby odbierać przychodzące połączenia CQL. Utrzymać tę sesję terminala. Zapisz adres IP tej maszyny wirtualnej (nazwa hosta -I)
4. Tworzenie tabeli za pomocą CQL
Połącz się cqlsh z adresem IP maszyny wirtualnej proxy Cassandra-Bigtable.
W cqlsh uruchom to polecenie
-- 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
);
W konsoli Google Cloud sprawdź, czy w instancji Bigtable istnieją tabela pracowników oraz tabela metadanych.
6. Konfigurowanie serwera proxy ZDM
ZDM Proxy wymaga co najmniej 2 maszyn: co najmniej 1 węzła proxy, który obsługuje ruch, oraz „hosta pośredniczącego” używanego do wdrażania i sterowania za pomocą Ansible.
1. Tworzenie maszyn wirtualnych Compute Engine dla serwera proxy ZDM
Potrzebujemy 2 maszyn wirtualnych: zdm-proxy-jumphost i 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
Zapisz adresy IP obu maszyn wirtualnych.
2. Przygotuj hosta przesiadkowego
Nawiązywanie połączenia SSH z hostem zdm-jumphost
gcloud compute ssh zdm-jumphost
# Install Git and Ansible
sudo apt-get update
sudo apt-get install -y git ansible
Wnętrze jumphosta
git clone https:\/\/github.com/datastax/zdm-proxy-automation.git
cd zdm-proxy-automation/ansible/
Zmodyfikuj główny plik konfiguracji vars/zdm_proxy_cluster_config.yml:
Zaktualizuj parametry origin_contact_points i target_contact_points, podając wewnętrzne adresy IP maszyny wirtualnej Cassandra i maszyny wirtualnej Cassandra-Bigtable Proxy. Nie usuwaj komentarza z uwierzytelnianiem, ponieważ nie skonfigurowaliśmy go.
##############################
#### 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)
Zapisz i zamknij ten plik.
3. Wdrażanie serwera proxy ZDM za pomocą Ansible
Uruchom poradnik Ansible z katalogu ansible na hoście pośredniczącym:
ansible-playbook deploy_zdm_proxy.yml -i zdm_ansible_inventory
To polecenie zainstaluje niezbędne oprogramowanie (np. Dockera) na węźle proxy (zdm-proxy-node-1), pobierze obraz ZDM Proxy Dockera i uruchomi kontener proxy z podaną konfiguracją.
4. Sprawdzanie stanu serwera proxy ZDM
Sprawdź punkt końcowy gotowości serwera proxy ZDM działającego na węźle zdm-proxy-node-1 (port 14001) z hosta przejściowego:
# Replace <zdm-proxy-node-1-internal-ip> with the actual internal IP.
curl -G http://<zdm-proxy-node-1-internal-ip>:14001/health/readiness
Powinny pojawić się dane wyjściowe podobne do tych, które wskazują, że zarówno Origin (Cassandra), jak i Target (Cassandra-Bigtable Proxy) są WŁĄCZONE:
{
"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. Konfigurowanie aplikacji i rozpoczynanie zapisów podwójnych
Czas trwania: 0:05
Na tym etapie rzeczywistej migracji należy zmienić konfigurację aplikacji, aby wskazywały one adres IP węzła proxy ZDM (np. :9042) zamiast łączyć się bezpośrednio z Cassandra.
Gdy aplikacja połączy się z serwerem proxy ZDM: odczyty są domyślnie pobierane z źródła (Cassandra). Zapisy są wysyłane zarówno do źródła (Cassandra), jak i do miejsca docelowego (Bigtable przez proxy Cassandra-Bigtable). Dzięki temu aplikacja może normalnie działać, a nowe dane są zapisywane jednocześnie w obu bazach danych. Możesz przetestować połączenie za pomocą polecenia cqlsh wskazującego na serwer proxy ZDM z hosta pośredniczącego lub innej maszyny wirtualnej w sieci:
Cqlsh <zdm-proxy-node-1-ip-address> 9042
Spróbuj wstawić dane:
INSERT INTO zdmbigtable.employee (name, age, is_active) VALUES ('Alice', 30, true);
SELECT * FROM employee WHERE name = 'Alice';
Te dane powinny być zapisywane zarówno w Cassandra, jak i w Bigtable. Możesz to sprawdzić w Bigtable, otwierając konsolę Google Cloud i edytor zapytań Bigtable dla swojej instancji. Uruchom zapytanie „SELECT * FROM employee”, a niedawno wstawione dane powinny być widoczne.
8. Migracja danych historycznych za pomocą narzędzia Cassandra Data Migrator
Teraz, gdy podwójne zapisy są aktywne w przypadku nowych danych, użyj narzędzia Cassandra Data Migrator (CDM) do skopiowania dotychczasowych danych historycznych z Cassandra do Bigtable.
1. Tworzenie maszyny wirtualnej Compute Engine na potrzeby CDM
Ta maszyna wirtualna potrzebuje wystarczającej ilości pamięci dla Sparka.
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. Instalowanie wymagań wstępnych (Java 11, Spark)
Połącz się przez SSH z maszyną wirtualną cdm-migrator-vm:
gcloud compute ssh cdm-migrator-vm
Wewnątrz maszyny wirtualnej:
# 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. Pobieranie narzędzia Cassandra Data Migrator
Pobierz plik jar narzędzia CDM. Sprawdź na stronie wersji w GitHub narzędzia Cassandra Data Migrator odpowiedni adres URL wybranej wersji.
# 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. Konfigurowanie CDM
Utwórz plik properties o nazwie cdm.properties.
Nano cdm.properties
Wklej tę konfigurację, zastępując adresy IP i wyłączając funkcje TTL/Writetime, ponieważ nie są one bezpośrednio obsługiwane przez Bigtable. Zablokuj uwierzytelnianie.
# 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
Zapisz i zamknij plik.
5. Uruchamianie zadania migracji
Przeprowadź migrację za pomocą polecenia spark-submit. To polecenie informuje Sparka, aby uruchomił plik jar CDM, korzystając z pliku właściwości i określając przestrzeń kluczy oraz tabelę, którą ma migrować. Dostosuj ustawienia pamięci (–driver-memory, –executor-memory) na podstawie rozmiaru maszyny wirtualnej i objętości danych.
Upewnij się, że jesteś w katalogu zawierającym plik jar i plik właściwości CDM. Jeśli pobrałeś inną wersję, zastąp „cassandra-data-migrator-5.2.2.jar”.
./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
Migracja będzie przebiegać w tle, a dzienniki będą zapisywane w folderze cdm_migration_... .log. Monitoruj plik dziennika pod kątem postępu i błędów:
tail -f cdm_migration_*.log
6. Weryfikowanie migracji danych
Po zakończeniu zadania CDM sprawdź, czy dane historyczne znajdują się w Bigtable. Ponieważ serwer proxy Cassandra-Bigtable umożliwia odczytywanie zapytań CQL, możesz ponownie używać narzędzia cqlsh połączonego z serwerem proxy ZDM (który kieruje odczyty do docelowego serwera po migracji lub może zostać skonfigurowany w ten sposób) lub bezpośrednio z serwerem proxy Cassandra-Bigtable do wysyłania zapytań do danych. Łączenie przez serwer proxy ZDM:
cqlsh <zdm-proxy-node-1-ip-address> 9042
W cqlsh:
SELECT COUNT(*) FROM zdmbigtable.employee; -- Check row count matches origin SELECT * FROM employee LIMIT 10; -- Check some sample data
Możesz też użyć narzędzia cbt (jeśli jest zainstalowane w maszynie wirtualnej CDM lub w Cloud Shell), aby przeglądać dane bezpośrednio w Bigtable:
# 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. Przejście (koncepcja)
Po dokładnym sprawdzeniu spójności danych między Cassandra i Bigtable możesz przejść do ostatecznego przejścia.
W przypadku serwera proxy ZDM przejście na nową wersję wymaga zmiany konfiguracji, tak aby odczyt odbywał się głównie z punktu docelowego (Bigtable), a nie z punktu źródłowego (Cassandra). Zwykle odbywa się to za pomocą konfiguracji ZDM Proxy, co skutecznie przekierowuje ruch odczytu aplikacji do Bigtable.
Gdy upewnisz się, że Bigtable poprawnie wyświetla cały ruch, możesz:
- Zatrzymaj podwójne zapisy, zmieniając konfigurację serwera ZDM Proxy.
- wycofać pierwotny klaster Cassandra.
- Usuń serwer proxy ZDM i połącz aplikację bezpośrednio z serwerem proxy Cassandra-Bigtable lub użyj natywnego klienta CQL Bigtable dla Javy.
Szczegóły dotyczące rekonfiguracji serwera proxy ZDM na potrzeby przełączenia wykraczają poza zakres tego podstawowego laboratorium kodu, ale są szczegółowo opisane w dokumentacji usługi Datastax ZDM.
10. Czyszczenie danych
Aby uniknąć opłat, usuń zasoby utworzone w ramach tego ćwiczenia z programowania.
1. Usuwanie maszyn wirtualnych Compute Engine
gcloud compute instances delete cassandra-origin-vm zdm-proxy-jumphost zdm-proxy-node-1 bigtable-proxy-vm cdm-migrator-vm --zone=$ZONE --quiet
2. Usuwanie instancji Bigtable
gcloud bigtable instances delete zdmbigtable
3. Usuwanie reguł zapory sieciowej
gcloud compute firewall-rules delete allow-migration-internal
4. usunąć bazę danych Cassandra (jeśli jest zainstalowana lokalnie lub utrwalona);
Jeśli zainstalowałeś/zainstalowałaś Cassandra poza maszyną wirtualną Compute Engine utworzoną tutaj, wykonaj odpowiednie czynności, aby usunąć dane lub odinstalować Cassandra.
11. Gratulacje!
Udało Ci się skonfigurować ścieżkę migracji z Apache Cassandra do Bigtable opartą na serwerze proxy.
Poznasz te funkcje:
Wdróż Cassandra i Bigtable.
- Skonfiguruj serwer proxy Cassandra-Bigtable, aby zapewnić zgodność z CQL.
- Wdróż serwer proxy ZDM firmy Datastax, aby zarządzać podwójnym zapisem i ruchem.
- Do przenoszenia danych historycznych użyj narzędzia Cassandra Data Migrator.
Dzięki temu podejściu możesz przeprowadzać migracje z minimalnym czasem przestoju i bez wprowadzania zmian w kodzie, korzystając z warstwy proxy.
Dalsze kroki
- Dokumentacja Bigtable
- Więcej informacji o zaawansowanych konfiguracjach i procedurach przełączania znajdziesz w dokumentacji serwera proxy ZDM firmy Datastax.
- Więcej informacji znajdziesz w repozytorium Cassandra-Bigtable Proxy.
- Aby dowiedzieć się więcej o zaawansowanym korzystaniu z narzędzia, zapoznaj się z repozytorium Cassandra Data Migrator.
- Wypróbuj inne ćwiczenia z programowania Google Cloud