نقل قاعدة البيانات العلائقية إلى بحيرة بيانات S3 عبر AWS DMS، الجزء الأول

خدمة ترحيل قواعد البيانات من AWS هي خدمة سحابية تقوم بترحيل قواعد البيانات العلائقية، قواعد بيانات NoSQL، مستودعات البيانات، وجميع أنواع تخزين البيانات الأخرى إلى سحابة AWS أو بين السحابة والإعدادات المحلية بكفاءة وأمان. تدعم DMS عدة أنواع من قواعد البيانات المصدر والهدف مثل Oracle، MS SQL Server، MySQL، Postgres SQL، Amazon Aurora، AWS RDS، Redshift، و S3، إلخ.

الملاحظات أثناء ترحيل البيانات

عملنا على تصميم وإنشاء بحيرة بيانات S3 من AWS ومستودع بيانات في AWS Redshift مع مصادر البيانات من الإعدادات المحلية لـ Oracle، MS SQL Server، MySQL، Postgres SQL، و MongoDB لقواعد البيانات العلائقية. استخدمنا AWS DMS للتحميل الكامل الأولي ونقل البيانات التزايدية اليومية من هذه المصادر إلى AWS S3.

من خلال هذه السلسلة من المشاركات، أريد أن أشرح التحديات المختلفة التي واجهناها أثناء ترحيل البيانات الفعلي مع قواعد البيانات العلائقية المختلفة.

1. تاريخ التعديل لم يتم تعبئته بشكل صحيح في المصدر

تستخدم AWS DMS للتحميل الكامل والتقاط بيانات التغيير من قواعد البيانات المصدر. تقوم AWS DMS بالتقاط السجلات المتغيرة بناءً على سجلات المعاملات، ولكن عمود تاريخ التعديل الذي يتم تحديثه بشكل صحيح يمكن أن يساعد في تطبيق منطق إزالة التكرار، واستخراج أحدث سجل معدل لصف معين في الهدف في S3.

في حالة عدم توفر بيانات معدلة لجدول معين أو عدم تحديثها بشكل صحيح، توفر AWS DMS خيار قواعد التحويل لإضافة عمود جديد أثناء استخراج البيانات من قاعدة البيانات المصدر. هنا، AR_H_CHANGE_SEQ يساعد الرأس في إضافة عمود جديد بالقيمة كرقم متزايد فريد من قاعدة البيانات المصدر، والذي يتكون من طابع زمني ورقم متزايد تلقائيًا.

مثال الشيفرة أدناه يضيف عمودًا جديدًا باسم DMS_CHANGE_SEQ إلى الهدف، والذي يحتوي على رقم متزايد فريد من المصدر. هذا رقم فريد مكون من 35 رقمًا، حيث تتكون الـ 16 رقمًا الأولى من الطابع الزمني و19 رقمًا التالية من رقم معرف السجل المتزايد بواسطة قاعدة البيانات.

{

    "rule-type": "transformation",

    "rule-id": "2",

    "rule-name": "2",

    "rule-target": "column",

    "object-locator": {

        "schema-name": "%",

        "table-name": "%"

    },

    "rule-action": "add-column",

    "value": "DMS_CHANGE_SEQ",

    "expression": "$AR_H_CHANGE_SEQ",

    "data-type": {

        "type": "string",

        "length": 100

    }

}

2. تفعيل التسجيل التكميلي لأوراكل كمصدر

بالنسبة لأوراكل كمصدر، لالتقاط التغييرات الجارية، يحتاج AWS DMS إلى تفعيل الحد الأدنى من التسجيل التكميلي على قاعدة البيانات المصدر. وفقًا لذلك، سيتضمن هذا معلومات إضافية وأعمدة في سجلات التكرار لتحديد التغييرات في المصدر.

يمكن تفعيل التسجيل التكميلي للمفاتيح الرئيسية والفريدة، ومجموعات من الأعمدة، أو لجميع الأعمدة. يلتقط التسجيل التكميلي لجميع الأعمدة جميع الأعمدة للجدول في قاعدة البيانات المصدر ويساعد على كتابة سجلات كاملة في طبقة AWS S3 المستهدفة.

