ملاحظة
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تسجيل الدخول أو تغيير الدلائل.
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تغيير الدلائل.
حيثما أمكن، نوصي باستخدام إمكانية Apache Cassandra الأصلية لترحيل البيانات من نظام المجموعة الحالي إلى مثيل Azure المدار ل Apache Cassandra عن طريق تكوين مجموعة مختلطة. تستخدم هذه الإمكانية بروتوكول التناقل الخاص بـ Apache Cassandra لنسخ البيانات من مركز بيانات المصدر الخاص بك إلى مركز بيانات المثيل الجديد المُدار بطريقة سلسلة.
قد تكون هناك بعض السيناريوهات التي لا يكون فيها إصدار قاعدة البيانات المصدر متوافقا، أو يكون إعداد نظام المجموعة المختلط غير ممكن. يصف هذا البرنامج التعليمي كيفية ترحيل البيانات إلى Azure Managed Instance لـ Apache Cassandra بطريقة مباشرة باستخدام وكيل الكتابة المزدوجة وApache Spark. يتم استخدام وكيل dual-write لالتقاط التغييرات الحية، بينما يتم نسخ البيانات التاريخية بكميات كبيرة باستخدام Apache Spark. مزايا هذا النهج هي:
- الحد الأدنى من تغييرات التطبيق. يمكن أن يقبل الوكيل الاتصالات من التعليمات البرمجية للتطبيق الخاص بك مع تغييرات تكوين قليلة أو معدومة. يقوم بتوجيه جميع الطلبات إلى قاعدة البيانات المصدر الخاصة بك وتوجيه عمليات الكتابة بشكل غير متزامن إلى هدف ثانوي.
- تبعية بروتوكول تحويل العميل. نظرا لأن هذا الأسلوب لا يعتمد على الموارد الخلفية أو البروتوكولات الداخلية، يمكن استخدامه مع أي نظام Cassandra المصدر أو الهدف الذي ينفذ بروتوكول Apache Cassandra السلكي.
الصورة التالية توضح النهج.
المتطلبات الأساسية
تكوين إعدادات تشعيل الخدمة لـ Azure Managed Instance لنظام المجموعة Apache Cassandra باستخدام مدخل Azure أو Azure CLI. تأكد من أنه يمكنك توصيل مجموعتك بـ CQLSH.
قم بتكوين إعدادات تشغيل الخدمة لحساب Azure Databricks داخل شبكة Managed Cassandra الظاهرية. تأكد من أن الحساب لديه وصول الشبكة إلى نظام مجموعة Cassandra المصدر الخاص بك. ينشئ هذا المثال مجموعة Spark في هذا الحساب لتحميل البيانات التاريخية.
تأكد من أنك قمت بالفعل بترحيل مخطط مساحة المفاتيح/الجدول من قاعدة بيانات Cassandra المصدر إلى قاعدة بيانات المثيل المدار Cassandra الهدف.
تكوين إعدادات تشغيل الخدمة بنظام مجموعة Spark
نوصي بتحديد الإصدار 7.5 من وقت تشغيل Azure Databricks، والذي يدعم Spark 3.0.
إضافة تبعيات Spark
تحتاج إلى إضافة مكتبة Apache Spark Cassandra Connector إلى مجموعتك للاتصال بأي نقاط نهاية متوافقة مع بروتوكول سلكي Apache Cassandra. في نظام المجموعة، حدد Libraries>Install New>Maven ثم أضف com.datastax.spark:spark-cassandra-connector-assembly_2.12:3.0.0 إحداثيات Maven.
هام
إذا كان لديك متطلب للاحتفاظ بـ Apache Cassandra writetime لكل صف أثناء الترحيل، فإننا نوصي باستخدام هذه العينة. تحتوي جرة التبعية في هذه العينة أيضا على موصل Spark، لذا قم بتثبيت هذا الإصدار بدلا من تجميع الموصل.
هذه العينة مفيدة أيضاً إذا كنت تريد إجراء تحقق من مقارنة الصفوف بين المصدر والهدف بعد اكتمال تحميل البيانات التاريخية. راجع تشغيل تحميل البيانات التاريخيةوالتحقق من صحة المصدر والهدف.
حدد Install، ثم أعد تشغيل نظام المجموعة عند اكتمال التثبيت.
إشعار
تأكد من إعادة تشغيل نظام مجموعة Azure Databricks بعد تثبيت مكتبة موصل Cassandra.
تثبيت وكيل الكتابة المزدوجة
للحصول على الأداء الأمثل أثناء الكتابة المزدوجة، نوصي بتثبيت الوكيل على جميع العقد في مجموعة Cassandra المصدر.
#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
بدء تشغيل وكيل الكتابة المزدوجة
نوصي بتثبيت الوكيل على كافة العقد في نظام مجموعة Cassandra المصدر لديك. على الأقل، قم بتشغيل الأمر التالي لبدء تشغيل الوكيل على كل عقدة. استبدل <target-server> بعنوان IP أو عنوان ملقم من إحدى العقد في نظام المجموعة الهدف. استبدل <path to JKS file> بمسار إلى ملف jks محلي، واستبدل <keystore 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>
يفترض من خلال بدء تشغيل الوكيل بهذه الطريقة بأن ما يلي صحيح:
- تحتوي نقاط النهاية المصدر والهدف على نفس اسم المستخدم وكلمة المرور.
- تنفذ نقاط النهاية المصدر والهدف طبقة مآخذ التوصيل الآمنة (SSL).
إذا لم تتمكن نقاط النهاية المصدر والهدف لديك من استيفاء هذه المعايير، فقم بقراءة المزيد من خيارات التكوين.
تكوين SSL
بالنسبة إلى SSL، يمكنك إما تنفيذ مخزن مفاتيح موجود، على سبيل المثال، المخزن الذي يستخدمه نظام المجموعة المصدر، أو إنشاء شهادة موقعة ذاتيا باستخدام keytool:
keytool -genkey -keyalg RSA -alias selfsigned -keystore keystore.jks -storepass password -validity 360 -keysize 2048
يمكنك أيضًا تعطيل طبقة مأخذ التوصيل الآمنة لنقاط النهاية المصدر أو الهدف إذا لم يتم تطبيق طبقة مأخذ التوصيل الآمنة. استخدم العلامات --disable-source-tls أو --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
إشعار
تأكد من أن تطبيق العميل يستخدم نفس مخزن المفاتيح وكلمة المرور مثل تلك المستخدمة لوكيل الكتابة المزدوجة عند إنشاء اتصالات SSL بقاعدة البيانات التي تستخدم الوكيل.
تكوين بيانات الاعتماد والمنفذ
بشكل افتراضي، يتم تمرير بيانات اعتماد المصدر من تطبيق العميل الخاص بك. يستخدم الوكيل بيانات الاعتماد لإجراء اتصالات إلى نظامي المجموعات المصدر والهدف. كما ذكر سابقًا، تفترض هذه العملية أن بيانات اعتماد المصدر والهدف هي نفسها. إذا لزم الأمر، يمكنك تحديد اسم مستخدم وكلمة مرور مختلفين لنقطة النهاية Cassandra الهدف بشكل منفصل عند بدء تشغيل الوكيل:
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>
منافذ المصدر والهدف الافتراضية، عند عدم تحديدها، هي 9042. إذا كان الهدف أو نقطة النهاية Cassandra المصدر يعمل على منفذ مختلف، يمكنك استخدام --source-port أو --target-port لتحديد رقم منفذ مختلف:
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>
نشر الوكيل عن بُعد
قد تكون هناك ظروف لا تريد فيها تثبيت الوكيل على عقد نظام المجموعة نفسها. تريد تثبيته على جهاز منفصل. في هذا السيناريو، حدد عنوان IP ل <source-server>:
java -jar target/cassandra-proxy-1.0-SNAPSHOT-fat.jar <source-server> <destination-server>
تحذير
قد ترغب في تشغيل الوكيل عن بعد على جهاز منفصل بدلا من تشغيله على جميع العقد في مجموعة Apache Cassandra المصدر. إذا كان الأمر كذلك، نوصي بنشر الوكيل على نفس عدد الأجهزة التي لديك عقد في نظام المجموعة الخاص بك. إعداد استبدال لعناوين IP الخاصة بهم في system.peers. استخدم هذا التكوين في الوكيل. إذا لم تستخدم هذا الأسلوب، فقد يؤثر ذلك على الأداء أثناء حدوث الترحيل المباشر، لأن برنامج تشغيل العميل لا يمكنه فتح الاتصالات بجميع العقد في نظام المجموعة.
السماح بتغييرات رمز التطبيق صفر
بشكل افتراضي، يستمع الوكيل على المنفذ 29042. يجب تغيير التعليمات البرمجية للتطبيق للإشارة إلى هذا المنفذ. بدلا من ذلك، يمكنك تغيير المنفذ الذي يستمع إليه الوكيل. قد تستخدم هذا الأسلوب إذا كنت تريد إزالة تغييرات التعليمات البرمجية على مستوى التطبيق من خلال:
- وجود خادم Cassandra المصدر مشغل على منفذ مختلف.
- وجود وكيل مشغل على منفذ Cassandra القياسي 9042.
java -jar target/cassandra-proxy-1.0-SNAPSHOT-fat.jar source-server destination-server --proxy-port 9042
إشعار
لا يتطلب تثبيت الوكيل على عقد نظام المجموعة إعادة تشغيل العقد. إذا كان لديك العديد من عملاء التطبيق وتفضل تشغيل الوكيل على منفذ Cassandra القياسي 9042 لإزالة أي تغييرات في التعليمات البرمجية على مستوى التطبيق، فقم بتغيير المنفذ الافتراضي Apache Cassandra. ثم تحتاج إلى إعادة تشغيل العقد في نظام المجموعة الخاص بك وتكوين المنفذ المصدر ليكون المنفذ الجديد الذي قمت بتعريفه من أجل نظام المجموعة Cassandra المصدر.
في المثال التالي، نقوم بتغيير نظام المجموعة Cassandra المصدر للتشغيل على المنفذ 3074 ثم نبدأ نظام المجموعة على المنفذ 9042:
java -jar target/cassandra-proxy-1.0-SNAPSHOT-fat.jar source-server destination-server --proxy-port 9042 --source-port 3074
فرض البروتوكولات
لدى الوكيل وظائف لفرض البروتوكولات، والتي قد تكون ضرورية إذا كانت نقطة النهاية المصدر أكثر تقدمًا من الهدف أو غير معتمدة. في هذه الحالة، يمكنك تحديد --protocol-version و--cql-version لفرض البروتوكول للامتثال للهدف:
java -jar target/cassandra-proxy-1.0-SNAPSHOT-fat.jar source-server destination-server --protocol-version 4 --cql-version 3.11
بعد تشغيل وكيل الكتابة المزدوجة، قم بتغيير المنفذ على عميل التطبيق وإعادة التشغيل. أو قم بتغيير منفذ Cassandra ثم أعد تشغيل نظام المجموعة إذا اخترت هذا النهج. يبدأ الوكيل في إعادة توجيه الكتابة إلى نقطة النهاية الهدف. يمكنك التعرف على المراقبة والمقاييسالمتوفرة في أداة الوكيل.
تشغيل تحميل البيانات التاريخية
لتحميل البيانات، قم بإنشاء دفتر ملاحظات Scala في حساب Azure Databricks. استبدل المصدر والهدف تكوينات Cassandra ببيانات الاعتماد المقابلة، واستبدل مسافات المفاتيح والجداول المصدر والهدف. أضف المزيد من المتغيرات لكل جدول كما هو مطلوب إلى النموذج التالي ثم قم بالتشغيل. بعد أن يبدأ التطبيق الخاص بك بإرسال الطلبات إلى وكيل الكتابة المزدوجة، ستكون على استعداد لترحيل البيانات التاريخية.
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
إشعار
في نموذج Scala السابق، timestamp يتم تعيين إلى الوقت الحالي قبل قراءة جميع البيانات في الجدول المصدر. ثم، يتم تعيين writetime إلى هذا الطابع الزمني القديم. يضمن هذا الأسلوب أن السجلات المكتوبة من تحميل البيانات التاريخية إلى نقطة النهاية الهدف لا يمكنها الكتابة فوق التحديثات التي تأتي مع طابع زمني لاحق من وكيل الكتابة المزدوجة أثناء قراءة البيانات التاريخية.
هام
إذا كنت بحاجة إلى الاحتفاظ بطوابع زمنية دقيقة لأي سبب من الأسباب، يجب اتباع نهج ترحيل البيانات التاريخية التي تحافظ على الطوابع الزمنية، مثل هذه العينة. تحتوي جرة التبعية في العينة أيضا على موصل Spark، لذلك لا تحتاج إلى تثبيت تجميع موصل Spark المذكور في المتطلبات الأساسية السابقة. يؤدي تثبيت كليهما في نظام مجموعة Spark إلى حدوث تعارضات.
تحقق من المصدر والهدف
بعد اكتمال تحميل البيانات التاريخية، يجب أن تكون قواعد البيانات الخاصة بك متزامنة وجاهزة للتنفيذ. نوصي بالتحقق من صحة المصدر والهدف للتأكد من تطابقهما قبل التقليص أخيرا.
إشعار
إذا استخدمت عينة مرحل Cassandra المذكورة في الأقسام السابقة للحفاظ على writetime، فلديك القدرة على التحقق من صحة الترحيل عن طريق مقارنة الصفوف في المصدر والهدف استنادا إلى تفاوتات معينة.