فشل نسخة احتياطية لـ pg_dump لـ pgsql عن بُعد - اختلافات في المنفذ والإصدار: ما الخيارات المتاحة؟

عند محاولة تشغيل نسخ احتياطي للنظام، أواجه الرسالة التالية: “فشل النسخ الاحتياطي. يرجى التحقق من السجلات.”

ويشير السجل إلى: pg_dump: [archiver (db)] فشل الاتصال بقاعدة البيانات "discoursedb": تعذر الاتصال بالخادم: تم رفض الاتصال

أعتقد أن هناك مشكلتين على الأرجح:

  1. يعمل الخادم البعيد على منفذ غير قياسي.
  2. يعمل PostgreSQL البعيد بإصدار أحدث من PSQL.

عند الدخول إلى التطبيق (/var/discourse/launcher enter app) وتنفيذ نسخ احتياطي يدوي، لاحظت أنه في البداية، دون تعريف المنفذ، ظهرت نفس الرسالة بالضبط:

$ pg_dump -h 123.456.789.101 -U username -W -F t discourse_db > discourse_db_backup.tar
كلمة المرور:
pg_dump: [archiver (db)] فشل الاتصال بقاعدة البيانات "discourse_db": تعذر الاتصال بالخادم: تم رفض الاتصال
	هل يعمل الخادم على المضيف "123.456.789.101" ويقبل
	اتصالات TCP/IP على المنفذ 5432؟

تم حل هذه المشكلة بسهولة (باستثناء أنني لا أعرف كيف أجبر Discourse على استخدام المنفذ الصحيح في النسخ الاحتياطي)، لكن المشكلة التالية كانت أكثر إثارة للقلق، وهي أننا نستخدم إصدارًا أحدث من PSQL على خادم قاعدة البيانات:

$ pg_dump -h 123.456.789.101 -p 45678 -U username -W -F t discourse_db > discourse_db_backup.tar
كلمة المرور:
pg_dump: إصدار الخادم: 11.5 (Ubuntu 11.5-3.pgdg18.04+1); إصدار pg_dump: 10.10 (Debian 10.10-1.pgdg100+1)
pg_dump: جاري الإلغاء بسبب عدم تطابق إصدار الخادم

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

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

I did find some discussion in another post regarding someone who has a slightly comparable situation. The big difference in my case is that we store files on the local server vs S3. I could forego backing up PostgreSQL since that is backed up independently, however I do still need to back up:

  • local content and
  • Discourse settings

I still would like a consolidated backup with the db + content + settings all in one place, but I’m guessing you don’t/won’t support that and thus I’d like to at least get content + settings into a consolidated package.

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

Postgres 11 isn’t supported. You can look elsewhere for how to restore between versions, but it’ll be some work to get discourse to work with pg11.

Interesting and odd. I had read somewhere that 11 was alright, but aside from that I have a system already deployed to 11 and have not seen any errors or problems (aside from backup) thus far… Now you have me worried…

Oh, here we go, according to this post PostgreSQL 11 "should just work."

Yes. I’ve got two systems deployed on pg11 too. They are working fine except I’m doing backups directly. I upgraded pg to 11 in the container. They’ll make backups but not restore them.

4 إعجابات

The Discourse backup system should simply warn and not fail if there is a PostgreSQL version mismatch. I just tried to make a backup myself and because I too am using an external PG server, no tarball was created at all.

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

cd /var/discourse
./launcher enter app
apt-get remove postgresql-client-common
apt-get update
sudo apt-get install postgresql

التفاصيل: Discourse yedekleme pg_dump hatası ve çözümü: pg_dump: error: server version: 12|13|14|15|*; pg_dump version: 12|13|14|15|* - Veritabanı Yönetim Sistemleri - Soru Cevap