كيفية التراجع بأمان عن إصدار Immich بعد إصدار غير متوافق

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

لا تُعد إصدار Immich إلى إصدار سابق إلا بعد الحفاظ على الحالة الحالية وتحديد ما إذا كان الإصدار الأحدث قد غيّر قاعدة البيانات أو الإعدادات بطريقة لا يستطيع الإصدار الأقدم قراءتها.

يمكن استبدال صورة الحاوية، لكن ربما تكون الحالة الدائمة قد خضعت للترحيل بالفعل. إذا بدأ التحديث بشكل سيئ، فأوقف التحديثات التلقائية وعمليات الكتابة الجديدة، وسجّل الإصدارين، واحمِ قاعدة البيانات الحالية والوسائط، ثم اختر بين التراجع البسيط عن صورة الحاوية واستعادة نقطة الاسترداد السابقة للتحديث.

جمّد التحديث الفاشل قبل أن يغيّر المزيد من الحالة

عطّل تحديثات الصور التلقائية وأوقف العملاء عن إضافة صور جديدة أثناء جمع الأدلة. سجّل أرقام الإصدارات أو البصمات الدقيقة لصورتَي Immich القديمة والجديدة، وإصدار PostgreSQL، وملفات Compose والبيئة، ومسارات التحميل، وأول خطأ في بدء التشغيل أو الترحيل.

يوضّح دليل ZimaSpace حول حدود التراجع عن صورة الحاوية التمييز المهم: تبقى وحدات التخزين الدائمة بعد استبدال الصورة، لكن ذلك يكون آمنًا فقط عندما يظل التطبيق الأقدم متوافقًا مع الحالة الموجودة داخلها.

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

حدّد ما إذا كان الإصدار قد تجاوز حدًا من حدود ترحيل قاعدة البيانات

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

يوضّح تقرير حديث عن Immich حيث فشلت الخدمة بعد مسار تحديث سبب عدم موثوقية تبديل الإصدارات البسيط عند استخدام مسارات ترحيل غير مدعومة أو متجاوزة. تعامل مع النقاش بوصفه دراسة حالة، وتحقق من تسلسل الترحيل الدقيق لإصداراتك.

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

استعد قاعدة بيانات وبيئة تشغيل متطابقتين بدلًا من خلط فترتين

أنشئ هدف التراجع من آخر إصدار معروف بسلامته، وإعداد النشر المتوافق معه، ونقطة استرداد قاعدة البيانات السابقة للتغيير غير المتوافق. أبقِ شجرة الوسائط كما هي ما لم يغيّر الإصدار ملفات الوسائط بطريقة موثقة؛ لا تُعد نسخ تيرابايتات لمجرد أن صورة التطبيق تغيّرت.

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

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

-15% OFF

ثبّت الصورة الدقيقة المعروفة بسلامتها وأعد إنتاج إعداداتها

استخدم إصدارًا محددًا أو مرجع صورة غير قابل للتغيير بدلًا من وسم متحرك. استعد البيئة المطابقة، وتبعيات الخدمة، وتعيينات الأجهزة، والشبكات، والمنافذ، وهدف الوكيل العكسي من آخر عملية نشر معروفة بسلامتها. فالتراجع الذي يغيّر عدة طبقات من البنية التحتية دون تنبيه ينشئ حادثة ثانية.

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

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

تحقق من الإصدار القديم تحت المحفّز الأصلي وحافظ على مسار للتقدم

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

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

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

الدعم والنصائح

المزيد للقراءة

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.