سوف يؤدي تسجيل جميع الأعمدة بشكل إضافي إلى زيادة حجم سجلات إعادة التشغيل، حيث يتم تسجيل جميع الأعمدة الخاصة بالجدول في السجلات. يحتاج المرء إلى تكوين سجلات إعادة التشغيل والأرشفة وفقًا لذلك لأخذ المعلومات الإضافية في الاعتبار.

3. عرض النطاق الترددي الشبكي بين قواعد البيانات المصدر والهدف

عملت التحميل الكامل الأول من المصادر المحلية لـ Oracle و MS SQL Server، إلخ، بشكل جيد، وتغيرت أيضًا عملية التقاط البيانات لمعظم الوقت.

كان هناك عدد معتدل من المعاملات في معظم أوقات اليوم في شهر معين، باستثناء عملية نهاية يوم العمل، يوميًا، بعد منتصف الليل، وأنشطة نهاية الشهر. لوحظ أن مهام ترحيل DMS كانت غير متزامنة أو فشلت خلال هذا الوقت.

راجعنا مقاييس المصدر والهدف ونسخة التكرار في السجلات ووجدنا الملاحظات التالية:

• CDCLatencySource – الفجوة، بالثواني، بين آخر حدث تم التقاطه من نقطة نهاية المصدر والطابع الزمني الحالي لنظام AWS DMS.
• CDCIncomingchanges – العدد الإجمالي لفعاليات التغيير في نقطة زمنية معينة التي تنتظر أن تُطبق على الهدف. هذا يزيد من صفر إلى آلاف خلال أنشطة التسوية في الصباح الباكر.
• CDCLatencySource – الفترة الزمنية، بوحدات الثواني، بين آخر حدث تم التقاطه من نقطة نهاية المصدر والطابع الزمني الحالي لنظام AWS DMS. هذه الفترة تزيد من صفر إلى بضعة آلاف تصل إلى 10-12K ثانية خلال أنشطة التسوية اليومية بعد منتصف الليل. كانت هذه القيمة تصل إلى 40K خلال أنشطة نهاية الشهر.

عند تحليل السجلات بشكل أعمق ومراجعة مقاييس أخرى، لاحظنا أن:

مقياس AWS DMS NetworkReceiveThroughput يهدف إلى فهم حركة المرور الواردة على مثيل النسخ الاحتياطي DMS لكل من قاعدة بيانات العميل وحركة مرور DMS. تساعد هذه المقاييس في فهم المشكلات المتعلقة بالشبكة، إن وجدت، بين قاعدة البيانات المصدر ومثيل النسخ الاحتياطي DMS.

لوحظ أن معدل استلام الشبكة كان يصل إلى 30MB/s، أي 250Mb/s، بسبب اتصال VPN بين المصدر وAWS، والذي كان أيضًا مشتركًا لتطبيقات أخرى.

الاستنتاج النهائي لهذه المشكلة هو أن الاتصال بين قواعد البيانات المصدر والهدف حاسم لنجاح ترحيل البيانات. يجب التأكد من توفير عرض نطاق كافٍ بين قواعد البيانات المصدر الموجودة في الموقع أو في سحابة أخرى وبيئة AWS قبل بدء ترحيل البيانات الفعلي.

1. يمكن أن يوفر نفق VPN مثل AWS Site-to-Site VPN أو Oracle Cloud Infrastructure (OCI) Site-to-Site VPN (Oracle AWS) معدل نقل يصل إلى 1.25 Gbps. سيكون هذا كافيًا لترحيل الجداول الصغيرة أو الجداول ذات حركة مرور DML الأقل.
2. بالنسبة لعمليات نقل البيانات الكبيرة مع معاملات ثقيلة في الثانية على الجداول، يجب أن تفكر في AWS Direct Connect. إنه يوفر خيار إنشاء اتصال خاص مخصص بعرض نطاق 1 جيجابت في الثانية، 10 جيجابت في الثانية، وما إلى ذلك.

الخاتمة

هذا هو الجزء الأول من السلسلة المتعددة الأجزاء حول تحديات نقل قواعد البيانات العلائقية باستخدام AWS DMS والحلول المنفذة لها. معظم هذه التحديات المذكورة في هذه السلسلة قد تحدث أثناء عملية نقل قاعدة البيانات ويمكن الإشارة إلى هذه الحلول.