لماذا يتصرف Immich بشكل مختلف بعد إعادة تشغيل الحاوية؟

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

تتغير حالة Immich بعد إعادة التشغيل لأن ذاكرات التخزين المؤقت المؤقتة تختفي، وتُعاد اتصالات تبعيات الخدمة، بينما قد يكشف إعداد التخزين الدائم غير الصحيح عن فقدان أكثر خطورة للحالة.

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

إعادة التشغيل تزيل حالة العملية المؤقتة

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

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

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

قد يكشف ترتيب التبعيات عن سباق عند بدء التشغيل

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

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

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

يجب أن تبقى الحالة الدائمة بعد استبدال الحاوية

تختفي الصور وملفات قاعدة البيانات المخزنة فقط في طبقة الكتابة الخاصة بالحاوية عند استبدال تلك الحاوية. ولا تستمر وحدات التخزين المُسمّاة وعمليات الربط إلا عندما يشير النشر إلى الموقع الأساسي نفسه. تحافظ إعادة التشغيل البسيطة عادةً عليها، لكن تعديلات 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.