Just let Discourse handle it. This requires 3 times the disk space. So if your DB is 100GB, you would need an additional 200GB free to do the upgrade. Obviously a huge problem for people with large installs.
Follow their “manual update” procedure. This requires 2 times the disk space, so if your DB is 100GB you would need an additional 100GB free. This is also a big problem for some.
In this post, @Falco suggested using the --link option to do the upgrade in-place using hard links. The docker container they suggest using supports that argument, but Discourse devs don’t suggest using it in the post.
So my question is this, should option 3 be:
Run the command below, which will require a very small amount of additional disk space. So if your DB is 100GB, it might require, say, an additional 10GB? And if so, is this a recommended procedure by the Discourse devs, and has anyone actually done it before and lived to tell the tale?
New command to upgrade in-place:
docker run --rm \
-v DIR:/var/discourse/shared/standalone/postgres_data:/var/lib/postgresql \
tianon/postgres-upgrade:12-to-13 \
--link
Compared to the old command to upgrade into a new directory (requiring double the space):
P.S.: I would have just replied to that PG13 upgrade thread, but it deletes posts after 7 days. Why do you have it configured that way? I know there was a lot of discussion when this first came up that would have been useful for reference.
If they have, they didn’t mention it here. Mostly instrucions here try to be as foolproof as possible and require as little system adminstration knowledge as possible. Most people here woud rather do something the safest, most tested way possible than some way designed to save a very few dollars.
If it works for you, you can update PostgreSQL 13 update accordingly, but before you do, do you feel comfortable recommending to someone who doesn’t know what bash is that they do it that way? You’re sure that it won’t hose their database and their site will be ruined forever?
The idea is that if some other good information is presented that it be added to the OP rather than asking people to read through year’s worth of posts that are likely to be unhelpful or wrong.
No I’m not sure, I don’t have much experience with postgres and was hoping one of the discourse devs could provide some assurances it would work.
Even if it does work I also wouldn’t recommend it as the default upgrade procedure as the old way keeps a separate copy of the DB for rollback. If it works it would be a great option for space-constrained environments though.
Another easy way is to spin up a new server, migrate the data, and turn off the old one. If you must use the old one, do the upgrade on a temporary server, so a fresh install on the original server (which probably needs an OS upgrade) and move it back.
That’s safe, easy, and well documented. Hundreds of people have done that.
Yes, but that would take a day or two. During that time we could either a) tell users their posts during this period will be lost or b) set the forum read-only. Neither is a great solution.
I don’t think that the server would be down a whole lot longer than during the rebuild. And if you move to the new server and stay there, you can leave the old server in read only mode while you make the move. If downtime is your concern then moving to a new server will be much, much better.
We have a pretty big forum, but I’ve never tried restoring a backup so I don’t know how long it would take. We would indeed stay on the new host if we did it. I would like to avoid that due to the extra work/annoyance if possible.
طريقة أخرى لحل مشكلة الترقية مع مساحة محدودة هي عمل نسخة احتياطية، وحذف دليل postgres باستخدام rm -r، وإعادة البناء، ثم استعادة النسخة الاحتياطية. لقد قمت بذلك في موقع الأسبوع الماضي.
لا، لم أحصل عليه مطلقًا على ترقية. حذف قاعدة البيانات واستعادة النسخة الاحتياطية يبدو محفوفًا بالمخاطر للغاية. نحتاج إلى الترقية في مكانها لتعمل، بشكل أساسي.
نحن نشغل أوبونتو 18.04 والذي سيتم إيقاف دعمه في عام 2023، لذا أعتقد أنه في تلك المرحلة لن يكون لدينا خيار سوى الانتقال إلى مضيف جديد على أي حال، ونخطط لتحمل العبء حينها، وبناء مضيف جديد يعمل بنظام 22.04 LTS، واستعادة من النسخة الاحتياطية.
هممم. قد يكون الأمر غير مهم. أعتقد أنه مع النموذج الاحتياطي، يتم ضغط أحد النسخ، مما قد يحدث فرقًا؟ وكان الموقع الذي قمت به يحتوي على نسخ احتياطية على S3. وكان موقع اختبار، لذا كانت المخاطر منخفضة إذا كانت هناك مشكلة.
باستثناء أن النسخ الاحتياطية تُستخدم كثيرًا وفي مواقف أكثر بكثير من الترقية في المكان. أعتبرها أكثر أمانًا بكثير.
ربما، ولكن ليس لدي خبرة كبيرة مع بوستجريس ولا أشعر بالراحة للقيام بذلك. استعادة الموقع بالكامل من النسخ الاحتياطي على جهاز افتراضي مختلف تمامًا، هذا أشعر بالراحة للقيام به، ومع ذلك سيعني ذلك فقدان المشاركات لعدد الساعات التي تستغرقها الاستعادة، لذلك لست متحمسًا جدًا لذلك أيضًا. ولكن نظرًا لأن 18.04 لم يعد مدعومًا، فلن يكون لدي الكثير من الخيارات العام المقبل.
ما لم تكن قاعدة بياناتك بحجم عشرات الجيجابايت، فلن يستغرق الأمر ساعات. وستضع المنتدى في وضع القراءة فقط قبل إجراء النسخ الاحتياطي والاستعادة، لذلك لن تفقد أي مشاركات. الأمر ليس بهذه الصعوبة مع وقت قراءة فقط يكاد يكون معدومًا.
بحلول ذلك الوقت، سيكون لديك أيضًا إمكانية الوصول إلى الدردشة المضمنة في Discourse، وهي ميزة سيتم إصدارها في 2.9 (ربما تكون معطلة افتراضيًا، ولكنها في مرحلة تجريبية ومدعومة للاستخدام).