نقل MySQL وMariaDB يحتاج اختبار توافق واتساق، خصوصاً إذا تغير المحرك أو الإصدار الرئيسي أثناء الانتقال. نجاح الاتصال أو ظهور الجداول لا يثبت أن الفرز والمصادقة والإجراءات المخزنة والتطبيق تعمل كما كانت. قبل شراء الوجهة، اطلب تجربة استعادة وتشغيل لاستعلامات وعمليات ممثلة، ثم خطة تسليم تحدد آخر كتابة على المصدر وكيف تحفظ التغييرات عند الرجوع.
اكتب زوج المصدر والوجهة بدقة
سجل اسم المحرك وإصداره الكامل ومحركات التخزين وحجم القاعدة وأكبر الجداول والخصائص الخاصة. انتقال MySQL إلى MySQL بإصدار مختلف لا يساوي انتقال MySQL إلى MariaDB، كما لا يفترض أن الطريق العكسي يدعم القيود نفسها. احصر الأدوات والتوسعات والموصلات ونظام التشغيل وملفات الإعداد المرتبطة بالتطبيق.
تعرض مصفوفة توافق MySQL وMariaDB فروقاً في المصادقة وJSON والإعدادات وغيرها. استخدمها نقطة بداية لتقييم الإصدارين الفعليين، ولا تختزل القرار في أن المحركين يقبلان بروتوكول اتصال متشابهاً أو أن لوحة الاستضافة توفر زر تبديل.
راجع عناصر التوافق التي تؤثر في البيانات
| العنصر | ما قد يختلف | اختبار لازم |
|---|---|---|
| الترميز وcollation | دعم الاسم وقواعد المقارنة والفرز | نص عربي ورموز وبحث وقيود فريدة |
| SQL mode | قبول القيم والاستعلامات والتواريخ | عمليات التطبيق والتقارير المهمة |
| JSON ودواله وفهارسه | التخزين والخصائص وخطة التنفيذ | نتائج الاستعلام وأداؤه |
| المصادقة والموصل | الإضافات المدعومة وطريقة التفاوض | دخول التطبيق بحسابه الفعلي |
| إجراءات وviews وtriggers وevents | الصياغة والمالك والصلاحيات | وجودها وتنفيذ وظائفها الصحيحة |
| النسخ المتماثل | صيغة السجل وGTID والاتجاه المدعوم | نسخ تغييرات ممثلة دون أخطاء |
لا تبدل اسم collation غير معروف باسم آخر لمجرد إكمال الاستيراد. قد يتغير معنى التساوي والترتيب، فتظهر مشكلة في بحث عربي أو قيد يمنع التكرار. حدد السلوك المطلوب واختبره ببيانات ممثلة، مع حفظ النص الأصلي وتجنب تحويلات ترميز متكررة يصعب عكسها.
اختر تصديراً منطقياً أو نسخة فيزيائية مدعومة
التصدير المنطقي ينقل تعريفات وبيانات قابلة للمراجعة، لكنه قد يستغرق وقتاً في التحميل وبناء الفهارس ويحتاج تكييفاً مع الوجهة. النسخ الفيزيائي قد يناسب قواعد كبيرة ضمن شروط توافق دقيقة، لكنه لا يجعل ملفات MySQL وMariaDB قابلة للتبادل بين جميع الإصدارات. حدد الأداة وإصدارها وطريقة إعداد النسخة قبل الاستعادة.
توضح وثائق MariaDB Backup أهمية توافق نسخة الأداة ومرحلة prepare قبل الاستعادة. لا تختبر فوق دليل بيانات الإنتاج أو تستهلك النسخة الوحيدة القابلة للرجوع. جهز وجهة معزولة ومساحة عمل تكفي البيانات والسجلات والنسخ المؤقتة.
حدد كيف ستحصل على لقطة متسقة
راجع محركات الجداول وخيارات الأداة والمعاملات وتغيرات البنية أثناء النسخ. قد يناسب single-transaction جداول InnoDB وفق شروطه، لكنه لا يقدم الاتساق نفسه لجداول غير معاملاتية. كما أن عمليات تغيير البنية خلال التصدير تحتاج تنسيقاً؛ وجود ملف SQL كبير لا يثبت أنه يمثل حالة تجارية متسقة.
دوّن نقطة البداية والكتابة التي حدثت بعدها، وحدد إن كانت الخطة ستستخدم منع كتابة نهائياً أو نسخ تغييرات مدعوماً. تشمل البيانات المتغيرة مهام النظام والتطبيقات المتكاملة، لا مستخدمي واجهة الموقع فقط. اختبار العدد الإجمالي للصفوف مفيد، لكن بعض التعديلات لا تغير العدد، ولذلك يحتاج التحقق أكثر من مقياس واحد.
افحص الحسابات والصلاحيات والكائنات التابعة
لا تنقل جداول النظام والحسابات حرفياً بين محركات أو إصدارات غير متوافقة. جهز حسابات التطبيق بصلاحيات محددة وطريقة مصادقة يدعمها الموصل الحالي أو المحدث. واختبر الاتصال عبر TLS من سيرفر التطبيق الجديد وفق الاسم والشهادة والسياسة، دون خفض الحماية لتجاوز رسالة عدم توافق.
راجع DEFINER وملكية الكائنات وأذونات الإجراءات والأحداث المجدولة. قد تنجح استعادة view لكنها تفشل عند الاستخدام بسبب حساب غير موجود أو صلاحية مختلفة. راجع أيضاً أن مجدول الأحداث لا يشغل مهمة حقيقية مرتين أثناء التجربة أو التعايش، واحتفظ بالتعريفات الحساسة في ملفات مقيدة الوصول.
راجع النسخ المتماثل حسب الاتجاه والإصدار
توضح وثائق توافق replication بين MariaDB وMySQL أن الدعم يعتمد على عوامل منها الإصدار والاتجاه والخصائص. صيغ GTID مختلفة بين المشروعين، لذلك لا تنقل إعدادها كما هو أو تفترض وجود مزامنة تلقائية متبادلة.
اختبر النسخ الأولي ثم التحديث والحذف والأنواع المستخدمة، وراقب التأخر والأخطاء واحتفاظ binary logs والمساحة. قرب التأخر من الصفر لا يثبت شمول كل جدول أو كائن. عند التسليم، امنع كتابة المصدر وفق الخطة، وانتظر آخر تغييرات مطلوبة وتحقق منها قبل توجيه التطبيق وفتح الكتابة الجديدة.
اختبر التطبيق ونتائجه بعد الاستعادة
توصي وثائق MySQL لفحوص ما قبل الترقية بإجراءات جاهزية وأداة فحص للمسارات المدعومة. هذه تساعد كشف مشكلات معروفة، لكنها لا تختبر منطق تطبيقك أو تثبت توافق انتقال إلى محرك آخر. أضف عمليات أعمال حقيقية المعنى داخل بيئة اختبار.
في مثال افتراضي، متجر يستعيد الجداول بنجاح ثم تتغير نتائج فرز المنتجات أو يفشل حساب التطبيق بالمصادقة الجديدة. وفي نظام مالي، قد يعيد تقرير النتيجة نفسها بزمن أكبر بسبب خطة مختلفة. قارن صحة النتائج والأداء والأخطاء، وراجع الإحصاءات والفهارس وفق المحرك بعد النقل.
اربط التحويل بخطة رجوع تحمي الكتابات الجديدة
حدد كيف ستغلق تجمعات الاتصال القديمة وتوجه التطبيق والعمال والمجدول إلى الوجهة. أبق المصدر تحت ضوابط تمنع كتابة متعارضة أو مهام مزدوجة. وبعد تشغيل الوجهة، راقب أخطاء الاستعلام والاتصال والمهام ونتائج العمل، مع مسؤول واضح لاتخاذ قرار استمرار أو رجوع.
يساعد دليل نقل الاستضافة على تنسيق التطبيق وDNS، ويكمل مقال أخطاء النسخ الاحتياطي التحقق من الاستعادة. الرجوع بعد بيانات جديدة يحتاج نقلها أو مصالحتها وفق تصميم مجرب؛ لا تستبدل الواقع بنسخة سابقة فتفقد عمليات صحيحة.
أسئلة شائعة عن نقل MySQL وMariaDB
هل MariaDB بديل مطابق لكل إصدار MySQL؟
لا. راجع زوج الإصدارات والخصائص والموصلات المستخدمة، واختبر التطبيق. التوافق العام لا يضمن تطابق كل صيغة تخزين أو إعداد.
هل أصلح خطأ collation باستبدال اسمه في الملف؟
بعد تحليل واختبار فقط؛ تغيير قواعد المقارنة قد يؤثر في البيانات والقيود والنتائج. احتفظ بالنسخة الأصلية ووثق التحويل المطلوب.
متى أحتاج ترقية موارد القاعدة أثناء النقل؟
إذا أثبت اختبار الاستعادة والتشغيل أن السعة أو النافذة لا تكفي بعد الضبط. افصل هذه الحاجة عن عدم توافق المحرك أو الحسابات.
اطلب نقلاً مع اختبار توافق موثق
أرسل المحركين والإصدارين والحجم ومحركات الجداول والخصائص الخاصة عبر طلب عرض نقل قاعدة البيانات. اطلب ضمن استضافة MySQL وقواعد البيانات تجربة استعادة وفحص ترميز وصلاحيات ونتائج تطبيق، مع نافذة تحويل وخطة رجوع قبل اعتماد النقل.