تحديث PostgreSQL 18 لمستخدمي الاستضافة الذاتية

هل يمكنك تقديم المزيد من التفاصيل؟ أواجه نفس المشكلة

إعجاب واحد (1)

بالنسبة لأولئك الذين يواجهون نفس المشكلة، هذا ملخص (بواسطة الذكاء الاصطناعي) لما قمت به:
بدء تشغيل PG15 مؤقتًا → تصدير قاعدة البيانات → استخدام PG18 → استعادة النسخة المُصدَّرة

إعجاب واحد (1)

إذن، نعم، هذا الترقية يعتمد على الصور.

إذن، حتى لو اخترت تثبيت إصدار قديم من Discourse، هل ستفرض الصورة الترقية إلى الإصدار 18؟

فهمتُ.

إعجاب واحد (1)

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

ولحسن الحظ، كان منتدى التطوير جديدًا نسبيًا، لذا لم يُفقد الكثير.

إعجابَين (2)

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

ولكن لو حدث خطأ، فإن البيانات الوحيدة التي كنت سأفقدُها هي تكوين مكون السمة.

إعجاب واحد (1)

مرحباً، لدي منتدى بقاعدة بيانات كبيرة نسبياً (حوالي 80 جيجابايت). للانتقال من الإصدار 13 إلى الإصدار 15، قمت بتغيير الخادم، وإجراء تثبيت جديد، ثم استعادة البيانات.
هل أنصحونني باتباع نفس النهج؟ (حاولت التحديث المباشر لكن واجهت أخطاء في ترميز الأحرف collation)

في وقت سابق من هذا الموضوع، ذكر فريق الدعم:

إذن، نعم، إنها خيار متاح.

لقد قلتَ بالفعل:

أخطاء في الترتيب؟ ما هو الإصدار الحالي لـ Discourse؟

ربما تنشر الأخطاء التي واجهتها / مخرجات وحدة التحكم.

لكنك لم تنفد المساحة (يوصى بضعف حجم قاعدة البيانات الحالية)؟

مرحباً، لدي مساحة كافية (250 جيجابايت فارغة). كانت المشكلة “عدم تطابق الترتيب الأبجدي” (collation mismatch)، لكن يبدو أن ملف app.yml لا يحتوي على ترميز UTF.

إعجاب واحد (1)

نحاول توفير إعدادات افتراضية منطقية في صور discourse_docker، لكن من المستحيل مراعاة كل حالة استخدام ممكنة. لا تتردد في تخصيص صورك لإبقاء الإصدارات القديمة إذا كنت تفضل ذلك.

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

هذه طريقة صالحة تمامًا إذا كنت تشعر براحة أكبر معها.

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

السبب في رؤيتك لذلك هو أننا أصدرنا في الأيام القليلة الماضية إصدارًا جديدًا من الصورة الأساسية يترقى من Debian Bookworm إلى Trixie، مما يغير إصدار glibc. الإعدادات المحلية (Locales) المعتمدة على مزود libc (والذي كنت تستخدمه على الأرجح) ليست مستقرة عبر ترقيات glibc، لذا عندما يبدأ سكريبت الترقية خادم Postgres لتصدير بياناتك القديمة، فإنه يعرض تحذيرات عدم تطابق الترتيب الأبجدي.

عدم تطابق الترتيب الأبجدي هو السبب الكامل وراء قيامنا بالتصدير والاستعادة بدلاً من تشغيل pg_upgrade. بمجرد أن تستخدم قاعدة البيانات C.UTF-8 مع مزود builtin، لن تؤثر ترقيات glibc بعد ذلك على الترتيب الأبجدي.

إعجابَين (2)

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

إعجابَين (2)

حاولتُ إدراج ما يلي في ملف app.yml

app.yml
templates:

  • “templates/postgres.15.template.yml”
  • “templates/redis.template.yml”
  • “templates/web.template.yml”
  • “templates/web.ratelimited.template.yml”

للتأخير في ترقية الإصدار، لكنني أواجه هذا الخطأ:

Errno::ENOENT: No such file or directory @ rb_sysopen - /etc/postgresql/15/main/postgresql.conf
Location of failure: /usr/local/lib/ruby/gems/3.4.0/gems/pups-1.4.0/lib/pups/replace_command.rb:11:in ‘IO.read’
replace failed with the params {“filename” => “/etc/postgresql/15/main/postgresql.conf”, “from” => “data_directory = ‘/var/lib/postgresql/15/main’”, “to” => “data_directory = ‘/shared/postgres_data’”}
bootstrap failed with exit code 1
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.
./discourse-doctor may help diagnose the problem.

