ملاحظة: لست متأكدًا من السبب، لكن ترقية PostgreSQL 18 تعطل فحوصات البيانات الأصلية. تُعد فحوصات بيانات PostgreSQL ميزة افتراضية، ويبدو أن تعطيلها أمر غير معتاد للغاية.
طلب السحب (PR) لعدم تعطيل فحوصات البيانات (مفعل افتراضيًا): Do not disable PostgreSQL 18 data checksums - Pull Request #1105 - discourse/discourse_docker - GitHub
وهو أفضل من أن تضطر لتخصيص 20 جيجابايت فارغة لساعة واحدة فقط تحتاجها في عام كامل 
ربما ينبغي أن يكون هذا هو النهج الموصى به من أجل توفير الأشجار والماء. 
فقط للتأكد، أنا لا أستخدم PostgreSQL الذي توفره Discourse، وDiscourse نفسها لا تتطلب PG18 بعد، أليس كذلك؟ لذلك، لا يُطلب مني (بعد) الترقية إلى PG18.
ملاحظة جيدة. لكن النقطة الأخرى هي أن إصدارات LTS (الدعم طويل الأجل) تظهر كل بضع سنوات، لذا فإن القيام بذلك في الوقت نفسه ليس فكرة سيئة.
لديك بالتأكيد وقت طويل. لقد دافعوا عن… آه، بعض الإصدارات بسرعة بعد التحديث بسبب ميزة معينة كانت مطلوبة، لكن يمكنك على الأرجح الانتظار لمدة تصل إلى عام. أنا أراقب مستودع discourse_docker. في مرحلة ما، سيبدأون في الحديث عن إزالة الدعم لـ PG15؛ الأمر ليس صاخباً بشكل خاص وهو طريقة سهلة للبقاء على اطلاع على تحديثات الأمور الداخلية.
إعجابَين (2)
عمل بشكل جيد على تثبيت Raspberry Pi 5 الخاص بي، بعد إعادة بنائه مرتين وانتهى الأمر.
7 إعجابات
هل لدينا أي معايير أداء (benchmarks) بالمناسبة؟
هذا قد يشجع الآخرين على اتباع خطانا الجريئة في وقت أقرب.
تخبرني أداة البحث الذكي المجانية الخاصة بي:
بالنسبة لتطبيق Rails نموذجي، يمكن أن يؤدي الانتقال من PostgreSQL 15 إلى 18 إلى تحقيق أداء استعلام أسرع بنسبة ~10-25% دون إجراء أي تغييرات على الكود، وحتى 40% في أنماط استعلام محددة إذا استغلت ميزات الفهرسة والمخطط الجديدة.
إذا كان هذا صحيحاً، فهذه ترقية كبيرة! 
7 إعجابات
فقط للتأكد من أن كل شيء سار بسلاسة في نسختنا المستضافة ذاتيًا. شكرًا لك على هذا التحديث، وابقنا على اطلاع.
5 إعجابات
صحيح، لكننا نهدف إلى آلية ترقية بسيطة وشفافة. هناك مزايا في كلا الاتجاهين.
أقول لك: افعل ما تشعر بالراحة تجاهه، ولا تخف من تخصيص القوالب في discourse_docker حسب احتياجاتك. ومن الواضح أن المفتاح هو الاختبار أولاً ووجود خطة للتراجع.
في منصتنا المستضافة، ننوي إجراء المزيد من الاختبارات والمقارنات قبل تفعيل هذه الميزة، ولذلك قمت بتعطيلها في discourse_docker أيضًا لتوحيد الإعدادات. ومع ذلك، لا يلزم تعطيلها بشكل صارم (نحن نستخدم فقط جزء حاوية الويب من discourse_docker داخليًا)، ولن أمانع في تفعيلها.
إحدى النقاط المحتملة التي قد تسبب المشاكل هي أن pg_upgrade لن يعمل إذا كانت إعدادات فحوصات البيانات في مجلدي البيانات القديم والجديد مختلفة. يجب أن تكون العملية كالتالي: إيقاف خادم PG15، تشغيل pg_upgrade لتحويله إلى PG18 دون فحوصات، ثم تشغيل pg_checksums لتفعيل فحوصات البيانات، وأخيرًا تشغيل PG18. هذا لا يمثل مشكلة عند استخدام النسخ الاحتياطي والاستعادة (كما في هذه الترقية)، لكنه شيء يجب الانتباه إليه.
لاحظ أن فحوصات البيانات كانت متاحة منذ إصدار Postgres 9.3، لكنها كانت معطلة افتراضيًا حتى الآن. سيضم Postgres 19 أيضًا القدرة على تفعيل/تعطيلها أثناء التشغيل.
[quote=“elmuerte, post:25, topic:406194, full:true”]
فقط للتأكيد، أنا لا أستخدم PostgreSQL المقدم من Discourse، وDiscourse نفسه لا يتطلب PG18 بعد، أليس كذلك؟ إذن لستُ ملزمًا (بعد) بالترقية إلى PG18.
[/quote]\n
ليس في الوقت الحالي، لا. معظم وظائف Discourse تستخدم محول Rails PostgreSQL للتواصل مع قاعدة البيانات، لكن النسخ الاحتياطي والاستعادة تستخدم pg_dump وpsql في حاوية الويب. حاليًا، نقوم بتثبيت عميلَي PG15 وPG18 لتمكين النسخ الاحتياطي والاستعادة باستخدام كلا الإصدارين، لكن في مرحلة ما في المستقبل سنزيل PG15.
العامل الدافع كان الانتقال إلى مزود اللغة المدمج الجديد. نحن نعمل على ترقية نظام التشغيل في منصتنا المستضافة ونريد كسر الاعتماد على glibc.
3 إعجابات
أدير PostgreSQL الخاص بي بشكل مستقل عن الحاوية. ما هو تجزئة Git الموصى بها التي يجب أن أتحول إليها لاستخدام pg18؟
إعجاب واحد (1)
e7f1201 أضاف عميل PG18 إلى صورة الويب لتوافق النسخ الاحتياطية. إذا كنت لا تستخدم أيًا من مكونات خادم Postgres في discourse_docker، فهذا هو أقدم إصدار يجب عليك استخدامه لـ PG18.
إعجاب واحد (1)
كنت أتحدث عن ترقيتين أو ثلاث.
أوافق. كانت نقطتي فقط هي أن القدرة على استعادة نسخة احتياطية قديمة من PostgreSQL إلى إصدار أحدث لا تقل دعمًا. آلية الترقية في الموقع تعمل بشكل مذهل لأغلب الأشخاص، ولكن عندما يحدث خطأ ما، يصعب معرفة ما يجب فعله (لأنه يحدث نادرًا إلى حد كبير).
إعجابَين (2)
إذا كان ذلك يساعد أي شخص، في اللحظات التي تبقى فيها وحدة تحكم SSH ثابتة وفي اللحظات التي يبدأ فيها العرق البارد من الذعر في الظهور…
قمت بتشغيل هذا في نافذة طرفية أخرى لمراقبة التقدم:
watch -n 10 'df -h /; echo; du -sh /var/discourse/shared/standalone/postgres_data* 2>/dev/null'والذي يحدث لك كل 10 ثوانٍ ويحافظ على هدوئك
استغرق هجرتي بحجم 35 جيجابايت حوالي 10 دقائق.
8 إعجابات
تم التحديث لدي بنجاح مع التثبيت الافتراضي. بالطبع، قمت بعمل نسخة احتياطية وتنزيلها في حال حدوث أي خطأ 
3 إعجابات
رائع. سأضيف free -h إلى ذلك - إن استنفاد الذاكرة مشكلة شائعة بما يكفي.
المشكلة الوحيدة في استخدام watch أو حتى top هي أنها تتحدث باستمرار، لذا قد تفوتك بعض المعلومات. إذا نفدت لديك موارد معينة وفشل التحديث، فإنك تفقد السجل بعد بضع ثوانٍ. لذلك، أميل إلى تشغيل شيء أكثر شبهاً بحلقة while - ربما مثل هذا:
while true; do date; echo; free -h; echo; df -h /; echo; sh -c 'du -sh /var/discourse/shared/standalone/postgres_data* 2>/dev/null'; sleep 10; echo; done
4 إعجابات
أستطيع الإبلاغ عن نجاح… في نصف إعداد الموقع المتعدد الخاص بي. تم هجرة الموقع الافتراضي كما هو متوقع، لكن الموقع الثانوي بدا وكأنه تثبيت جديد. لحسن الحظ، لا يصعب استعادة النسخة الاحتياطية. لدي خادم آخر أستخدمه للعملاء، وأفكر في تشغيل نقطة (Droplet) جديدة واستعادة المواقع من النسخ الاحتياطية لإجراء هذا التحديث. هذا أحد مخاطر استخدام تثبيت غير قياسي، أعتقد.
إعجاب واحد (1)
هل كان حاوية البيانات الخاصة بك حاوية بيانات قياسية؟ كنت أتساءل عما إذا كانت ستقوم بنقل قاعدة بيانات واحدة فقط أم جميعها في العنقود. يبدو أنك أجبت على سؤالي!
ما أفعله هو نقل كل قاعدة بيانات يدويًا من العنقود القديم إلى الجديد، ثم تعديل ملف discourse.conf يدويًا للتوجيه إلى قاعدة البيانات الجديدة، ثم إجراء إعادة بناء لتوجيه حاوية المواقع المتعددة بأكملها إلى العنقود الجديد (على جهاز مختلف أو منفذ مختلف).
إعجاب واحد (1)
نعم. بطبيعة الحال، لا يمكنني أن أقول إنني لم أرتكب أي أخطاء في إعداداتي. 
كنت أخطط لاستخدام rsync لنسخ بيانات postgres الخاصة بي لتشغيل qn upgrade هناك، لأتأكد مما إذا كانت العملية تنقل قاعدة بيانات discourse فقط أم العنقود بأكمله، لكن يبدو أنك أجبت على سؤالي، وسيكون الأمر واضحًا إذا نظرت إلى الكود.
إعجابَين (2)
لديّ سؤالان هنا:
- قمنا بتثبيت كتلة تخزين إضافية على خادم الاختبار. لكن ترقية PostgreSQL تفشل لأن فحص المساحة يتحقق فقط من القرص الرئيسي. هل هناك طريقة لتجاوز فحص المساحة؟
- بالنسبة لموقعنا الإنتاجي، نستخدم Google Cloud SQL. هل هناك أي شيء يجب أن نعرفه قبل الترقية عبر Google Cloud؟