فكرة جيدة، شكرًا يا إد! لقد حدّثت مشاركتي. 
إعجابَين (2)
مع هذا التغيير، ألاحظ انخفاضًا إجماليًا في استهلاك الذاكرة بنسبة 4% تقريبًا. أحسنت.
إعجابَين (2)
شكراً لكِ يا ليلي، قمت بالتحديث منذ قليل ويبدو أن كل شيء سار على ما يُرام 
إعجاب واحد (1)
لا يُعدّ من الشائع أن تكون الجداول والفهارس المُعاد كتابتها أكثر إحكامًا
إعجاب واحد (1)
آه، هذا ضمن الضوضاء التشغيلية لـ Postgres (يعتمد على ما إذا كنت تنظر قبل أو بعد تنفيذ vacuum، إعادة بناء الجدول، وما إلى ذلك)
لم ألاحظ أي شيء مفقود منذ ذلك الحين، لذا، على حد علمي، كل شيء على ما يرام.
إعجاب واحد (1)
أقوم بتشغيل Discourse في حاوية Docker مستقلة على /var/discourse.
حاولت ترقية قاعدة بيانات PostgreSQL المدمجة من الإصدار 15 إلى 18. بدا أن عملية الترقية اكتملت، والمجلد النشط للبيانات الآن يُظهر:
/shared/postgres_data/PG_VERSION
18
ومع ذلك، لا تزال حاوية Discourse المُعاد بناؤها تحتوي فقط على ثنائيات PostgreSQL 15:
/usr/lib/postgresql/15/bin/postgres
postgres (PostgreSQL) 15.18
تم تكوين خدمة PostgreSQL لتشغيل:
/usr/lib/postgresql/15/bin/postmaster -D /etc/postgresql/15/main
بينما يتم تركيب مجلد بيانات Discourse الفعلي في:
/shared/postgres_data
وبالتالي، تفشل PostgreSQL مع ظهور الخطأ التالي:
FATAL: database files are incompatible with server
DETAIL: The data directory was initialized by PostgreSQL version 18,
which is not compatible with this version 15.18
(Debian 15.18-1.pgdg12+1).
أفهم أن صور Discourse Docker الحديثة من المفترض أن تحتوي على ثنائيات PostgreSQL 18. قمت بتعديل app.yml لاستخدام قالب PostgreSQL 18 وإعادة بناء التطبيق، لكن الحاوية الناتجة لا تزال تحتوي على ثنائيات PostgreSQL 15، ولا يزال سكريبت الخدمة يشير إلى /etc/postgresql/15/main.
الجزء ذي الصلة من إعداد الخدمة الحالي هو:
HOME=/var/lib/postgresql USER=postgres exec thpoff \
chpst -u postgres:postgres:ssl-cert -U postgres:postgres:ssl-cert \
/usr/lib/postgresql/15/bin/postmaster -D /etc/postgresql/15/main
أسئلتي هي:
-
ما هو الطريقة الصحيحة لإعادة بناء أو تحديث حاوية Discourse بحيث تحتوي فعليًا على ثنائيات PostgreSQL 18؟
-
هل يوجد قالب أو وسم صورة (image tag) معين يجب استخدامه في
app.yml؟ -
بمجرد توفر PostgreSQL 18، ما هي الإجراء المدعوم لبدء تشغيله مقابل مجلد
/shared/postgres_dataالموجود مسبقًا؟
لم أحذف أو أعيد تهيئة مجلد بيانات PostgreSQL 18. أفضّل استعادة العنقود المُرقى بدلاً من استعادة بيانات PostgreSQL 15 القديمة.
إعجاب واحد (1)
بناءً على التعليمات الموجودة في المنشور الأصلي، يبدو أن هذه كانت خطوة غير ضرورية، ما لم أكن أفوّت شيئًا؟
فإن إعادة بناء تثبيت قياسي كان يجب أن يجلب أحدث صورة ويبدأ الترحيل.
ما لم تكن قد اخترتَ عدم استخدام أحدث صورة، أليس من المؤكد أن الثنائيات الجديدة كانت مضمونة؟ غريب جدًا…
هل أنت متأكد من أنك لم تثبّت (تُثبِّت) على صورة معينة؟
3 إعجابات
ليس عن قصد؟ أنا أستخدم مستودع git الفرع العادي، ولا يوجد في ملف app.yml الخاص بي ما يشير إلى أنني قمت بتثبيت أي إصدار. لقد قمت فقط بتغيير القالب إلى postgres 18 لمعرفة ما إذا كان سيوفر أي فائدة؛ نعم، كانت هذه خطوة غير ضرورية لم تنفع، لذا يمكنني إرجاعها إلى الوضع السابق.
هل لديكم أي اقتراحات حول كيفية الحصول على الملفات التنفيذية الجديدة؟ فهي غير موجودة فعليًا على الرغم من عدد المرات التي أعدت فيها البناء:
root@hostname-app:/usr/lib/postgresql# ls -la
total 12
drwxr-xr-x 1 root root 4096 May 21 00:47 .
drwxr-xr-x 1 root root 4096 May 21 00:48 ..
drwxr-xr-x 1 root root 4096 May 21 00:47 15
root@hostname-app:/usr/lib/postgresql#
إعجاب واحد (1)
لإدخار الوقت والجهد، أنصحك باستخدام أحدث نسخة احتياطية لديك لإنشاء خادم جديد، فسيوفر عليك الكثير من العمل.
إعجاب واحد (1)
حسنًا، أعتقد ذلك! أحيانًا لا يستحق الأمر العناء في إصلاح الأشياء. شكرًا لك.
إعجابَين (2)
إذا لم تتمكن من الوصول إلى لوحة الإدارة لأن نسخة Discourse الخاصة بك فقدت اتزانها، فكيف يمكنك أخذ نسخة من قاعدة البيانات عبر root@ لرفعها إلى نسخة جديدة؟ (ربما يوجد دليل آخر)
أو ما هو الأمر الذي يجب تنفيذه عبر سطر الأوامر لإجراء نفس العملية التي تتم عبر لوحة الإدارة؟
حسنًا، وبشكل أدق، أحتاج إلى إعادة بناء التطبيق لحل مشكلة شهادة تبدو وكأنها حدثت للتو (لم يتم إجراء أي تغييرات مسبقة أدت إلى هذا الفشل الظاهر) - تظهر رسالة خطأ “المنفذ 443 غير قابل للوصول” (يشير المعالج إلى: “فشل التحقق من DNS”) - لا أعلم ما إذا كانت Cloudflare أو DigitalOcean قد غيّرت شيئًا، لكن مرة أخرى لم يتم إجراء أي تغييرات من طرفي - حسنًا، لا أستطيع إعادة البناء بسبب هذين الخطأين المحتملين، بما في ذلك الخطأ أدناه، على عكس المرة الماضية التي كانت فيها المشكلة “مساحة غير كافية”، هل لديك فكرة عن كيفية تجاوز هذا الخطأ أدناه؟
لإضافة إلى ذلك، حصلت على نفس الخطأ تمامًا قبل وبعد زيادة حجم القرص الأساسي (لإدراج احتياجات ترقية postgres من 15 إلى 18)
FAILED
--------------------
Pups::ExecError: if [ -f /root/install_postgres ]; then
/root/install_postgres && rm -f /root/install_postgres
elif [ -e /shared/postgres_run/.s.PGSQL.5432 ]; then
socat /dev/null UNIX-CONNECT:/shared/postgres_run/.s.PGSQL.5432 || exit 0 && echo postgres already running stop container ; exit 1
fi
failed with return #<Process::Status: pid 17 exit 1>
Location of failure: /usr/local/lib/ruby/gems/3.4.0/gems/pups-1.4.0/lib/pups/exec_command.rb:138:in 'Pups::ExecCommand#spawn'
exec failed with the params {"tag" => "db", "cmd" => "if [ -f /root/install_postgres ]; then\n /root/install_postgres && rm -f /root/install_postgres\nelif [ -e /shared/postgres_run/.s.PGSQL.5432 ]; then\n socat /dev/null UNIX-CONNECT:/shared/postgres_run/.s.PGSQL.5432 || exit 0 && echo postgres already running stop container ; exit 1\nfi\n"}
أوه، حسنًا، لقد وجدت ما أعتقد أنني بحاجة إليه، وقد نشرته @Lilly في هذا الموضوع منذ فترة طويلة
cd /var/discourse
./launcher enter web_only
discourse backup
exit
من هذا، أفترض أنني يمكنني إنشاء نسخة احتياطية قابلة للاستخدام من قاعدة البيانات، والتي يمكنني رفعها إلى نسخة discourse جديدة، وتجاوز جميع المشاكل.
هل سيعطيني هذا الأمر نسخة احتياطية كاملة، أي المنشورات + المرفقات/الصور؟
أوصي بنسخ احتياطي لقاعدة البيانات فقط، واستخدام rsync لنقل كل شيء آخر. نقل موقع Discourse إلى VPS آخر باستخدام rsync. يمكنك أيضًا نقل شهادات ssl باستخدام rsync حتى تتمكن من تشغيل الموقع الجديد قبل تغيير DNS.
إليك كيف أقوم بذلك: Changing Digital Ocean droplets with doctl (resize, floating ip, rename, etc) - Howto - Literate Computing Dashboard
تعديل: آسف. لا أستطيع معرفة ما إذا كنت قد حللت مشكلتك أم لا. إذا كنت أقرأ الأمر بشكل صحيح، فأكثر شيء سهولة هو العودة إلى القالب الافتراضي بدون إصدار وإعادة البناء مرة أخرى.
إعجابَين (2)
هل أعدت بناء حاوية البيانات (على الأرجح حاوية التطبيق في حالتك) مرتين كما هو مطلوب؟
(بالمناسبة، رسالة التحديث تقول بإعادة بناء التطبيق، لكنني أعتقد أنها تعني “حاوية قاعدة البيانات التي قد تُسمى app أو data”، أم أنها تعني كلاهما؟)
وبعض الملاحظات: قبل فترة، حاولت الانتقال من الإصدار 13 إلى 15 لكن فشلت عدة مرات، وظللت مع قالب .13. عندما طُرح الإصدار .18، حاولت مرة أخرى ونجح الأمر دون أي مشاكل (كان عليّ فقط تنظيف المجلدات _new و _older قبل ذلك). لذا، يمكنني الآن تشغيل القالب الافتراضي غير المُرقّم للبيانات مرة أخرى. أحسنت في جعل التحديث متينًا بهذا الشكل.
إعجاب واحد (1)
لاحظت للتو في سجل الأخطاء، وقبل تحديث قاعدة بيانات PostgreSQL، أن هناك بعض الأخطاء المتعلقة بـ SQL في السجلات:
Job exception: PG::UndefinedFunction: ERROR: function array_remove(bigint[], integer) does not exist LINE 1: ...ATE "access_control_lists" SET allowed_user_ids = array_remo...
وهذا أمر غريب، إذ يبدو أن هذه الدالة من إصدار PostgreSQL 9، بينما كنت أستخدم الإصدار 15 سابقًا. هل يمكن أن يكون هذا مشكلة في الصلاحيات أو مسار البحث (search path)؟ يبدو أن المشكلة لم تعد تظهر بعد تحديث قاعدة البيانات، لكن ربما يكون الأمر متعلقًا بتوقيت الدفعات (batch timing)… أرى أن الدالة مستخدمة في أماكن كثيرة، وحتى في سكربتات الترحيل (migration scripts).
ربما يعني ذلك أن بعض الدوال تفشل في الإصدارات الأقدم من PostgreSQL على الرغم من أن قوالبها لا تزال مدرجة. ربما فاتني ذلك، لكنني كنت أعتقد أن الإصدارات الأقدم متوافقة.
إعجاب واحد (1)