Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Wenn möglich, empfehlen wir, dass Sie die native Apache Cassandra-Funktion verwenden, um Daten aus Ihrem vorhandenen Cluster in Azure Managed Instance für Apache Cassandra zu migrieren, indem Sie einen Hybridcluster konfigurieren. Diese Funktion verwendet das Gossipprotokoll von Apache Cassandra, um Daten nahtlos aus Ihrem Quellrechenzentrum in Ihr neues Rechenzentrum der verwalteten Instanz zu replizieren.
Möglicherweise gibt es einige Szenarien, in denen Ihre Quelldatenbankversion nicht kompatibel ist, oder ein Hybridclustersetup ist andernfalls nicht machbar. In diesem Tutorial wird beschrieben, wie Sie Daten live mithilfe eines Proxys für duales Schreiben und Apache Spark zu Azure Managed Instance for Apache Cassandra migrieren. Der Proxy für duales Schreiben stellt die fortlaufende Erfassung von Live-Änderungen sicher, während Apache Spark Verlaufsdaten als Massenvorgang kopiert. Diese Methode bietet folgende Vorteile:
- Minimale Anwendungsänderungen. Damit der Proxy Verbindungen von Ihrem Anwendungscode akzeptiert, sind wenig bis keine Konfigurationsänderungen nötig. Sie leitet alle Anforderungen an Ihre Quelldatenbank weiter und leitet Schreibvorgänge asynchron an ein sekundäres Ziel weiter.
- Abhängigkeit vom Wire Protocol des Clients. Da dieser Ansatz nicht von Back-End-Ressourcen oder internen Protokollen abhängig ist, kann er mit jedem Quell- oder Ziel-Cassandra-System verwendet werden, das das Apache Cassandra-Drahtprotokoll implementiert.
Die Vorgehensweise ist in der folgenden Abbildung dargestellt.
Voraussetzungen
Stellen Sie mithilfe des Azure-Portals oder der Azure CLI ein Azure Managed Instance for Apache Cassandra-Cluster bereit. Stellen Sie sicher, dass Sie über CQLSH eine Verbindung mit Ihrem Cluster herstellen können.
Stellen Sie in Ihrem virtuellen verwalteten Cassandra-Netzwerk ein Azure Databricks-Konto bereit. Stellen Sie sicher, dass das Konto über einen Netzwerkzugriff auf Ihren Cassandra-Quellcluster verfügt. In diesem Beispiel wird ein Spark-Cluster in diesem Konto für das laden der historischen Daten erstellt.
Stellen Sie sicher, dass Sie das Schlüsseltasten-/Tabellenschema bereits aus Ihrer Cassandra-Quelldatenbank zu Ihrer Zieldatenbank für verwaltete Instanzen von Cassandra migriert haben.
Bereitstellen eines Spark-Clusters
Es wird empfohlen, Azure Databricks-Laufzeitversion 7.5 auszuwählen, die Spark 3.0 unterstützt.
Hinzufügen von Spark-Abhängigkeiten
Sie müssen dem Cluster die Apache Spark-Cassandra-Connectorbibliothek hinzufügen, um eine Verbindung mit Wire Protocol-kompatiblen Apache Cassandra-Endpunkten herzustellen. Wählen Sie in Ihrem Cluster Bibliotheken>Neue>Maveninstallieren und fügen Sie dann com.datastax.spark:spark-cassandra-connector-assembly_2.12:3.0.0 in Maven-Koordinaten hinzu.
Wichtig
Wenn Sie die Anforderung haben, Apache Cassandra writetime für jede Zeile während der Migration zu erhalten, empfehlen wir dieses Beispiel zu benutzen. Das Abhängigkeitspaket in diesem Beispiel enthält auch den Spark-Connector. Installieren Sie daher diese Version anstelle der Connector-Assembly.
Dieses Beispiel zeigt auch, wie der Zeilenvergleich zwischen Quelle und Ziel nach dem Laden der Verlaufsdaten überprüft wird. Weitere Informationen finden Sie unter Ausführen des Ladens von Verlaufsdaten und Überprüfen der Quelle und des Ziels.
Wählen Sie Installieren aus, und starten Sie den Cluster nach Abschluss der Installation neu.
Hinweis
Stellen Sie sicher, dass Sie den Azure Databricks-Cluster neu starten, nachdem die Cassandra-Connectorbibliothek installiert wurde.
Installieren Sie den Proxy für duales Schreiben.
Für eine optimale Leistung bei dualen Schreibvorgängen empfehlen wir, den Proxy auf allen Knoten in Ihrem Quell-Cassandra-Cluster zu installieren.
#assuming you do not have git already installed
sudo apt-get install git
#assuming you do not have maven already installed
sudo apt install maven
#clone repo for dual-write proxy
git clone https://github.com/Azure-Samples/cassandra-proxy.git
#change directory
cd cassandra-proxy
#compile the proxy
mvn package
Starten des Proxys für duales Schreiben
Es wird empfohlen, den Proxy auf allen Knoten in Ihrem Cassandra-Quellcluster zu installieren. Führen Sie mindestens den folgenden Befehl aus, um den Proxy auf allen Knoten zu starten. Ersetzen Sie <target-server> durch eine IP- oder Serveradresse eines der Knoten im Zielcluster. Ersetzen Sie <path to JKS file> durch den Pfad zu einer lokalen jks-Datei und <keystore password> durch das entsprechende Kennwort.
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>
Wenn Sie den Proxy auf diese Weise starten, muss Folgendes zutreffen:
- Quell- und Zielendpunkte besitzen denselben Benutzernamen und dasselbe Kennwort.
- Quell- und Zielendpunkte implementieren Secure Sockets Layer (SSL).
Wenn Ihre Quell- und Zielendpunkte diese Kriterien nicht erfüllen können, finden Sie nachfolgend weitere Konfigurationsoptionen.
Konfigurieren von SSL
Bei SSL können Sie entweder einen vorhandenen Schlüsselspeicher verwenden, z. B. den von Ihrem Quellcluster verwendeten, oder ein selbstsigniertes Zertifikat mithilfe von keytool erstellen.
keytool -genkey -keyalg RSA -alias selfsigned -keystore keystore.jks -storepass password -validity 360 -keysize 2048
Wenn die Quell- oder Zielendpunkte SSL nicht implementieren, können Sie dieses auch deaktivieren. Verwenden Sie hierzu die Flags --disable-source-tls oder --disable-target-tls:
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
Hinweis
Stellen Sie sicher, dass Ihre Clientanwendung denselben Schlüsselspeicher und dasselbe Kennwort wie die für den Dual-Write-Proxy verwendeten verwendet, wenn Sie SSL-Verbindungen mit der Datenbank erstellen, die den Proxy verwenden.
Konfigurieren der Anmeldeinformationen und des Ports
Standardmäßig werden die Quellanmeldeinformationen von Ihrer Client-App übergeben. Der Proxy verwendet die Anmeldeinformationen zum Herstellen von Verbindungen mit den Quell- und Zielclustern. Wie bereits erwähnt, wird bei diesem Prozess davon ausgegangen, dass die Quell- und Zielanmeldeinformationen identisch sind. Bei Bedarf können Sie einen anderen Benutzernamen und ein anderes Kennwort für den Cassandra-Zielendpunkt beim Starten des Proxys separat angeben:
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>
Der voreingestellte Wert für die Quell- und Zielports, wenn nicht angegeben, ist 9042. Werden der Cassandra-Quell- oder Zielendpunkt an einem anderen Port ausgeführt, können Sie mit --source-port oder --target-port eine andere Portnummer angeben:
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>
Remote-Bereitstellung des Proxymoduls
Es kann Situationen geben, in denen Sie den Proxy nicht selbst auf den Clusterknoten installieren möchten. Sie möchten es auf einem separaten Computer installieren. Geben Sie in diesem Szenario die IP-Adresse von <source-server>:
java -jar target/cassandra-proxy-1.0-SNAPSHOT-fat.jar <source-server> <destination-server>
Warnung
Möglicherweise möchten Sie den Proxy remote auf einem separaten Computer ausführen, anstatt ihn auf allen Knoten in Ihrem Quell-Apache Cassandra-Cluster auszuführen. In diesem Fall wird empfohlen, dass Sie den Proxy auf derselben Anzahl von Computern bereitstellen, wie Sie Knoten in Ihrem Cluster haben. Richten Sie eine Ersetzung für ihre IP-Adressen in system.peers ein. Verwenden Sie diese Konfiguration im Proxy. Wenn Sie diesen Ansatz nicht verwenden, wirkt sich dies möglicherweise auf die Leistung aus, während die Livemigration auftritt, da der Clienttreiber keine Verbindungen mit allen Knoten im Cluster öffnen kann.
Keine Änderungen am Anwendungscode zulassen
Der Proxy lauscht standardmäßig an Port 29042. Sie müssen den Anwendungscode so ändern, dass er auf diesen Port verweist. Alternativ können Sie den Port ändern, auf den der Proxy lauscht. Sie können diesen Ansatz verwenden, wenn Sie Codeänderungen auf Anwendungsebene beseitigen möchten, indem Sie:
- den Cassandra-Quellservers auf einem anderen Port ausführen.
- den Proxy auf dem Cassandra-Standardport 9042 ausführen.
java -jar target/cassandra-proxy-1.0-SNAPSHOT-fat.jar source-server destination-server --proxy-port 9042
Hinweis
Für die Installation des Proxys auf Clusterknoten ist kein Neustart der Knoten erforderlich. Wenn Sie über viele Anwendungsclients verfügen und den Proxy lieber auf dem Standardmäßigen Cassandra-Port 9042 ausführen möchten, um Codeänderungen auf Anwendungsebene zu beseitigen, ändern Sie den Apache Cassandra-Standardport. Anschließend müssen Sie die Knoten in Ihrem Cluster neu starten und den Quellport als den neuen Port konfigurieren, den Sie für Ihren Cassandra-Quellcluster festgelegt haben.
Im folgenden Beispiel ändern wir den Cassandra-Quellcluster so, dass er auf dem Port 3074 ausgeführt wird, und wir starten den Cluster auf Port 9042:
java -jar target/cassandra-proxy-1.0-SNAPSHOT-fat.jar source-server destination-server --proxy-port 9042 --source-port 3074
Erzwingen von Protokollen
Der Proxy kann Protokolle erzwingen, die möglicherweise erforderlich sind, wenn der Quellendpunkt moderner ist als der Zielendpunkt, oder wenn der Quellendpunkt anderweitig nicht unterstützt wird. In diesem Fall können Sie --protocol-version und --cql-version festlegen, um die Übereinstimmung des Protokolls mit dem Zielendpunkt zu erzwingen:
java -jar target/cassandra-proxy-1.0-SNAPSHOT-fat.jar source-server destination-server --protocol-version 4 --cql-version 3.11
Nachdem der Dual-Write-Proxy ausgeführt wurde, ändern Sie den Port auf Dem Anwendungsclient, und starten Sie es neu. Oder ändern Sie den Cassandra-Port, und starten Sie den Cluster neu, wenn Sie diesen Ansatz ausgewählt haben. Der Proxy startet die Weiterleitung von Schreibvorgängen an den Zielendpunkt. Weitere Informationen zur Überwachung und zu Metriken im Proxytool finden Sie hier.
Laden der Verlaufsdaten
Erstellen Sie zum Laden der Daten ein Scala-Notebook in Ihrem Azure Databricks-Konto. Ersetzen Sie Ihre Quell- und Zielkonfigurationen für Cassandra durch die entsprechenden Anmeldeinformationen sowie die Quell-und Zielkeyspaces und -tabellen. Fügen Sie im folgenden Beispiel nach Bedarf für jede Tabelle weitere Variablen hinzu, und führen Sie den Code anschließend aus. Nachdem Ihre Anwendung mit dem Senden von Anforderungen an den Proxy für duales Schreiben begonnen hat, können Sie die Verlaufsdaten migrieren.
import com.datastax.spark.connector._
import com.datastax.spark.connector.cql._
import org.apache.spark.SparkContext
// source cassandra configs
val sourceCassandra = Map(
"spark.cassandra.connection.host" -> "<Source Cassandra Host>",
"spark.cassandra.connection.port" -> "9042",
"spark.cassandra.auth.username" -> "<USERNAME>",
"spark.cassandra.auth.password" -> "<PASSWORD>",
"spark.cassandra.connection.ssl.enabled" -> "true",
"keyspace" -> "<KEYSPACE>",
"table" -> "<TABLE>"
)
//target cassandra configs
val targetCassandra = Map(
"spark.cassandra.connection.host" -> "<Source Cassandra Host>",
"spark.cassandra.connection.port" -> "9042",
"spark.cassandra.auth.username" -> "<USERNAME>",
"spark.cassandra.auth.password" -> "<PASSWORD>",
"spark.cassandra.connection.ssl.enabled" -> "true",
"keyspace" -> "<KEYSPACE>",
"table" -> "<TABLE>",
//throughput related settings below - tweak these depending on data volumes.
"spark.cassandra.output.batch.size.rows"-> "1",
"spark.cassandra.output.concurrent.writes" -> "1000",
"spark.cassandra.connection.remoteConnectionsPerExecutor" -> "1",
"spark.cassandra.concurrent.reads" -> "512",
"spark.cassandra.output.batch.grouping.buffer.size" -> "1000",
"spark.cassandra.connection.keep_alive_ms" -> "600000000"
)
//set timestamp to ensure it is before read job starts
val timestamp: Long = System.currentTimeMillis / 1000
//Read from source Cassandra
val DFfromSourceCassandra = sqlContext
.read
.format("org.apache.spark.sql.cassandra")
.options(sourceCassandra)
.load
//Write to target Cassandra
DFfromSourceCassandra
.write
.format("org.apache.spark.sql.cassandra")
.options(targetCassandra)
.option("writetime", timestamp)
.mode(SaveMode.Append)
.save
Hinweis
Im vorherigen Scala-Beispiel timestamp wird vor dem Lesen aller Daten in der Quelltabelle auf die aktuelle Uhrzeit festgelegt. Anschließend wird writetime auf diesen früheren Zeitstempel festgelegt. Durch diesen Ansatz wird sichergestellt, dass Datensätze, die aus den Verlaufsdaten auf den Zielendpunkt geschrieben werden, keine Updates mit einem späteren Zeitstempel aus dem Proxy für duales Schreiben überschreiben können, während die Verlaufsdaten gelesen werden.
Wichtig
Falls Sie jedoch die genauen Zeitstempel beibehalten müssen, sollten Sie die Verlaufsdaten auf eine Weise migrieren, bei der die Zeitstempel beibehalten werden, wie etwa in diesem Beispiel. Das Abhängigkeits-Jar im Beispiel enthält auch den Spark-Connector, daher müssen Sie die Spark-Connector-Assembly, die in den früheren Voraussetzungen erwähnt wurde, nicht installieren. Wenn beide in Ihrem Spark-Cluster installiert sind, treten Konflikte auf.
Überprüfen der Quelle und des Ziels
Nachdem das Laden der Verlaufsdaten abgeschlossen ist, sollten Ihre Datenbanken synchron und zur Übernahme bereit sein. Vor der endgültigen Übernahme wird eine Überprüfung der Quelle und des Ziels empfohlen, um sicherzustellen, dass beide übereinstimmen.
Hinweis
Wenn Sie das in den früheren Abschnitten erwähnte Cassandra-Migrationsbeispiel zum Beibehalten writetimeverwendet haben, haben Sie die Möglichkeit, die Migration zu überprüfen , indem Sie Zeilen in Quelle und Ziel basierend auf bestimmten Toleranzen vergleichen .