هل يمكن لـ Immich استخدام قاعدة بيانات خارجية دون التسبب في مشكلات عند الترقية؟

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

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

ابدأ بتوثيق متطلبات قاعدة البيانات الخارجية

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

من الممكن استخدام خادم PostgreSQL موجود مسبقًا، لكنه ليس الإعداد الافتراضي الموصى به لـ Immich. في الإصدارات الحالية، يتطلب مسار قاعدة البيانات المستقلة إضافة pgvector بالإضافة إلى VectorChord؛ ومن المعروف أن Immich يعمل مع PostgreSQL من الإصدار 14 إلى 19، ومع pgvector بإصدار >=0.7 وأقل من 0.9، ومع VectorChord بإصدار >=0.3 وأقل من 2.0. أعد التحقق من هذه النطاقات قبل كل تحديث لأنها قد تتغير.

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

تحقق من توافق PostgreSQL والإضافات قبل تغيير أي شيء

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

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

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

افصل تحديثات الإصدار الرئيسي لقاعدة البيانات عن تحديثات Immich

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

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

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

Featured

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

ZimaCube2

$799.00 - $2,499.00

Buy Now

حافظ على مسار استرجاع يشمل قاعدة البيانات والوسائط معًا

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

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

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

تحقق من التحديث كتطبيق، لا كمجرد اتصال بقاعدة البيانات

بعد التغيير، تأكد من أن PostgreSQL يقبل دور Immich المقصود، وأن الإضافات المطلوبة موجودة بالإصدارات المتوقعة، وأن عملية ترحيل Immich تكتمل من دون أخطاء متكررة في قاعدة البيانات. يثبت اتصال TCP ناجح أو الأمر SELECT 1 إمكانية الاتصال، لا توافق التطبيق.

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

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