ترحيل MySQL إلى PostgreSQL مع بقاء MySQL متزامنة حتى التحويل

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

الفرق التي تطلب منا نقل MySQL إلى PostgreSQL لديها في الغالب واحد من ثلاثة أسباب. الأول توحيد محرك قواعد البيانات في أنظمتها، فيشغّل فريق واحد كل القواعد وينسخها احتياطيًا ويراقبها بالطريقة نفسها. والثاني حاجة إلى ما يتقنه PostgreSQL، مثل الأنواع الصارمة وفهرسة JSON وإضافات البيانات الجغرافية. والثالث اختيار خدمة PostgreSQL مُدارة لا بد أن تلحق بها قواعد MySQL.

ويستحق الترحيل كلفته حين يكون المكسب مسمّى ويوجد من يشغّل PostgreSQL بعد ذلك، لا لحل مشكلة أداء يكفي لها ضبط MySQL. فإن كان هذا هو الجواب الصادق قلناه كتابةً. والمنهج العام لأي مصدر في صفحة الترحيل إلى PostgreSQL، أما هذه الصفحة فتخص المصدر MySQL تحديدًا.

روابط ذات صلةصفحة الترحيل إلى PostgreSQL

هذا هو الجزء الذي يفاجئ الفرق السعودية أكثر من غيره في نقل MySQL، لأنه يمس أسماء العملاء وعناوينهم والنصوص الحرة بالعربية.

• ترميز utf8 ليس دائمًا UTF-8 كاملًا. الترميز الذي تسميه MySQL باسم utf8 صيغة من ثلاثة بايتات لا تحفظ بعض الأحرف، مثل كثير من الرموز التعبيرية، أما utf8mb4 فهو الصيغة الكاملة. وترميز UTF8 في PostgreSQL كامل، لكن ما أسقطته MySQL من أحرف قد ضاع قبل الترحيل.
• نص عربي في عمود latin1. كانت بعض التطبيقات القديمة تكتب بايتات UTF-8 في أعمدة latin1، فيظهر النص سليمًا في التطبيق ومشوّهًا في كل مكان آخر. ويأخذ التقييم عيّنة من كل عمود نصي ليكشف ذلك، ويُعالج التحويل لكل عمود على حدة.
• البايتات غير الصالحة. يرفض PostgreSQL أي تسلسل بايتات لا يصح في ترميز القاعدة. فالتحميل الذي يفشل في صفوف قليلة يدلكم على مكان البيانات غير السليمة.
• حالة الأحرف والتشكيل. قواعد الترتيب الافتراضية في MySQL لا تميّز حالة الأحرف عادةً، فتكون 'Riyadh' و'RIYADH' متساويتين، أما PostgreSQL فيقارن النصوص حرفيًا افتراضيًا. فالمفاتيح الفريدة والبحث على النصوص تحتاج إلى قرار: فهرس على الأحرف الصغيرة، أو إضافة citext، أو قاعدة ترتيب لا تميّز حالة الأحرف.
• الأوضاع المتساهلة. حين تعمل MySQL دون الوضع الصارم قد تعدّل القيم الخارجة عن المدى أو غير الصالحة وتحفظها مع تحذير فقط. أما PostgreSQL فيرفضها بخطأ، فيكون الترحيل هو الموضع الذي تظهر فيه هذه القيم.

ويُعاد اختبار البحث في النصوص العربية التي كانت تعتمد على قواعد الترتيب في MySQL، على PostgreSQL وببياناتكم أنتم.

تحفظ معظم تطبيقات MySQL استعلاماتها في التطبيق لا في القاعدة. فالتغييرات صغيرة، لكنها موزعة على ملفات كثيرة:

• علامات الاقتباس. تصبح العلامة المائلة حول الأسماء (backtick) علامة اقتباس مزدوجة أو تُحذف. ويحوّل PostgreSQL الأسماء غير المقتبسة إلى أحرف صغيرة.
• الإدخال مع التحديث والمفاتيح. يصبح الشرط ON DUPLICATE KEY UPDATE في جملة INSERT هو ON CONFLICT DO UPDATE، وتحل RETURNING محل LAST_INSERT_ID().
• تقسيم النتائج والدوال. تصبح LIMIT 20, 10 هي LIMIT 10 OFFSET 20، وIFNULL هي COALESCE. وفي MySQL تعني || في الغالب «أو»، أما في PostgreSQL فتربط النصوص.
• GROUP BY. قد تسمح MySQL باختيار أعمدة غير مجمّعة ولا محسوبة بدالة تجميع، ويرفض PostgreSQL ذلك ما لم يعتمد العمود على المفتاح الأساسي المجمّع.
• القسمة. في MySQL يعطي 5 / 2 القيمة 2.5، وفي PostgreSQL تعطي قسمة عددين صحيحين القيمة 2. والتقارير المالية تستحق اختبارًا خاصًا.
• الإجراءات والمشغّلات والأحداث. تُعاد كتابة الإجراءات المخزنة بلغة PL/pgSQL، وتصبح المشغّلات دوال مشغّلات، وتحتاج المهام على مجدول الأحداث في MySQL إلى أداة جدولة جديدة.

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

iblync منصة إنتركي لترحيل البيانات ونسخها، وMySQL وPostgreSQL كلاهما في قائمة موصلاتها المنشورة. وله في هذا المشروع مهمة واحدة: نقل البيانات وإبقاء القاعدتين على اتفاق بينما يُثبَت الهيكل والاستعلامات والتطبيق.

• التحميل الأولي. تُنسخ البيانات الحالية إلى PostgreSQL مرة واحدة، مع تقييد المعدل حتى لا ينافس التحميل الإنتاج على MySQL. ويذكر موقع iblync أن الترحيل إذا انقطع يستأنف من حيث توقف.
• المزامنة المستمرة. كل تغيير يجري على MySQL بعد التحميل يُطبَّق على PostgreSQL بقواعد الأنواع والترميز نفسها، وإن تعذّر الوصول إلى PostgreSQL تنتظر التغييرات في طابور بدل أن تفشل. ويراجع التقييم إعدادات السجلات في MySQL، فهي التي تحدد طريقة قراءة التغييرات.
• الاتجاهان عند الحاجة. يدعم iblync المزامنة في الاتجاهين، فيمكن أن تعود التغييرات إلى MySQL مدة متفقًا عليها ليبقى التراجع ممكنًا.
• الإثبات. يذكر موقع iblync أن التحقق يعتمد على المجاميع الاختبارية (checksums) وعدد الصفوف. ونتفق على شروط النجاح لبياناتكم قبل التحويل.

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

روابط ذات صلةصفحة النسخ المتماثل الفوري

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

وقبل البدء، تمر قائمة قرارات الترحيل لدينا على الأسئلة التي تحدد هل يستحق الانتقال كلفته. وإن كانت بيئتكم تضم SQL Server أيضًا فصفحة ترحيل SQL Server إلى PostgreSQL تتناول ذلك المصدر.

روابط ذات صلةقائمة قرارات الترحيلترحيل SQL Server إلى PostgreSQL

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