إذًا، أحاول ترحيل موقع عن طريق استعادة نسخة احتياطية من عملية نشر موجودة. أحصل على فشل الاستعادة بسبب عدم تطابق المخطط (المصدر أحدث من الهدف).
الآن أراجع نقطة النهاية admin/plugins لكلا عمليتي النشر، فهما متطابقتان بالنسبة لتلك المدرجة، وحالتها، وإصدارها، لذا أنا في حيرة من أمري بعض الشيء. لقد حاولت أيضًا إعادة جميع السمات والمكونات مرة أخرى فقط في حالة عدم حدوث تغيير. كلا الموقعين عند التطبيق 3.1.3، لذا لا يبدو أن هذا هو السبب الجذري في هذه الحالة.
أفترض أنه تم تثبيت إضافة على الموقع ثم تم إعادة نشر المثيل وتم الحفاظ على قاعدة البيانات دون تثبيت هذه الإضافة، ولكن هذا مجرد تخمين. هل هناك طريقة حتمية بالنظر إلى مثيل أو قاعدة بيانات يمكنني من خلالها معرفة ما ساهم في انحراف المخطط؟ وهل هناك طريقة لـ “تخفيض الإصدار” أو هل الطريقة الوحيدة هي جعل الموقع الهدف مطابقًا أو مجموعة شاملة؟
لا أعتقد ذلك، ولكنها بيئة تطوير لذا كل شيء ممكن على ما أعتقد.
هل هناك أي شيء تعرفه في جدول schema_migrations (أو الكود المستنسخ للحاوية) يمكنني التحقق منه يدويًا وربط إصدار المخطط بأي تغيير؟
إعادة تسمية الملف يمكن أن تسمح بتحميل الأشياء عبر الواجهة الرسومية، لكنني كنت أستخدم merger الذي يمنع بناءً على max(schema_migrations) وأنا حقًا أحاول تجنب تعديل الأشياء كثيرًا.
بعض هذا يسبق أي مهمة تشغيلية حيث قد تظهر عدم تطابقات إصدارات الترحيل. فهم أفضل لكيفية تتبع إصدار الترحيل إلى التغييرات حتى عندما يظهر هذا مرة أخرى، يمكنني على أمل اكتشاف دليل تشغيل للمصالحة.
نعم، يمكنني رؤية أقصى قيمة لـ schema_migration (حتى بمجرد النظر إلى اسم ملف النسخ الاحتياطي)، ولكني تحققت من الجدول وهو مجرد قيمة تاريخ. لا توجد مؤشرات على مصدره.
على سبيل المثال، “الجيد” هو 20230823100627 والموقع هو 20231022224833. لا يمكنني حتى العثور على ملفات لـ “20231022” في مجلد post_migrate (أو في أي مكان آخر في المستودع).
أنا متأكد من أنه أمام عيني. ونعم، سأبحث في التغييرات السابقة ورسائل البريد الإلكتروني لمحاولة معرفة ما إذا كان بإمكاني مطابقة إجراء ما بعد أغسطس حيث قد يكون إصدار مارق قد تسلل.
في هذه الحالة، إنها نسخة Dev إلى نسخة “دمج” تم توفيرها حديثًا والتي سأستخدمها بعد ذلك للدمج لاستيراد نسخة Dev أخرى كجهد لتوحيد المثيلات قيد التنفيذ. تزامن إصدار ترحيل المخطط هو شرط مسبق (ليس مفاجئًا). في هذه الحالة، البيئة المستهدفة على 1022 والمصدر هو 0823. في جميع إصدارات 3.1.3 التي لدي، نحن 0823، لذلك كان الأمر محيرًا من أين جاء 1022 وهذا ما أحاول استنتاجه، لكن لا يمكنني العثور على أي أثر.
كان الناس ينظرون إلى الأتمتة، ولكن في البيئات الأخرى لم يقوموا بتنشيطها أبدًا، لذا كانت متاحة في قائمة الإضافات ولم يتم إجراء أي تغيير في المخطط. لذا بعيدًا عن المثالية، لكن التلميح بالنسبة لي في هذا العمل هو التحقق من مستودعات جميع الإضافات المثبتة حتى لو كانت معطلة، ربما تم تمكينها في وقت ما.
نقوم بإعادة نشر لإزالة بعض هذه الإضافات البحثية والتطويرية، بالإضافة إلى مراقبة إدخالات الإضافات / قاعدة البيانات عن كثب والقيام بسجلات أفضل هناك.
نعم، لقد اكتشفنا الأمر أخيرًا أيضًا بالنظر إلى وقت تشغيل المثيل نفسه، ولكنه بعيد عن الوضع المثالي. درس مستفاد لدليل تشغيل إذا احتجنا إليه. لم أتحقق من مستودع الأتمتة في المؤسسة لأنه بدا معطلاً ولم يكن هناك أي سجل لاستخدامه من قبل أي شخص. افتراض سيء من جانبي.
@RGJ هل هناك أي فرصة لأن تكون قاعدة البيانات هذه متاحة للعامة في أي مكان؟ استخدام نظام ملفات المثيل “يعمل” ولكنه يصبح أكثر فوضوية مما أفضل.
نعم، كنت أبحث في مستودع discourse نفسه مقابل المسح الشامل للعالم حيث لم أكن متأكدًا مما إذا كان سيظهر على الإطلاق. البحث بدون نطاق مكلف للغاية، لكنني لم أخرج إلى المنظمة لمعرفة ما إذا كانت هناك نتائج لجهود Discourse الرسمية.
لدينا 3 أو 4 مثيلات من Discourse بدأتها فرق مستقلة لحل مشكلة عمل مشتركة ونحن نرى ما إذا كان بإمكاننا جلب الجميع إلى مثيل واحد مع عدم فقدان عملهم السابق.
لا أصدق أنها ممارسة جيدة الاعتماد على الاحتفاظ بالبيانات في بيئة التطوير (dev).
إذا كانت البيانات مهمة، فيجب أن يكون هذا العمل موجودًا في بيئة الإنتاج (Production) في ظل ظروف أكثر تحكمًا.
لا أعرف الطبيعة الكاملة لما تحاول القيام به، ولكن بآرائي الخاصة، يجب أن تكون الحلول بالتأكيد إضافات (plugins) يمكن نشرها في أي مكان ولا تعتمد بالكامل على إصدار معين من Discourse، ولا تهتم إذا كانت بيانات معينة مسبقة التعبئة خارج نطاق إعداد بياناتها الخاصة.
في هذه الحالة، نقوم بجدوى عمليات الدمج هذه للحالات الإنتاجية باستخدام عدد قليل من الحالات التطويرية. إذا تمكنا من جعل دليل التشغيل قوياً، فستكون جميع البيانات والحالات على مستوى الإنتاج، ولكن تم صيانتها بواسطة فرق مستقلة حتى الآن. لذا فإن معرفة المعوقات التي تحول دون نجاح الدمج هو ما أعمل عليه الآن. ومن الواضح أن إصدار المخطط هو إصدار رئيسي، ويمكن لكل من التطبيق والإضافات التأثير على “قابلية الدمج” وستؤثر عليها. لحسن الحظ، أظهرت الحالات الإنتاجية 0823، لذا لن تحدث هذه المشكلة المحددة في تشغيل إنتاجي، ولكن معرفة كيفية تحليل انحراف المخطط كانت مطلوبة وستساعد وثائق العمليات لدينا حقاً.
اكتشفت فارقًا آخر في المخططات. لذلك قمنا بإزالة المكون الإضافي للأتمتة من النشر وأعدنا النشر. ثم لاحظت أن schema_migration بدا وكأنه عاد إلى 0823 كأحدث إصدار. لذلك اعتقدت أنني سأكون على ما يرام دون تثبيت المكون الإضافي للأتمتة في المثيل الذي أقوم بدمجه فيه. حسنًا، عندما قمت بتشغيل الاستيراد مرة أخرى، حصلت على خطأ PG::UndefinedTable: ERROR: relation "discourse_automation_automations" does not exist، لذلك على الرغم من أن إصدار الترحيلات قد تراجع، إلا أن التغييرات في المخطط المرتبطة به في قاعدة البيانات الفعلية كانت لا تزال موجودة على ما يبدو.
(والذي يمكنك الحصول عليه 
