نقل موقع Discourse إلى VPS آخر باستخدام rsync

ويكي المجتمع Sysadmins
,
21

أهلاً!

أحاول اتباع الخطوات التي وضعها @scottfsmith. لقد تمكنت من إنجاز عملية rsync. لا يهمني الحصول على أحدث التغييرات عبر rsync لأنني فقط أختبر إصدارًا جديدًا من لينكس مع موقعي الحالي لمعرفة ما إذا كانت جميع إضافاتي تعمل. لذلك، لن أقوم بتشغيل rsync للمرة الثانية. ثم يؤدي تشغيل ./launcher rebuild app إلى ظهور أخطاء.

2022-12-13 14:43:01.974 UTC [59] LOG:  database system was interrupted; last known up at 2022-12-13 10:23:29 UTC
2022-12-13 14:43:02.075 UTC [59] LOG:  invalid primary checkpoint record
2022-12-13 14:43:02.075 UTC [59] PANIC:  could not locate a valid checkpoint record
2022-12-13 14:43:03.137 UTC [56] LOG:  startup process (PID 59) was terminated by signal 6: Aborted
2022-12-13 14:43:03.137 UTC [56] LOG:  aborting startup due to startup process failure
2022-12-13 14:43:03.231 UTC [56] LOG:  database system is shut down
I, [2022-12-13T14:43:06.699692 #1]  INFO -- : 
I, [2022-12-13T14:43:06.711862 #1]  INFO -- : > su postgres -c 'createdb discourse' || true
createdb: error: could not connect to database template1: could not connect to server: No such file or directory
	Is the server running locally and accepting
	connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?
I, [2022-12-13T14:43:06.917008 #1]  INFO -- : 
I, [2022-12-13T14:43:06.917421 #1]  INFO -- : > su postgres -c 'psql discourse -c "create user discourse;"' || true
psql: error: could not connect to server: No such file or directory
	Is the server running locally and accepting
	connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?
I, [2022-12-13T14:43:07.007654 #1]  INFO -- : 
I, [2022-12-13T14:43:07.008155 #1]  INFO -- : > su postgres -c 'psql discourse -c "grant all privileges on database discourse to discourse;"' || true
psql: error: could not connect to server: No such file or directory
	Is the server running locally and accepting
	connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?
I, [2022-12-13T14:43:07.087098 #1]  INFO -- : 
I, [2022-12-13T14:43:07.087319 #1]  INFO -- : > su postgres -c 'psql discourse -c "alter schema public owner to discourse;"'
psql: error: could not connect to server: No such file or directory
	Is the server running locally and accepting
	connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?
I, [2022-12-13T14:43:07.167221 #1]  INFO -- : 
I, [2022-12-13T14:43:07.168041 #1]  INFO -- : Terminating async processes

لا أستطيع فهم الكثير من هذا للعثور على حل. تشير بعض عمليات البحث إلى أن الحاوية تحتاج إلى الإيقاف ولكنها لم تبدأ بعد. أي أفكار؟

شكراً
ديفيد

22

يمكنك إعداد خادم تدريجي لحل مشكلتك المحددة.

من تلك الأخطاء، يبدو أن قاعدة البيانات معطلة. تحتاج إلى إيقاف قاعدة البيانات لتتمكن من الحصول على مجموعة بيانات صالحة لكي تعمل. النسخة الثانية من rsync ليست اختيارية.

إعجاب واحد (1)
23

رائع!
موضوع عمره أربع سنوات ورد خلال 3 دقائق! :slight_smile:
على أي حال، إنه في الأساس خادم مرحلي أستهدفه وأستخدم طريقة rsync هذه. ولكن هل توصي بعدم القيام بذلك بهذه الطريقة باستخدام rsync ولكن باستخدام نسخة احتياطية؟ أتذكر أنني لم أحصل على جميع إعدادات التخصيص من خادم مرحلي سابق قمت بإعداده، ولكن ربما أكون مخطئًا.
شكرًا

إعجاب واحد (1)
24

هذا ما يصفه هذا الرابط.

كل شيء، باستثناء المكونات الإضافية (الموجودة في app.yml الخاص بك)، موجود في النسخة الاحتياطية؛ قاعدة البيانات والمرفقات هما كل ما في الأمر.

إعجاب واحد (1)
25

من اختباري لهذه الطريقة، يبدو أنها كافية لتشغيل ./launcher stop app قبل عملية rsync الأولية. بالطبع، أحد أسباب استخدام هذه الطريقة هو إبقاء المنتدى قيد التشغيل على الخادم القديم لأطول فترة ممكنة، وفي هذه الحالة، من الواضح أنه من الضروري تشغيل عملية rsync الثانية للحفاظ على الاتساق. ولكن بالنسبة للعملية الشائعة نسبيًا لنقل منتدى إلى خادم و/أو مضيف مختلف حيث يكون التوقف القصير مقبولاً، فإنني حقًا أحب بساطة وقابلية نقل هذه الطريقة.

إعجاب واحد (1)
26

صحيح.

صحيح.

طريقتي المفضلة هي إجراء مزامنة لشهادات Let’s Encrypt و SSL، ووضع الخادم القديم في وضع القراءة فقط، وأخذ نسخة احتياطية، واستعادتها على الخادم الجديد، ثم تبديل نظام أسماء النطاقات (أو الأفضل، عنوان IP ثابت عندما يكون الخادم الجديد جاهزًا.

ولكن إذا لم تكن تهتم بفترة توقف قصيرة، فطريقتك رائعة.

إعجابَين (2)
27

أخطط للانتقال إلى خادم افتراضي خاص جديد (VPS) في يناير بعد بعض المشاكل الأخيرة في ترقية Discourse على نظام Ubuntu القديم الخاص بي.

أسئلتي حول الانتقال من خادم Digital Ocean قديم إلى خادم Digital Ocean جديد هي:

  • أخطط لخفض قيمة TTL لسجل DNS A قبل يوم من الترحيل إلى شيء صغير، مثل 5 دقائق. هل هذا يبدو معقولاً؟

  • تم تعديل المنشور الأول في هذا الموضوع آخر مرة في يونيو 2016. هل لا يزال صالحًا وصحيحًا؟

  • هل ستنسخ طريقة rsync هذه أيضًا قاعدة البيانات بأكملها من الخادم الافتراضي الخاص القديم إلى الخادم الافتراضي الخاص الجديد؟
    – نحن نستخدم تثبيتًا قياسيًا

  • هل سيتم نسخ شهادة SSL الحالية من Let’s Encrypt أيضًا؟ هل شهادة SSL مرتبطة بعنوان IP بأي شكل من الأشكال؟ هل ستستمر في التجديد تلقائيًا؟ أي مشاكل هنا؟

  • في أي نقطة يجب أن أغير سجل DNS العام A ليشير إلى الخادم الافتراضي الخاص الجديد؟
    – وأيضًا تغيير TTL مرة أخرى إلى شيء أعلى

28

كل هذا صحيح.

إذا كنت تستخدم شيئًا يسمح لك بالحصول على عنوان IP دائم يمكن تعيينه لأجهزة افتراضية متعددة، فيمكنك القيام بذلك حتى لا تعتمد على نظام أسماء النطاقات (DNS) لإجراء التبديل.

التحذير الوحيد الذي يمكنني إضافته هو إيقاف تشغيل الموقع القديم لعملية rsync النهائية ثم إعادة تشغيله في وضع القراءة فقط أثناء إعادة بناء الموقع الجديد.

29

لا يزال المنشور الأول يعرض المسار /var/discourse/ غير الصحيح:

هل يمكنك التعديل/التحديث من فضلك؟

30

@Richie، @JammyDodger جعل هذا الآن ويكي :+1:

إعجابَين (2)
31

لقد انتقلت إلى خادم افتراضي خاص جديد اليوم وفكرت في مشاركة تجاربي حيث يبدو أن عددًا لا بأس به من الأشخاص يواجهون مشكلة نظام التشغيل القديم في تحديثاتهم مؤخرًا :blush:

أنا على Digital Ocean، لذا أنشأت قطرة جديدة.

خادم افتراضي خاص قديم = Ubuntu Server 18.04.6 LTS

خادم افتراضي خاص جديد = Ubuntu Server 23.10

لقد قمت بالصيانة المعتادة على الخادم الافتراضي الخاص الجديد - يرجى التعديل حسب ما يناسبك:

Apt-get update

Apt-get upgrade

Apt-get install fail2ban

ufw default deny incoming

ufw default allow outgoing

ufw allow ssh

ufw allow http

ufw allow https

ufw enable

ثم قمت بإنشاء دليل فارغ جديد لـ Discourse:

sudo mkdir -p /var/discourse

ثم قمت بتثبيت Docker:

wget -qO- https://get.docker.com/ | sh

ثم قمت بتغيير TTL على DNS الخاص بي من 30 دقيقة إلى 10 دقائق (الحد الأدنى الذي تسمح به GoDaddy).

على الخادم القديم، قمت بتنزيل نسخة محلية من النسخة الاحتياطية لقاعدة بيانات Discourse الليلة الماضية (لا يمكنك أبدًا الحصول على نسخ احتياطية محلية كافية). قمت أيضًا بتنزيل نسخة من app.yml إلى جهاز الكمبيوتر المحلي الخاص بي أيضًا.

كما اقترح عدد قليل من الأشخاص أعلاه، قمت بإجراء مزامنة “من جذر إلى جذر”. استخدمت عنوان IP بدلاً من اسم المضيف، حتى أتمكن من تجنب أي ارتباك في DNS. كما تم اقتراحه أعلاه، استخدمت مفاتيح -avz:

rsync -avz root@old.ip.address.here:/var/discourse /var

للرجوع إليها، مجلد Discourse الخاص بي هو 25 جيجابايت.

استغرق الأمر حوالي 25 دقيقة للمزامنة من الخادم القديم إلى الخادم الجديد. كان هذا ببساطة بين قطرتين من Digital Ocean في نفس منطقة LON1. قد تختلف تجاربك.

بعد المزامنة ومحاولة إعادة البناء، واجهت نفس الخطأ الذي واجهه @piratdavid بخصوص postgres database system is shut down.

لذا قمت بإيقاف التطبيق على الخادم الافتراضي الخاص القديم:

./launcher stop app

وقمت بمزامنة أخرى، للتغييرات فقط هذه المرة:

rsync -avz --delete root@old.ip.address.here:/var/discourse /var

ثم قمت بتشغيل تطبيق Discourse القديم مرة أخرى ووضعته بسرعة في وضع الصيانة - هذا حتى يتمكن الأشخاص من الوصول إليه وسيظهرون رسالة تحذير الصيانة المعتادة.

هذا يمنحني أيضًا بعض الوقت للعمل على الخادم الافتراضي الخاص الجديد :blush:

لقد قمت بتحديث ملف HOSTS الخاص بي على جهاز الكمبيوتر المحلي الخاص بي حتى أتمكن من الوصول إلى Discourse على الخادم الافتراضي الخاص الجديد دون تحذيرات / مشاكل في المتصفح.

على الخادم الافتراضي الخاص الجديد، قمت بتشغيل:

./discourse-setup

كان هذا حتى يتمكن من تحديث إعدادات الذاكرة العشوائية ووحدة المعالجة المركزية في ملف app.yml تلقائيًا.

ثم قمت بإعادة بناء التطبيق على الخادم الافتراضي الخاص الجديد:

./launcher rebuild app

قمت ببعض الاختبارات السريعة، كل شيء على ما يرام.

تم تحديث DNS - تم الانتهاء من المهمة.

شكرًا على الموضوع المفصل، أيها الجميع :smiley:

3 إعجابات
32

شكرًا يا رفاق، تم تحديث المنشور الأول بخصوص المسارات /var/discourse.

إعجاب واحد (1)
33

إذا كان أي شخص يواجه مشكلة في إجراء مزامنة rsync من الجذر إلى الجذر لأنه ربما قام بتعطيل تسجيل الدخول كجذر على الخادم القديم، أو كنت ترغب فقط في القيام بذلك كمستخدم غير جذر، فقد وجدت هذه المشاركة مفيدة لمعرفة كيفية استخدام sudo على الخادم البعيد: https://askubuntu.com/questions/719439/using-rsync-with-sudo-on-the-destination-machine

لنفترض أن لديك مستخدمًا، discourse، على كلا الجانبين لديه امتيازات sudo. على الجهاز البعيد، ستقوم بتحرير ملف /etc/sudoers باستخدام sudo visudo. ستقوم بإضافة السطر:

discourse ALL=NOPASSWD:/usr/bin/rsync

ثم على الجهاز الجديد، ستقوم بتشغيل (كمستخدم غير جذر الخاص بك):

sudo rsync -avz --delete --rsync-path="sudo rsync" discourse@old.ip.address.here:/var/discourse /var

سيسمح لك هذا بتشغيل كل ما هو موصوف هنا كمستخدمين غير جذر. إذا كنت تحتفظ بالخادم القديم، فسأعود إلى ملف /etc/sudoers وأحذف السطر الذي أضفته للتو.

إعجاب واحد (1)
34

إذا فهمت بشكل صحيح، فإن هذا يسمح بالجزء الأكبر من النقل بالحدوث أثناء تشغيل Discourse. تتطلب استراتيجية الاستعادة من النسخ الاحتياطي الحد الأدنى من الوصول للقراءة فقط للنسخة الاحتياطية ونقل النسخة الاحتياطية إلى الخادم الجديد (أو النقل عبر حاوية S3). بالنسبة للمواقع الكبيرة، يمكن أن يؤدي هذا إلى وقت قراءة فقط كبير تتجنبه استراتيجية rsync بشكل أنيق.

قد يكون من الممكن زيادة وقت التشغيل قليلاً عن طريق تجنب إيقاف تشغيل PostgreSQL على النظام القديم و"إصلاح" المشكلة على النظام الجديد باستخدام pg_resetwal. ملاحظة: لم أجرب هذا، ومن شبه المؤكد أن السماح لقاعدة البيانات بالإغلاق بشكل طبيعي هو فكرة أفضل.

أتساءل عما إذا كانت هناك طريقة لبدء تشغيل Discourse في وضع القراءة فقط؟ أظن أن أسرع طريقة هي عبر سطر الأوامر بعد تشغيل الحاوية.

على أي حال، شكرًا لك على إبلاغنا بتجربتك! يبدو أنها عملية مفيدة للاحتفاظ بها. :slight_smile:

35

جداً.

مفيدة لدرجة أنني أفكر في القيام بذلك مرة أخرى لإنشاء بيئة اختبار (على خادم افتراضي خاص بمواصفات أقل)، فقط للاختبار واستباق أي مشاكل قبل تطبيق أي تغييرات على بيئة الإنتاج.

إعجاب واحد (1)
37

مرحباً،

أنا في منتصف محاولة هذه العملية على نسخة قديمة من Discourse أصبحت الآن مسؤولة عن صيانتها - الانتقال من Ubuntu EOL إلى شيء أحدث لأن أي ترقية تفشل إذا حاولت القيام بها في مكانها - وعلى الرغم من نجاح rsync، فشل postgres في التشغيل مشيراً إلى مشاكل في ملكية الملفات. تشغيل rsync كـ root مع خيارات الحفاظ على الملكية لم يصحح هذا (ملكية الملفات والأذونات تتطابق الآن مع المصدر، لقد تحققت)، وبسبب فشل bootstrap وليس لدي حاوية قيد التشغيل، لا يمكنني محاولة إصلاح هذا كما يصف Update failed (postgresql) - #7 by noezDE.

ما هي أفضل طريقة لتطبيع ما يتوقعه postgres؟

38

هل يمكنك chown الملفات خارج الحاوية؟ يجب أن يكون ذلك ممكنًا إذا كانت لديك أذونات الجذر/sudo.

39

بالتأكيد، ولكن إلى ماذا؟ من خارج الحاوية، الأذونات صحيحة تمامًا وهي أيضًا هراء صارخ.

المصدر (يعمل):

root@ip-[...]:/var/discourse/shared/standalone# ls
total 54492
drwxr-xr-x 15 root       root         4096 Oct 22  2021 .
drwxr-xr-x  3 root       root         4096 Feb 28  2017 ..
drwxr-xr-x  3 ubuntu     www-data     4096 Feb 28  2017 backups
-rw-r--r--  1 root       root     55730645 Mar 15  2017 discussion.json
drwx------  7 root       root         4096 Mar  6  2017 letsencrypt
drwxr-xr-x  4 root       root         4096 Feb 28  2017 log
drwxr-xr-x  2 _apt       netdev       4096 Feb 28  2017 postgres_backup
drwx------ 19 _apt       netdev       4096 Sep 15 04:39 postgres_data
drwx------ 20 _apt       netdev       4096 Oct 22  2021 postgres_data_old
drwx------ 20 messagebus uuidd        4096 Apr  5  2018 postgres_data_older
drwxrwsr-x  5 _apt       netdev       4096 Sep 15 04:39 postgres_run
drwxr-xr-x  2 lxd        lxd          4096 Sep 16 01:03 redis_data
drwxr-xr-x  2 root       root         4096 Mar  6  2017 ssl
drwxr-xr-x  4 root       root         4096 Feb 28  2017 state
drwxr-xr-x  4 ubuntu     www-data     4096 Sep 15 04:39 tmp
drwxr-xr-x  5 ubuntu     www-data     4096 Apr 13  2017 uploads

الوجهه (معطل):

root@ip-[...]:/var/discourse/shared/standalone# ls -al
total 54488
drwxr-xr-x 15 root       root         4096 Sep 15 04:31 .
drwxr-xr-x  3 root       root         4096 Sep 15 04:27 ..
drwxr-xr-x  3 ubuntu     www-data     4096 Sep 15 04:27 backups
-rw-r--r--  1 root       root     55730645 Sep 15 04:27 discussion.json
drwx------  7 root       root         4096 Sep 15 04:27 letsencrypt
drwxr-xr-x  4 root       root         4096 Sep 15 04:27 log
drwxr-xr-x  2 _apt       netdev       4096 Sep 15 04:27 postgres_backup
drwx------ 19 _apt       netdev       4096 Sep 15 04:27 postgres_data
drwx------ 20 _apt       netdev       4096 Sep 15 04:30 postgres_data_old
drwx------ 20 messagebus uuidd        4096 Sep 15 04:31 postgres_data_older
drwxrwsr-x  5 messagebus tss          4096 Sep 15 04:31 postgres_run
drwxr-xr-x  2 uuidd      _ssh         4096 Sep 15 04:38 redis_data
drwxr-xr-x  2 root       root         4096 Sep 15 04:32 ssl
drwxr-xr-x  4 root       root         4096 Sep 15 04:31 state
drwxr-xr-x  4 ubuntu     www-data     4096 Sep 15 04:31 tmp
drwxr-xr-x  5 ubuntu     www-data     4096 Sep 15 04:31 uploads

أفترض أن هذه المعرفات قد تكون منطقية أكثر داخل الحاوية، ربما؟

40

نعم، لقد حاولت فرض الأرقام التعريفية الرقمية من ls -aln وما زلت أحصل على نفس الفشل.

2024-09-16 01:21:27.237 UTC [36] FATAL:  data directory "/shared/postgres_data" has wrong ownership

لا أعرف ما الذي يريده.

41

أعتقد أنني واجهت خطأً مشابهاً مؤخراً.

أحد التخمينات هو أن الحاوية القديمة والحاوية الجديدة تحتويان على إدخالات مختلفة في ملف /etc/passwd. يمكنك مقارنة هذين الملفين، على ما أعتقد.

أعتقد أن أفضل ما يمكنك فعله هو الاستعادة من نسخة احتياطية. لا أتذكر ما إذا كنت قد فعلت ذلك أم أنني جعلت شيئاً ما 777.