كيفية إصلاح Immich بعد امتلاء وحدة تخزين قاعدة البيانات الخاصة به

عند امتلاء وحدة تخزين قاعدة بيانات Immich، أوقف عمليات الكتابة الجديدة في Immich، وحافظ على دليل بيانات PostgreSQL، وأنشئ مساحة عمل آمنة قبل محاولة الاسترداد. لا تحذف الملفات من pg_wal أو من مكونات PostgreSQL الداخلية الأخرى لمجرد أنها كبيرة.

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

تأكد من نظام الملفات الممتلئ وأوقف عمليات الكتابة الإضافية

تحقق من توفر السعة وعدد العقد لكل من وحدة تركيب PostgreSQL، وجذر بيانات Docker، ونظام ملفات الجذر على المضيف، وأي مسار tmpfs أو ذاكرة مشتركة مذكور في الخطأ. طابق التوقيت مع سجلات PostgreSQL. تعني رسالة «لا توجد مساحة كافية على الجهاز» الصادرة من pg_wal شيئًا مختلفًا عن امتلاء ذاكرة التخزين المؤقت للصور أو قسم الصور المصغرة.

يوضح نقاش حول استرداد قاعدة بيانات Immich أن PostgreSQL أوقف الاسترداد لأنه لم يتمكن من كتابة ملف WAL مؤقت بعد امتلاء وحدة التخزين. الحالة قديمة ومحددة ببيئة نشر معينة، لكنها توضح لماذا لا يؤدي تغيير أذونات الملفات أو إعادة تشغيل الحزمة إلى إصلاح مشكلة السعة.

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

حافظ على حالة PostgreSQL قبل توفير مساحة

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

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

استرد PostgreSQL أولًا، ثم قرر ما إذا كان Immich يحتاج إلى إصلاح

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

يوضح دليل ZimaSpace حول صيانة قاعدة بيانات Immich أو استبدالها الحد الفاصل التالي: لا ينبغي أن تؤدي مشكلات الحجم أو الأداء العادية إلى إعادة البناء، بينما قد يبرر فشل التكامل أو الاسترداد المتكرر استعادة نسخة موثقة من قاعدة البيانات.

شغّل Immich فقط بعد استمرار PostgreSQL في العمل بصورة سليمة.

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

Featured

ZimaCube 2 سحابة شخصية منزلية NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

أصلح سبب النمو وأثبت قدرة النظام على الامتلاء بأمان مجددًا

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

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

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