فشل النسخ الاحتياطية مع قاعدة بيانات Postgres 16 (وجميع PG أكبر من 13)

لم تعد النسخ الاحتياطية تعمل لقاعدة بيانات postgres 16 بسبب هذا الالتزام الذي يقوم بتثبيت postgresql-client-${PG_MAJOR} بدلاً من postgresql-client

هل هذا يحل مشكلة؟ ألم يكن عميل psql الذي توفره أنظمة التشغيل يعمل بشكل جيد مع جميع إصدارات postgres؟

لقد فوجئت بأن هذا العميل يستخدم PG16 على قاعدة بيانات Digital Ocean، لكنني اعتقدت أنني أعرف أن بعض استضافة CDCK تستخدم PG15 الآن.

هل هناك طريقة أفضل للحصول على نسخة احتياطية عاملة بدلاً من شيء مثل هذا:

run:
  - exec:
      cd: /var/www/discourse
      cmd:
        - apt-get update && apt-get remove -y postgresql-client-13 && apt-get install -y postgresql-client-16

ربما يمكنني تعيين PG_MAJOR في متغير بيئة؟

إعجابَين (2)

نعم، يبدو أن هذا هو الحال.

من PR:

اكتشفت هذه المشكلة عندما تم إجراء نسخة احتياطية من Discourse باستخدام pg_dump الإصدار 17.2 والذي لا يمكن استعادته على مجموعات PostgreSQL \u003c 17.2.

يبدو أنك بين المطرقة والسندان هنا (PostgreSQL: Documentation: 18: pg_dump)

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

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

لا. لا يمكنني ذلك، لأن هذا هو ما يبني الصورة الأساسية.

لذا، يبدو أن إصلاحي هو أفضل ما يمكن الحصول عليه، على الرغم من أنه لو كنت أكثر ذكاءً لكان بإمكاني إزالة محتويات apt التي أسحبها باستخدام apt-get update.

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

شكرًا لك، ريتشارد!

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

هل تفشل النسخ الاحتياطية بصمت؟

(أرى أن تثبيتي العادي يستخدم الإصدار 13، لذا أفترض أن هذا الموقف خاص بعض الشيء، على الرغم من أنه ربما ليس نادرًا جدًا.)

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

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

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

[2025-06-14 03:30:20] pg_dump: error: aborting because of server version mismatch
[2025-06-14 03:30:20] pg_dump: detail: server version: 16.9; pg_dump version: 15.12 (Debian 15.12-1.pgdg120+1)

أقوم بتشغيل Discourse على أوبونتو يعمل على قطرة Digital Ocean، باستخدام دليل التثبيت الموصى به. لكنني أستخدم قاعدة بيانات Postgres المُدارة من Digital Ocean بدلاً من حاوية postgres. بالنظر إلى قاعدة بياناتي، فهي تعمل بنسخة pg 16. لا أعتقد أنهم قاموا بترقيتها مؤخرًا (ولا أتوقع أن تتم ترقية إصدار رئيسي تلقائيًا على أي حال)، لكنني أرسلت بريدًا إلكترونيًا إلى دعمهم للتحقق مرة أخرى.

على أي حال، قادتني أبحاثي إلى هذه الصفحة. لم أكن متأكدًا من مكان وضع YAML الذي نشره @pfaffman، لذلك قمت بتشغيل الأوامر يدويًا، وفكرت في مشاركتها لأي شخص آخر يتعثر في هذا:

  • cd /var/discourse
  • launcher enter app
  • apt list --installed | grep postgres # للتأكد من أن الإصدار المثبت حاليًا هو 15
  • apt-get update
  • apt-get remove postgresql-client-15
  • apt-get install postgresql-client-16

ثم قمت بتشغيل نسخة احتياطية يدوية على صفحة النسخ الاحتياطي للمسؤول.

يبدو أن هذا قد أصلح المشكلة مؤقتًا، ولكن كما أشار @pfaffman، أتوقع أنه في المرة التالية التي أقوم فيها بترقية Discourse، سيعود إلى postgresql-client-15، وستتوقف النسخ الاحتياطية عن العمل مرة أخرى، مما يتطلب التدخل اليدوي المذكور أعلاه.

هل هناك أي حل لهذه المشكلة بخلاف الاضطرار إلى تكرار هذه الخطوات في كل مرة أقوم فيها بترقية Discourse؟

أعتقد أنني أقدم هنا مكانًا ما الأشياء لوضع هذه الأوامر على ملف app.yml الخاص بك.

يمكنك إلقاء نظرة على قوالب postgres للحصول على أمثلة ربما.

شكرًا، ولكنني لست متأكدًا مما إذا كنت أفهم. لدي انطباع بأن YAML الذي ذكرته في المنشور الأصلي أعلاه كان ببساطة وسيلة لتقليل الأوامر من العدد القليل الذي نشرته أعلاه إلى أمر واحد، ولكن كان لا يزال يتعين عليك تشغيله يدويًا في كل مرة تقوم فيها بترقية Discourse. هل أسأت تفسير ذلك؟