الترحيل إلى PostgreSQL مع تشغيل متوازٍ قبل التحويل النهائي

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

• الشيفرة المخزنة. لا توجد حزم (Packages) في PostgreSQL. ويقترح توثيقها استخدام المخططات (Schemas) لتجميع الدوال، والجداول المؤقتة لحفظ حالة الجلسة التي كانت متغيرات الحزم تحفظها. والشيفرة الإجرائية من أي قاعدة مصدر تُعاد كتابتها لـ PostgreSQL، وغالبًا بلغة PL/pgSQL.
• أنواع البيانات. ينصح توثيق PostgreSQL باستبدال varchar2 بـ varchar أو text، واستبدال number بـ numeric أو بنوع رقمي أنسب. وأنواع التاريخ والوقت تحتاج المراجعة نفسها.
• النصوص الفارغة. تعامل Oracle Database القيمة النصية التي طولها صفر على أنها null، أما PostgreSQL فلا، فتتغير نتائج المقارنات والقيود التي تعتمد على ذلك.
• حالة الأحرف في الأسماء. يحوّل PostgreSQL الأسماء غير المحاطة بعلامات اقتباس إلى أحرف صغيرة، فالشيفرة التي تخلط بين الأسماء المقتبسة وغير المقتبسة قد لا تجد جداولها.
• الأخطاء داخل الإجراءات. في PL/pgSQL، عند التقاط استثناء تُلغى كل تغييرات قاعدة البيانات منذ بداية تلك الكتلة. وشيفرة معالجة الأخطاء المنقولة سطرًا بسطر قد تفقد عملًا كانت تحتفظ به.
• الاستعلامات الديناميكية. يعمل EXECUTE بطريقة قريبة، لكن الأسماء والقيم يجب أن تُقتبس بالدالتين quote_ident وquote_literal، وإلا فلن يعمل الاستعلام بشكل موثوق.

لا شيء من هذا غريب، ولهذا يقرأ التقييم الشيفرة المخزنة واستعلامات التطبيق قبل أن يقدّر أحد أي مدة.

النمط واحد مهما كانت قاعدة البيانات التي تبدؤون منها:

1. التحميل الأولي. نسخ البيانات الحالية إلى PostgreSQL.
2. النسخ المستمر. نسخ كل تغيير من المصدر أولًا بأول ما دام النظامان يعملان.
3. التشغيل المتوازي. قاعدتا البيانات تعملان ومتطابقتان، للمدة التي يتطلبها التحقق ويحتاجها العمل. وتنتقل عمليات القراءة أولًا، بخطوات يمكن التراجع عنها.
4. التحويل النهائي. تنتقل عمليات الكتابة إلى PostgreSQL، ويبقى الرجوع ممكنًا حتى النقطة المتفق عليها.

يُنفَّذ التحويل النهائي مرة واحدة، ويُتمرَّن عليه أكثر من مرة، بما في ذلك التراجع.

قد ينتهي التقييم إلى أن الترحيل غير مناسب، ويقول ذلك كتابةً. فقاعدة البيانات العاملة التي تتحمل أحمالها أصل لا عبء، وقد يكون تحسين ما لديكم هو الخيار الأنسب. وحين يكون النظامان من مورّد واحد يوفر مسار ترحيل أصليًا مدعومًا، يكون ذلك المسار عادة أقل تكلفة من الترحيل بين أنظمة مختلفة، ولا يكون iblync الأداة المناسبة.

1. التقييم. عمل محدد النطاق يشمل أحمال العمل والشيفرة المخزنة واستعلامات التطبيقات وحجم البيانات ونافذة التوقف وإقامة البيانات. ونتيجته قرار مع مقارنة للتكلفة تتضمن خيار البقاء على الوضع الحالي.
2. الهيكل والشيفرة. تحويل الهيكل، وإعادة كتابة الشيفرة المخزنة، واختبارها على بيانات تشبه بيانات الإنتاج.
3. تعديلات التطبيقات. تقدير تعديلات الاستعلامات وبرامج الاتصال لكل خدمة والبدء بها مع فرق التطبيقات لديكم.
4. الجسر والتشغيل المتوازي. التحميل الأولي، والنسخ المستمر، والمقارنة خدمةً بعد خدمة.
5. تحويل نهائي بعد التمرين. التمرين على التحويل والتراجع، ثم التنفيذ مرة واحدة.
6. التثبيت. ضبط الأداء، وإثبات الاستعادة من النسخ الاحتياطية، وتمارين الانتقال عند التعطل، ثم التسليم لمديري قواعد البيانات لديكم أو تشغيل إنتركي لها من الرياض.

وبعد الانتقال، يمكن إدارة تغييرات الهيكل على PostgreSQL بالإصدارات وتمريرها عبر مسار نشر آلي، وهذا ما تغطيه ممارسة DevOps لقواعد البيانات لدى إنتركي.

روابط ذات صلةممارسة DevOps لقواعد البيانات

يُسعَّر كل مشروع على حدة بعد التقييم. وتحدد التكلفة عواملُ منها: مدى اختلاف الهيكل والشيفرة المخزنة عن PostgreSQL، وعدد الخدمات التي تتغير استعلاماتها، وحجم البيانات ومعدل تغيرها، ونافذة التوقف التي يقبلها العمل، ونموذج النشر، ومن يتولى تعديلات التطبيقات، والتشغيل بعد الإطلاق. ويُسعَّر iblync نفسه بعرض سعر بحسب الأنظمة المصدر والأنظمة الهدف وحجم البيانات.