Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
Jika memungkinkan, kami sarankan Anda menggunakan kemampuan asli Apache Cassandra untuk memigrasikan data dari kluster yang ada ke Azure Managed Instance for Apache Cassandra dengan mengonfigurasi kluster hibrid. Kemampuan ini menggunakan protokol gosip Apache Cassandra untuk mereplikasi data dari pusat data sumber Anda ke pusat data instans terkelola yang baru tanpa hambatan.
Ada beberapa skenario di mana versi database sumber Anda tidak kompatibel, atau penyiapan kluster hibrid tidak memungkinkan. Tutorial ini menjelaskan cara memigrasikan data ke Azure Managed Instance for Apache Cassandra secara langsung menggunakan proksi tulis ganda dan Apache Spark. Proksi tulis ganda digunakan untuk menangkap perubahan langsung, sementara data historis disalin secara massal menggunakan Apache Spark. Keuntungan-keuntungan dari pendekatan ini adalah:
- Perubahan aplikasi minimal. Proksi dapat menerima koneksi dari kode aplikasi Anda dengan sedikit atau tanpa perubahan konfigurasi. Ini merutekan semua permintaan ke database sumber Anda dan secara asinkron merutekan penulisan ke target sekunder.
- Dependensi protokol kabel klien. Karena pendekatan ini tidak bergantung pada sumber daya back-end atau protokol internal, pendekatan ini dapat digunakan dengan sistem Cassandra sumber atau target apa pun yang mengimplementasikan protokol kawat Apache Cassandra.
Gambar berikut mengilustrasikan pendekatan.
Prasyarat
Provisikan kluster Azure Managed Instance for Apache Cassandra dengan menggunakan portal Microsoft Azure atau CLI Azure. Pastikan Anda dapat tersambung ke kluster Anda dengan CQLSH.
Provisikan akun Azure Databricks di dalam jaringan virtual Managed Cassandra. Pastikan akun memiliki akses jaringan ke sumber kluster Cassandra Anda. Contoh ini membuat kluster Spark di akun ini untuk beban data historis.
Pastikan Anda sudah memigrasikan skema keyspace/tabel dari database Cassandra sumber Anda ke database instans terkelola Cassandra target Anda.
Provisi kluster Spark
Kami menyarankan agar Anda memilih runtime Azure Databricks versi 7.5, yang mendukung Spark 3.0.
Tambahkan ketergantungan Spark
Anda perlu menambahkan pustaka Konektor Apache Spark Cassandra ke kluster Anda untuk terhubung ke setiap protokol kawat yang kompatibel dengan titik akhir Apache Cassandra. Di klaster Anda, pilih Pustaka>Pasang Baru>Maven, lalu tambahkan com.datastax.spark:spark-cassandra-connector-assembly_2.12:3.0.0 di koordinat Maven.
Penting
Jika Anda memiliki persyaratan untuk mempertahankan Apache Cassandra writetime untuk setiap baris selama migrasi, sebaiknya gunakan sampel ini. Jar dependensi dalam sampel ini juga berisi konektor Spark, jadi instal versi ini alih-alih rakitan konektor.
Sampel ini juga berguna jika Anda ingin melakukan validasi perbandingan baris antara sumber dan target setelah pemuatan data historis selesai. Lihat Menjalankan beban data historis dan Memvalidasi sumber dan target.
Pilih Pasang,lalu mulai ulang klaster ketika pemasangan selesai.
Catatan
Pastikan untuk memulai ulang kluster Azure Databricks setelah pustaka Konektor Cassandra terpasang.
Pasang proksi dual-write
Untuk performa optimal selama penulisan ganda, kami sarankan Anda menginstal proksi pada semua simpul di kluster Cassandra sumber Anda.
#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
Mulai proksi dual-write
Kami merekomendasikan untuk memasang proksi pada seluruh simpul dalam sumber kluster Cassandra. Pada kondisi minimum, jalankan perintah berikut untuk memulai proksi di setiap simpul. Ganti <target-server> dengan sebuah IP atau alamat server dari satu node dalam kluster target. Ganti <path to JKS file> dengan jalur ke file jks lokal, dan ganti <keystore password> dengan kata sandi yang sesuai.
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>
Mulai proksi dengan cara ini dengan asumsi bahwa poin-poin berikut adalah benar:
- Titik akhir sumber dan target memiliki nama pengguna dan kata sandi yang sama.
- Titik akhir sumber dan target mengimplementasikan Secure Sockets Layer (SSL).
Jika titik akhir sumber dan target Anda tidak dapat memenuhi kriteria tersebut, baca terus untuk opsi konfigurasi lebih lanjut.
Mengonfigurasi SSL
Untuk SSL, Anda dapat menerapkan keystore yang ada, misalnya, yang digunakan kluster sumber Anda, atau membuat sertifikat yang ditandatangani sendiri dengan menggunakan keytool:
keytool -genkey -keyalg RSA -alias selfsigned -keystore keystore.jks -storepass password -validity 360 -keysize 2048
Anda juga dapat menonaktifkan SSL untuk titik akhir sumber atau target jika tidak mengimplementasi SSL. Gunakan --disable-source-tls atau --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
Catatan
Pastikan aplikasi klien Anda menggunakan keystore dan kata sandi yang sama dengan yang digunakan untuk proksi penulisan ganda saat Anda membangun koneksi SSL ke database yang menggunakan proksi.
Konfigurasikan informasi masuk dan port
Secara default, kredensial sumber diteruskan dari aplikasi klien Anda. Proksi menggunakan kredensial untuk membuat koneksi ke kluster sumber dan target. Seperti disebutkan sebelumnya, proses ini mengasumsikan bahwa informasi masuk sumber dan target adalah sama. Jika dibutuhkan, Anda dapat menentukan nama pengguna dan kata sandi yang berbeda untuk target titik akhir Cassandra secara terpisah saat memulai proksi:
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>
Port sumber dan target default, ketika tidak ditentukan, adalah 9042. Jika titik akhir Cassandra target atau sumber dijalankan pada port yang berbeda, Anda dapat menggunakan --source-port atau --target-port untuk menentukan nomor port yang berbeda:
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>
Sebarkan proksi dari jarak jauh
Mungkin ada keadaan di mana Anda tidak ingin menginstal proksi pada node kluster itu sendiri. Anda ingin menginstalnya pada komputer terpisah. Dalam skenario tersebut, tentukan alamat IP :<source-server>
java -jar target/cassandra-proxy-1.0-SNAPSHOT-fat.jar <source-server> <destination-server>
Peringatan
Anda mungkin ingin menjalankan proksi dari jarak jauh pada komputer terpisah daripada menjalankannya pada semua simpul di kluster Apache Cassandra sumber Anda. Jika demikian, kami sarankan Anda menyebarkan proksi ke jumlah komputer yang sama dengan jumlah simpul pada kluster Anda. Siapkan substitusi untuk alamat IP mereka di system.peers. Gunakan konfigurasi ini di proksi. Jika Anda tidak menggunakan pendekatan ini, pendekatan ini mungkin memengaruhi performa saat migrasi langsung terjadi, karena driver klien tidak dapat membuka koneksi ke semua simpul dalam kluster.
Izinkan perubahan kode aplikasi nol
Secara default, proksi tersebut mengikuti port 29042. Anda harus mengubah kode aplikasi untuk menunjuk ke port ini. Atau, Anda dapat mengubah port yang digunakan oleh proksi. Anda dapat menggunakan pendekatan ini jika Anda ingin menghilangkan perubahan kode tingkat aplikasi dengan:
- Menjalankan sumber server Cassandra pada port yang berbeda.
- Menjalankan proksi pada port Cassandra standar 9042.
java -jar target/cassandra-proxy-1.0-SNAPSHOT-fat.jar source-server destination-server --proxy-port 9042
Catatan
Menginstal proksi pada simpul kluster tidak memerlukan menghidupkan ulang simpul tersebut. Jika Anda memiliki banyak klien aplikasi dan lebih suka menjalankan proksi pada port Cassandra standar 9042 untuk menghilangkan perubahan kode tingkat aplikasi apa pun, ubah port default Apache Cassandra. Anda kemudian perlu memulai ulang simpul di kluster Anda, dan mengonfigurasi port sumber untuk menjadi port baru yang Anda tentukan untuk sumber kluster Cassandra Anda.
Dalam contoh berikut, kami mengubah sumber kluster Cassandra untuk dijalankan pada port 3074, dan kami memulai kluster pada port 9042:
java -jar target/cassandra-proxy-1.0-SNAPSHOT-fat.jar source-server destination-server --proxy-port 9042 --source-port 3074
Protokol paksa
Proksi tersebut memiliki beberapa fungsi untuk memaksa protokol-protokol yang mungkin diperlukan jika titik akhir sumber lebih modern daripada target atau jika target tidak mendukung. Dalam hal ini, Anda dapat menentukan --protocol-version dan --cql-version untuk memaksa protokol mematuhi target:
java -jar target/cassandra-proxy-1.0-SNAPSHOT-fat.jar source-server destination-server --protocol-version 4 --cql-version 3.11
Setelah proksi penulisan ganda berjalan, ubah port pada klien aplikasi Anda dan mulai ulang. Atau ubah port Cassandra dan mulai ulang kluster jika Anda memilih pendekatan tersebut. Proksi mulai meneruskan penulisan data ke endpoint target. Anda bisa mempelajari tentang pantauan dan metrik tersedia di alat proksi.
Jalankan muatan data riwayat
Untuk memuat data, buatlah catatan Scala di dalam akun Azure Databricks Anda. Ganti konfigurasi Cassandra sumber dan target Anda dengan informasi masuk terkait, dan ganti keyspace dan tabel sumber dan target. Tambahkan variabel lebih untuk tiap tabel sesuai kebutuhan ke contoh berikut, kemudian jalankan. Setelah aplikasi Anda mulai mengirimkan permintaan ke proksi dual-write, Anda siap untuk memindahkan data riwayat.
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
Catatan
Dalam sampel Scala sebelumnya, timestamp telah diatur ke waktu saat ini sebelum semua data dalam tabel sumber dibaca. Kemudian, writetime sedang diatur ke penandaan waktu dengan kondisi.backdated ini. Pendekatan ini memastikan bahwa rekaman yang ditulis dari beban data historis ke titik akhir target tidak dapat menimpa pembaruan yang masuk dengan stempel waktu selanjutnya dari proksi dual-write saat data historis sedang dibaca.
Penting
Jika Anda butuh mempertahankan penandaan waktu tertentu karena suatu alasan, Anda disarankan untuk melakukan pendekatan pemindahan data riwayat yang mempertahankan penandaan waktu, seperti contoh berikut ini. Jar dependensi dalam sampel juga berisi konektor Spark, sehingga Anda tidak perlu menginstal rakitan konektor Spark yang disebutkan dalam prasyarat sebelumnya. Menginstal keduanya di kluster Spark Anda menyebabkan konflik.
Validasi sumber dan target
Saat muatan data riwayat sudah lengkap, database Anda seharusnya sudah sinkron dan siap untuk dipindahkan langsung. Kami menyarankan agar Anda memvalidasi sumber dan target untuk memastikan kecocokan sebelum akhirnya beralih.
Catatan
Jika Anda menggunakan sampel migrator Cassandra yang disebutkan di bagian sebelumnya untuk mempertahankan writetime, Anda memiliki kemampuan untuk memvalidasi migrasi dengan membandingkan baris dalam sumber dan target berdasarkan toleransi tertentu.