علامات تشير إلى حاجة قاعدة بيانات Immich إلى الصيانة أو الاستبدال

قد تحتاج قاعدة بيانات Immich البطيئة فحسب إلى صيانة دورية لـ PostgreSQL أو إلى إصلاح للموارد؛ أما قاعدة البيانات التي تُظهر إخفاقات متكررة في سلامة البيانات أو الاسترداد، فقد تحتاج إلى استعادتها أو استبدالها من نسخة احتياطية تم التحقق منها.

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

افصل تدهور الأداء عن فشل سلامة البيانات

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

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

احتفظ بالسجلات، وإصدار قاعدة البيانات، وإصدارات الإضافات، وسجل الترقيات الأخيرة، ونسخة احتياطية أو لقطة قبل إجراء أي صيانة تدخّلية. إذا كانت النسخة الوحيدة من قاعدة البيانات قد تكون تالفة، فلا تُجرِ تنظيفًا تدميريًا لمجرد معرفة ما إذا كان الخطأ سيختفي؛ واحتفظ بالأدلة اللازمة لاتخاذ قرار استعادة منضبط.

ابحث عن مؤشرات صيانة قابلة للقياس

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

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

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

تأكد من أن التضخم أو نمو الفهارس يتوافق مع مسار البطء

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

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

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

-15% OFF

ZimaBoard 2 - خادم منزلي صغير لأفكارك الكبيرة

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

انتقل إلى الاستعادة أو الاستبدال عندما تكون سلامة البيانات غير مؤكدة

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

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

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

تحقق من قاعدة البيانات عبر عمليات القراءة والكتابة والنسخ الاحتياطي

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

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

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