يبدو أن حاوية الأساس غير صحيحة، أعتقد ذلك. هل قمت بتشغيل ./launcher rebuild؟ من المفترض أن يؤدي هذا الأمر إلى تنفيذ git pull، لكن يمكنك محاولة تشغيل git pull يدويًا للتحقق مما إذا كان ذلك سيُحدث أي تغيير.

إعجاب واحد (1)

نفس الخطأ

الخلاصة: sha256:837e8ed4b5916baa36856b842ad84fe262b6b1b5550701f8844b13cc7acad7a5
الحالة: تم تنزيل صورة أحدث لـ discourse/base:2.0.20260812-0036
docker.io/discourse/base:2.0.20260812-0036
جارٍ التأكد من أن المُشغّل (launcher) محدث
المُشغّل (launcher) محدث
إيقاف الحاوية القديمة

  • /usr/bin/docker stop -t 600 app
    app
    2.0.20260812-0036: جارٍ السحب من discourse/base
    الخلاصة: sha256:837e8ed4b5916baa36856b842ad84fe262b6b1b5550701f8844b13cc7acad7a5
    الحالة: الصورة محدثة بالفعل لـ discourse/base:2.0.20260812-0036
    docker.io/discourse/base:2.0.20260812-0036
    /usr/local/lib/ruby/gems/3.4.0/gems/pups-1.4.0/lib/pups.rb
    /usr/local/bin/pups --stdin
    I, [2026-08-25T06:22:16.249062 #1] INFO – : جارٍ القراءة من stdin
    I, [2026-08-25T06:22:16.274434 #1] INFO – : ملف > /etc/service/postgres/run chmod: +x chown:
    I, [2026-08-25T06:22:16.281650 #1] INFO – : ملف > /etc/service/postgres/log/run chmod: +x chown:
    I, [2026-08-25T06:22:16.287846 #1] INFO – : ملف > /etc/runit/3.d/99-postgres chmod: +x chown:
    I, [2026-08-25T06:22:16.293208 #1] INFO – : ملف > /root/install_postgres chmod: +x chown:
    I, [2026-08-25T06:22:16.299851 #1] INFO – : ملف > /root/upgrade_postgres chmod: +x chown:

فشل

Errno::ENOENT: لا يوجد ملف أو مجلد بهذا الاسم @ rb_sysopen - /etc/postgresql/15/main/postgresql.conf
موقع الفشل: /usr/local/lib/ruby/gems/3.4.0/gems/pups-1.4.0/lib/pups/replace_command.rb:11:in ‘IO.read’
فشل الاستبدال مع المعاملات {“filename” => “/etc/postgresql/15/main/postgresql.conf”, “from” => “data_directory = ‘/var/lib/postgresql/15/main’”, “to” => “data_directory = ‘/shared/postgres_data’”}
فشل التمهيد مع رمز الخروج 1
** فشل التمهيد ** يرجى التمرير لأعلى والبحث عن رسائل خطأ سابقة، فقد يكون هناك أكثر من خطأ واحد.
قد يساعد الأمر ./discourse-doctor في تشخيص المشكلة.
2d15a756bfd82ed45debfbb4936784721293a3aeecabe8ba9b58c64d4bbe16e1

إعجاب واحد (1)

أعتقد أنني وجدت السبب.

تقوم الصورة الأساسية الحالية بتثبيت خادم PostgreSQL 18، لكن ملف postgres.15.template.yml لا يزال يفترض أن حزم خادم PostgreSQL 15 موجودة مسبقًا. لذلك يصل إلى:

/etc/postgresql/15/main/postgresql.conf

قبل أن يتم إنشاء هذا الملف، مما يؤدي إلى ظهور خطأ ENOENT المذكور أعلاه.

لقد فتحت طلب دمج (PR) صغيرًا يجعل قالب احتجاز PostgreSQL 15 يحذف حزم خادم PostgreSQL 18 ويثبّت حزم خادم PostgreSQL 15 قبل إعداد PostgreSQL:

يجب أن يعيد هذا المسار المقصود حيث يؤخر تغيير postgres.template.yml إلى postgres.15.template.yml ترقية PostgreSQL 18.

4 إعجابات

هل تم إصدار التحديث؟
متى يمكنني إعادة المحاولة؟ (للمعرفة فقط)

تم دمج الإصلاح (شكرًا لك @Ethsim2!) لذا يمكنك المحاولة مرة أخرى.

إعجابَين (2)

يعمل، شكرًا جزيلًا!

إعجابَين (2)

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

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

3 إعجابات

نصيحة مفيدة لكل من يقوم بتحديثات PostgreSQL خارج Docker. يمكنك استخدام --link في pg_upgrade حتى لا تضطر إلى نسخ البيانات. يمكنك إنشاء روابط صلبة (hardlinks) لتلك البيانات. هذا يوفر مساحة القرص.

إعجابَين (2)