اترك الأمر لـ Discourse يتولى الترقية. يتطلب هذا ثلاثة أضعاف مساحة القرص. لذا، إذا كانت قاعدة بياناتك بحجم 100 جيجابايت، فستحتاج إلى 200 جيجابايت إضافية فارغة لإجراء الترقية. يمثل هذا بالطبع مشكلة ضخمة للأشخاص الذين لديهم تثبيتات كبيرة.
اتبع إجراء “التحديث اليدوي” الخاص بهم. يتطلب هذا ضعفي مساحة القرص، لذا إذا كانت قاعدة بياناتك بحجم 100 جيجابايت، فستحتاج إلى 100 جيجابايت إضافية فارغة. تمثل هذه أيضًا مشكلة كبيرة لبعض المستخدمين.
في هذا المنشور، اقترح @Falco استخدام خيار --link لإجراء الترقية في المكان نفسه باستخدام الروابط الصلبة. يدعم حاوية docker التي اقترح استخدامها هذا الوسيط، لكن مطوري Discourse لا ينصحون باستخدامه في المنشور.
إذن، سؤالي هو: هل يجب أن يكون الخيار 3 كالتالي:
تشغيل الأمر أدناه، والذي سيتطلب كمية ضئيلة جدًا من مساحة القرص الإضافية. لذا، إذا كانت قاعدة بياناتك بحجم 100 جيجابايت، فقد تتطلب، على سبيل المثال، 10 جيجابايت إضافية؟ وإذا كان الأمر كذلك، فهل هذه إجراء موصى به من قبل مطوري Discourse، وهل قام أي شخص بذلك بالفعل ونجا لرواية القصة؟
الأمر الجديد للترقية في المكان نفسه:
docker run --rm \
-v DIR:/var/discourse/shared/standalone/postgres_data:/var/lib/postgresql \
tianon/postgres-upgrade:12-to-13 \
--link
مقارنة بالأمر القديم للترقية إلى دليل جديد (يتطلب ضعف المساحة):
ملاحظة: كنت سأرد ببساطة على موضوع ترقية PG13 ذلك، لكنه يحذف المنشورات بعد 7 أيام. لماذا قمت بإعدادها بهذه الطريقة؟ أعرف أنه كان هناك الكثير من النقاش عندما ظهر هذا لأول مرة وكان من المفيد كمرجع.
إذا كانوا قد فعلوا ذلك، فلم يذكروا ذلك هنا. تحاول التعليمات الموجودة هنا في الغالب أن تكون خالية من الأخطاء قدر الإمكان وتتطلب الحد الأدنى من معرفة إدارة الأنظمة. يفضل معظم الأشخاص هنا فعل شيء بالطريقة الأكثر أمانًا والأكثر اختبارًا ممكنة بدلاً من طريقة مصممة لتوفير بضع دولارات فقط.
إذا كان الأمر يعمل بالنسبة لك، يمكنك تحديث تحديث PostgreSQL 13 وفقًا لذلك، ولكن قبل أن تفعل ذلك، هل تشعر بالراحة في التوصية بذلك لشخص لا يعرف ما هو bash؟ هل أنت متأكد من أن هذا لن يدمر قاعدة بياناته وأن موقعه سيُفسد إلى الأبد؟
الفكرة هي أنه إذا تم تقديم معلومات جيدة أخرى، فيجب إضافتها إلى المنشور الأصلي (OP) بدلاً من طلب من الناس قراءة منشورات تمتد على مدار سنوات من المرجح أن تكون غير مفيدة أو خاطئة.
لا، لست متأكدًا، فليس لديّ الكثير من الخبرة مع PostgreSQL، وآمل أن يتمكن أحد مطوري Discourse من تقديم ضمانات بأنها ستعمل.
حتى لو عملت بالفعل، فلن أنصح بها كإجراء الترقية الافتراضي، لأن الطريقة القديمة تحتفظ بنسخة منفصلة من قاعدة البيانات للرجوع إليها. ومع ذلك، إذا عملت، فستكون خيارًا ممتازًا للبيئات المحدودة المساحة.
طريقة سهلة أخرى هي تشغيل خادم جديد، ونقل البيانات، ثم إيقاف الخادم القديم. إذا كنت مضطرًا لاستخدام الخادم القديم، فقم بالترقية على خادم مؤقت، ثم قم بتثبيت نسخة جديدة على الخادم الأصلي (الذي قد يحتاج إلى ترقية نظام التشغيل) وأعد نقل البيانات إليه.
هذه الطريقة آمنة وسهلة وموثقة جيدًا. وقد قام بها المئات من الأشخاص.
نعم، لكن ذلك سيستغرق يومًا أو يومين. خلال هذا الوقت، يمكننا إما أ) إخبار المستخدمين بأن منشوراتهم خلال هذه الفترة ستُفقد، أو ب) جعل المنتدى للقراءة فقط. ولا يُعد أي منهما حلاً مثاليًا.
لا أعتقد أن الخادم سيكون معطلاً لفترة أطول بكثير مما كان عليه أثناء إعادة البناء. وإذا انتقلت إلى الخادم الجديد وبقيت هناك، فيمكنك ترك الخادم القديم في وضع القراءة فقط أثناء عملية الانتقال. إذا كانت التوقفات هي ما يقلقك، فإن الانتقال إلى خادم جديد سيكون أفضل بكثير.
لدينا منتدى كبير جدًا، لكنني لم أحاول استعادة نسخة احتياطية من قبل، لذا لا أعرف كم من الوقت سيستغرق الأمر. سنبقى بالتأكيد على المضيف الجديد إذا قمنا بذلك. وأود تجنب ذلك قدر الإمكان بسبب العمل الإضافي/الإزعاج.
طريقة أخرى لحل مشكلة الترقية مع مساحة محدودة هي عمل نسخة احتياطية، وحذف دليل postgres باستخدام rm -r، وإعادة البناء، ثم استعادة النسخة الاحتياطية. لقد قمت بذلك في موقع الأسبوع الماضي.
لا، لم أحصل عليه مطلقًا على ترقية. حذف قاعدة البيانات واستعادة النسخة الاحتياطية يبدو محفوفًا بالمخاطر للغاية. نحتاج إلى الترقية في مكانها لتعمل، بشكل أساسي.
نحن نشغل أوبونتو 18.04 والذي سيتم إيقاف دعمه في عام 2023، لذا أعتقد أنه في تلك المرحلة لن يكون لدينا خيار سوى الانتقال إلى مضيف جديد على أي حال، ونخطط لتحمل العبء حينها، وبناء مضيف جديد يعمل بنظام 22.04 LTS، واستعادة من النسخة الاحتياطية.
هممم. قد يكون الأمر غير مهم. أعتقد أنه مع النموذج الاحتياطي، يتم ضغط أحد النسخ، مما قد يحدث فرقًا؟ وكان الموقع الذي قمت به يحتوي على نسخ احتياطية على S3. وكان موقع اختبار، لذا كانت المخاطر منخفضة إذا كانت هناك مشكلة.
باستثناء أن النسخ الاحتياطية تُستخدم كثيرًا وفي مواقف أكثر بكثير من الترقية في المكان. أعتبرها أكثر أمانًا بكثير.
ربما، ولكن ليس لدي خبرة كبيرة مع بوستجريس ولا أشعر بالراحة للقيام بذلك. استعادة الموقع بالكامل من النسخ الاحتياطي على جهاز افتراضي مختلف تمامًا، هذا أشعر بالراحة للقيام به، ومع ذلك سيعني ذلك فقدان المشاركات لعدد الساعات التي تستغرقها الاستعادة، لذلك لست متحمسًا جدًا لذلك أيضًا. ولكن نظرًا لأن 18.04 لم يعد مدعومًا، فلن يكون لدي الكثير من الخيارات العام المقبل.
ما لم تكن قاعدة بياناتك بحجم عشرات الجيجابايت، فلن يستغرق الأمر ساعات. وستضع المنتدى في وضع القراءة فقط قبل إجراء النسخ الاحتياطي والاستعادة، لذلك لن تفقد أي مشاركات. الأمر ليس بهذه الصعوبة مع وقت قراءة فقط يكاد يكون معدومًا.
بحلول ذلك الوقت، سيكون لديك أيضًا إمكانية الوصول إلى الدردشة المضمنة في Discourse، وهي ميزة سيتم إصدارها في 2.9 (ربما تكون معطلة افتراضيًا، ولكنها في مرحلة تجريبية ومدعومة للاستخدام).