عادةً ما يشير خطأ ترحيل قاعدة بيانات Kopano مباشرةً بعد ترقية إصدار MySQL أو MariaDB إلى عدم توافق التطبيق وقاعدة البيانات فيما كان يُعتبر ضمنيًا: حالة المخطط، الإعدادات الافتراضية للخادم، سلوك SQL، المصادقة، أو مسار الترقية نفسه. الهدف الأساسي ليس مجرد تشغيل التطبيق kopano-serverمرة واحدة، بل الوصول إلى حالة يكون فيها المخطط متسقًا، ويبدأ Kopano دون أخطاء ترقية قاعدة البيانات، ويستطيع المستخدمون فتح المتاجر، ويستمر تدفق البريد بعد إعادة التشغيل.
يركز هذا الدليل على الأدلة. تتضمن كل مرحلة مؤشر نجاح ونقطة توقف عندها عن تجربة نفس الحل وتغيير المسار. وثائق إدارة Kopano العامة أقدم من إصدارات MySQL وMariaDB الحالية، لذا لا تفترض أن كل إصدار حديث من قواعد البيانات مدعوم من جميع إصدارات Kopano القديمة. استخدم إصدار حزمة Kopano المحدد، ومُورّد قاعدة البيانات، وخطأ الخادم كدليل حاسم.
ابدأ بالنتيجة التي تحتاجها
قبل تغيير الإعدادات، حدد المقصود بكلمة "ثابت". عادةً ما تتضمن عملية الاستعادة السليمة جميع هذه العلامات:
kopano-serverيبدأ التشغيل ويستمر بعد إعادة تشغيل الخدمة.
- لم يعد سجل Kopano يُبلغ عن ترقية مخطط قاعدة البيانات أو فشل تنفيذ SQL.
- يمكن قراءة قاعدة البيانات وكتابتها بواسطة حساب Kopano المُكوّن.
- تظهر المتاجر والمستخدمون الحاليون، بدلاً من مخطط فارغ تم إنشاؤه حديثًا.
- تستأنف عمليات إرسال البريد وتسليمه بشكل طبيعي.
- إعادة التشغيل الثانية تُنتج نفس النتيجة الصحية.
إذا حققتَ العنصر الأول فقط، فاستمر في الاختبار. إن بدء التشغيل المؤقت بعد التغيير sql_mode، على سبيل المثال، لا يثبت صحة المخطط الأساسي.
1. أوقف برنامج Kopano للكتابة وقم بأخذ نسخة احتياطية قابلة للاستعادة من قاعدة البيانات
توصي وثائق ترقية Kopano بعمل نسخة احتياطية من قاعدة البيانات وملفات التكوين، وإيقاف الخدمات التي تستخدم قاعدة البيانات قبل بدء عملية الترقية. وتشير الوثائق تحديدًا إلى إيقاف الخدمات التي تستخدم قاعدة البيانات kopano-spooler، kopano-serverبالإضافة إلى المكونات الاختيارية قيد التشغيل. راجع وثائق ترقية Kopano Core .
sudo systemctl stop kopano-spooler
sudo systemctl stop kopano-server
mysqldump -u root -p --single-transaction kopano > /root/kopano-before-fix.sql
ls -lh /root/kopano-before-fix.sql
بالنسبة للأنظمة الكبيرة، احتفظ أيضًا بملفات قاعدة /etc/kopano/البيانات، ولاحظ موقع تخزين المرفقات، واتبع سياسة النسخ الاحتياطي لقاعدة البيانات الحالية. إذا كانت المرفقات مخزنة خارج MySQL، فإن نسخة SQL وحدها لا تُعد نسخة احتياطية كاملة لـ Kopano.
أوقف خدمات Kopano التي تكتب إلى قاعدة البيانات وتحقق من وجود نسخة احتياطية جديدة قبل تغيير المخطط أو إعدادات الخادم.
علامة النجاح: لديك نسخة احتياطية يمكن استعادتها إلى قاعدة بيانات منفصلة، وتعرف مكان تخزين المرفقات الخارجية. غيّر أسلوبك إذا: فشلت عملية النسخ الاحتياطي نفسها. أصلح تلف قاعدة البيانات، أو الصلاحيات، أو مساحة القرص، أو الاتصال قبل محاولة ترحيل مخطط Kopano.
2. سجل إصدار قاعدة البيانات بالضبط والإعدادات الافتراضية المتغيرة
يمكن لتحديث رئيسي لـ MySQL تغيير الإعدادات الافتراضية للخادم دون تعديل الجداول الموجودة. على سبيل المثال، غيّر MySQL 8.0 مجموعة الأحرف الافتراضية للخادم إلى 0، utf8mb4والترتيب الافتراضي إلى 0.7 utf8mb4_0900_ai_ci. كما غيّر إعدادات افتراضية أخرى، وأزال أو أوقف استخدام سلوكيات قديمة. توثّق Oracle هذه الاختلافات في قسم " التغييرات في MySQL 8.0" .
قم بتسجيل حالة الخادم الفعلية بدلاً من افتراض ما فعله تحديث الحزمة:
mysql -u root -p
SELECT VERSION();
SHOW VARIABLES LIKE 'sql_mode';
SHOW VARIABLES LIKE 'character_set_server';
SHOW VARIABLES LIKE 'collation_server';
سجل إصدار قاعدة البيانات والإعدادات الافتراضية التي يراها Kopano الآن؛ تساعد هذه القيم في تفسير حالات الفشل التي ظهرت فقط بعد ترقية قاعدة البيانات.
لا تُعطّل أوضاع SQL الصارمة فورًا. قد يكشف خطأ الوضع الصارم عن بيانات قديمة غير صالحة أو استعلامات SQL غير صالحة يجب تصحيحها. قد يؤدي تعطيل الوضع الصارم إلى إخفاء الأعراض مع ترك بيانات تفشل لاحقًا. أولًا، سجّل العبارة الفاشلة أو خطأ قاعدة البيانات من سجل Kopano.
3. اقرأ أول خطأ في استعلام SQL، وليس فقط فشل الخدمة النهائي.
غالبًا ما يُظهر Systemd فقط حالة kopano-serverالخروج. عادةً ما يكون السطر المفيد في وقت سابق في سجل النظام أو سجل Kopano. ابدأ بـ:
journalctl -u kopano-server -n 100 --no-pager
ثم صنّف العطل. الجدول التالي هو خريطة فرز عملية، وليس ادعاءً بأن سببًا واحدًا ينطبق على جميع عمليات التثبيت.
| تسجيل الأعراض | ما الذي يجب فحصه بعد ذلك؟ | لا تفعل ذلك أولاً |
| تم رفض الوصول / خطأ في إضافة المصادقة | بيانات اعتماد Kopano MySQL، ومنح المضيف، وطريقة المصادقة | قم بتغيير المخطط |
| عمود غير معروف / عمود مكرر / الجدول موجود بالفعل | ترحيل جزئي للمخطط، تعطلت الترقية السابقة | قم بإسقاط الجدول المتأثر |
| قيمة سلسلة غير صحيحة / خطأ في الترتيب | قاعدة البيانات، والجدول، ومجموعة الأحرف/الترتيب | قم بتحويل كل جدول بشكل أعمى |
| خطأ في الإعدادات الافتراضية / البيانات مقطوعة / الوضع الصارم | عمود الفشل المحدد والبيانات المخزنة | تعطيل الوضع الصارم على مستوى العالم |
| الفهرس طويل جدًا / خطأ في حجم الصف | تعريف الجدول، توسيع مجموعة الأحرف، تنسيق InnoDB | حذف الفهارس بدون نسخة احتياطية |
| يبدأ تشغيل الخادم ولكنه يُبلغ عن مهمة صيانة مطلوبة لقاعدة بيانات كوبانو | الأمر الفرعي المحدد kopano-dbadmالذي تم تسميته بواسطة إصدار Kopano الخاص بك | ابتكر أمر ترقية عام |
يؤكد سجل تغييرات Kopano أن بعض الإصدارات أدخلت تغييرات على المخطط تتطلب kopano-dbadmعمليات محددة. كما يسجل عيوب ترقية قواعد البيانات السابقة، بما في ذلك حالات الفشل المتعلقة بتعريفات جداول MySQL القديمة وترقيات utf8mb4. استخدم سجل تغييرات Kopano Core لمطابقة إجراء الصيانة مع إصدار Kopano الخاص بك.
4. قارن مخطط كوبانو الحالي مع الإعدادات الافتراضية الجديدة للخادم
تحقق من المخطط كما هو موجود؛ الإعدادات الافتراضية للخادم وحدها لا تخبرك بمدى قدم تعريف جداول Kopano.
SHOW CREATE DATABASE kopano;
SHOW TABLE STATUS FROM kopano;
قم بفحص تعريف قاعدة بيانات Kopano الحالية ومحركات التخزين مع إبقاء خطأ الترحيل الأصلي مرئيًا للمقارنة.
إذا تم إنشاء قاعدة البيانات في الأصل على إصدار أقدم من MySQL، فقد تحتفظ جداولها بمجموعات الأحرف القديمة حتى وإن كانت الكائنات المُنشأة حديثًا تستخدم افتراضيًا utf8mb4. يُشير MySQL صراحةً إلى أن الترقية من الإصدار 5.7 إلى 8.0 لا تُحوّل تلقائيًا كائنات قاعدة البيانات الموجودة إلى مجموعة الأحرف الافتراضية الجديدة. هذا التمييز مهم: فقد تفشل عملية الترحيل عند إنشاء عمود أو فهرس جديد بقيم افتراضية مختلفة عن الكائنات المجاورة.
أضافت Kopano دعم ترميز utf8mb4 في الإصدارات اللاحقة من Core، ووثّقت خطوة صيانة محددة لقواعد البيانات، kopano-dbadm usmpوهي ترقية قواعد البيانات الحالية لدعم ترميز Unicode ذي 4 بايت. لا تُنفّذ هذا الأمر لمجرد أن MySQL يستخدم utf8mb4 افتراضيًا؛ بل نفّذه فقط عندما تتطلب وثائق إصدار Kopano المُثبّت لديك أو مخرجات الخادم ذلك.
5. إذا تمت ترقية MariaDB، فأكمل ترقية جانب MariaDB أولاً.
إذا كانت قاعدة بياناتك الخلفية تستخدم MariaDB بدلاً من Oracle MySQL، فأكمل عملية ترقية خادم قاعدة البيانات قبل إلقاء اللوم على Kopano. تُوثّق MariaDB mariadb-upgradeأداةً لتحديث جداول النظام وفحص الجداول بعد تغييرات الإصدار الرئيسية. وتوصي وثائقها بعمل نسخة احتياطية من جميع قواعد البيانات أولاً. راجع مرجع ترقية MariaDB الرسمي .
هذا فرعٌ وليس أمرًا عامًا. لا تُنفّذه mariadb-upgradeعلى Oracle MySQL. وبالمثل، لا تُطبّق افتراضات MySQL 8.0 على خادم MariaDB لمجرد أن كلاهما يقبل mysqlبروتوكول العميل.
6. تحقق من أن حساب قاعدة بيانات كوبانو لا يزال يتمتع بالصلاحيات المطلوبة
ينص دليل إدارة Kopano على أن الخادم يحتاج إلى صلاحيات ALTER، بما في ذلك صلاحيات الوصول إلى قاعدة بيانات Kopano. يتم تكوين معلمات اتصال قاعدة البيانات من خلال الإعدادات المتعلقة بـ MySQL في ملف التكوين . راجع قسم " CREATEتكوين مكونات KCCREATE ROUTINE " .DELETEDROPINDEXINSERTLOCK TABLESSELECTUPDATE/etc/kopano/server.cfg
بعد ترقية إصدار MySQL، قد يقوم المسؤول بإعادة إنشاء المستخدمين، أو تغيير إضافات المصادقة، أو نقل مضيف قاعدة البيانات، أو استعادة الصلاحيات بشكل غير كامل. اختبر نفس اسم المضيف والحساب الذي يستخدمه Kopano. إذا فشلت المصادقة قبل تنفيذ أي استعلام SQL خاص بالترقية، فقم بإصلاح مشكلة الحساب أو الصلاحيات أولاً.
7. أصلح فقط الحالة التي أثبتها الخطأ
في هذه المرحلة، يجب أن يكون لديك فئة فشل محددة واحدة. قم بتطبيق أصغر تغيير يفسرها:
- تحديث جزئي لمخطط Kopano: اتبع تعليمات ترقية Kopano الخاصة بالإصدار أو
kopano-dbadmالتعليمات المحددة في الإصدار المُثبَّت. لا تقم أبدًا بحذف علامة الإصدار أو إضافة أعمدة يدويًا لمجرد تشغيل العبارة التالية.
- عدم تطابق مجموعة الأحرف أو الترتيب: حدد الجدول والعمود المتأثرين أولاً. خطط للتحويلات على نسخة مستعادة قبل إجراء أي تغييرات على بيئة الإنتاج، لأن تغييرات مجموعة الأحرف قد تؤثر على أحجام الفهارس وسلوك المقارنة.
- عدم تطابق جدول النظام في MariaDB: أكمل إجراء ترقية MariaDB الموثق، ثم أعد محاولة Kopano.
- الأذونات أو المصادقة: قم بتصحيح حساب قاعدة بيانات Kopano وتحقق من تسجيل الدخول من مضيف Kopano.
- تركيبة إصدار غير مدعومة: أوقف تجارب التكوين. استعد بيئة قاعدة البيانات قبل الترقية أو انتقل إلى تركيبة Kopano/قاعدة بيانات يدعمها المورّد أو مصدر الحزمة.
الحالة الأخيرة مهمة. دليل إدارة Kopano Core المتاح للعموم يعود إلى جيل أقدم من المنتج، بينما تستمر إصدارات MySQL وMariaDB الحالية في التطور. إذا لم تجد بيان دعم خاصًا بتوافق نظامك، فلا ينبغي تفسير عدم وجود توثيق على أنه دليل على التوافق.
8. ابدأ تشغيل Kopano وتحقق من صحة أكثر من حالة العملية
sudo systemctl start kopano-server
sudo systemctl start kopano-spooler
systemctl --no-pager --full status kopano-server
journalctl -u kopano-server -n 50 --no-pager
إن حالة الخدمة السليمة ضرورية ولكنها غير كافية؛ راجع سجل بدء التشغيل ثم تحقق من صحة مخازن المستخدمين وتدفق البريد.
بعد التأكد من استمرار عمل الخدمة، اختبرها باستخدام سلوك التطبيق الفعلي. افتح صندوق بريد واحد على الأقل، وتأكد من وجود المجلدات والرسائل القديمة، وأرسل رسالة بين حسابين محليين، وأرسل رسالة صادرة واحدة، وتأكد من عمل استقبال الرسائل الواردة. إذا كنت تستخدم بروتوكول IMAP أو ActiveSync أو الأرشفة أو مكونات الخوادم المتعددة أو تخزين المرفقات الخارجية، فاختبر هذه المسارات أيضًا.
متى يجب عليك تغيير أسلوبك؟
توقف عن تكرار تغييرات المخطط عند ظهور أي من هذه الشروط:
- يتغير خطأ SQL بعد كل تعديل يدوي، مما يشير إلى وجود مخطط تم ترحيله جزئيًا.
- قاعدة البيانات التي تم استعادتها قبل الترقية تعمل على إصدار قاعدة البيانات القديم ولكنها تفشل باستمرار على الإصدار الجديد.
- لا يمكنك التأكد من أن إصدار Kopano الخاص بك يدعم الإصدار الرئيسي المثبت من MySQL أو MariaDB.
- تشير عمليات فحص الجداول إلى وجود خلل بدلاً من عدم توافق المخطط العادي.
- يتطلب تحويل مجموعة الأحرف تغيير العديد من الجداول الكبيرة دون وجود آلية تراجع مختبرة.
في هذه الحالات، يكون المسار الأكثر أمانًا غالبًا هو إعادة إنشاء بيئة قاعدة البيانات السابقة، واستعادة نسخة احتياطية سليمة، والتخطيط لترقية تدريجية في نسخة طبق الأصل. تشير أوراكل إلى أن الرجوع من إصدار MySQL 8.0 إلى 5.7 غير مدعوم في الموقع؛ البديل المدعوم هو استعادة نسخة احتياطية تم إنشاؤها قبل الترقية. راجع ملاحظات إصدار MySQL 8.0 .
قائمة التحقق النهائية
- تم الاحتفاظ بنسخة احتياطية من قاعدة البيانات ونسخة احتياطية من إعدادات Kopano.
- يتم تسجيل الإصدار الدقيق لـ MySQL أو MariaDB.
- تم تحديد أول خطأ حقيقي في لغة SQL وشرحه.
- لم يتم تطبيق أي حل بديل واسع النطاق لوضع SQL أو مجموعة الأحرف بدون دليل.
- تتطابق صيانة مخطط Kopano المطلوبة مع إصدار Kopano المثبت.
kopano-serverينجو من إعادة التشغيل الثانية.
- صناديق البريد والمجلدات والرسائل الموجودة سليمة.
- نجحت اختبارات التسليم الواردة والصادرة والمحلية.
- تم اختبار المكونات الاختيارية المستخدمة في بيئتك.
تُحل مشكلة ترحيل قاعدة البيانات عندما يتطابق مخطط قاعدة البيانات وخادم قاعدة البيانات وإصدار Kopano مجددًا، وليس بمجرد اختفاء رسالة الخطأ. احتفظ بالأدلة التي أدت إلى الإصلاح، لأنها أيضًا المعلومات التي ستحتاجها للترقية التالية لقاعدة البيانات أو Kopano.