صحيح، لكننا نهدف إلى آلية ترقية بسيطة وشفافة. هناك مزايا في كلا الاتجاهين.
أقول لك: افعل ما تشعر بالراحة تجاهه، ولا تخف من تخصيص القوالب في 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.