الافتراضات ضائعة بعد الاستعادة. كيف يمكن استعادتها؟

لقد قمت بتثبيت discourse بشكل نظيف واستعدت النسخة الاحتياطية التي أُخذت في نفس الليلة (باستخدام واجهة discourse لإجراء النسخة الاحتياطية والاستعادة).

تم عمل النسخة الاحتياطية لقاعدة البيانات والملفات المرفوعة.

بعد الاستعادة وإعادة بناء تطبيق discourse (كما أفترض أنه كان ضروريًا بسبب التغييرات في الإعدادات الناتجة عن التثبيت النظيف)، واجهنا مشكلة.

فقدت صور الرموز الشخصية (الصور الرمزية) لجميع المستخدمين الذين قاموا بتخصيص صورة ملفهم الشخصي.

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

ولكنني لم أتمكن من العثور على الخطوة المفقودة.

لقد وجدت موضوعًا لأشخاص فقدوا الرموز الشخصية الافتراضية (التي تأتي مع discourse)، لكن هذه ليست حالتنا؛ فالأشخاص الذين لم يغيّروا رموزهم الشخصية (ولم يرفعوا صورة) لا يزالون يملكون رمزهم الحرفي في مكانه.

تحديث:

لقد قمت بتشغيل الأمر التالي:
./launcher enter app
rake posts:rebake

ولكنه لم يُجدِ نفعًا.

هل قد يكون الأمر ليس posts:rebake؟

@arinaf،

من الغريب أن نفس الأمر حدث لي اليوم في إعداد يستخدم عكس nginx كوكيل عكسي لاتصال socket من نوع unix. كان كل شيء مثالياً، لكن صور الرموز التعريفية المخصصة كانت تظهر كأيقونات (أيقونة الشخص)، بينما كانت رموز الأحرف على ما يرام.

أثناء استكشاف المشكلة، عدت إلى إعداد قياسي مكون من حاويتين (بدون واجهة أمامية nginx وبدون socket من نوع unix)، فاختفت المشكلة.

ثم عدت إلى إعداد عكس nginx كوكيل عكسي لاتصال socket من نوع unix، فعدت المشكلة أيضاً.

أنا في حيرة من أمري… لذا سأأخذ استراحة لفترة :slight_smile:

من الواضح أن البيانات سليمة لأنها تعمل بشكل مثالي بدون عكس nginx كوكيل عكسي، وهو أمر غريب لأنها تعمل بشكل جيد بدونه. LOL. (كان كل شيء يعمل بلا عيب في كلا الحالتين وفجأة ظهرت مشكلة الرموز التعريفية الغريبة…)

هذا هو تكويني تمامًا، حيث أقوم بتشغيل برامج أخرى في حاوية Docker (مدونة Ghost).
أستخدم nginx كعكسي للوكيل.

من الواضح أن استعادة النسخ الاحتياطية ليس أمرًا مباشرًا كما يبدو.

لقد قمت بإعادة التهيئة، حيث اعتقدت أنها مشكلة في عدم حفظ الصور المصغرة، لكن دون جدوى.

سأجرب ما تقوله للتأكد مما إذا كانت المشكلة تتعلق بالعكسي للوكيل (لا أعرف لماذا يمكن أن يتداخل ذلك، لكنني لا أخسر شيئًا بالمحاولة).

نعم… لا أعتقد أن المشكلة تتعلق بقاعدة البيانات الخلفية أو استعادتها (أو أمر Rake).

بمجرد إيقاف الوكيل العكسي وتشغيل حاويتين بدونه، تختفي المشكلة. وبما أن قاعدة البيانات هي نفسها في جميع الحالات، فمن غير المرجح أن تكون المشكلة متعلقة بقاعدة البيانات.

سأكون غير متصل بالإنترنت لمدة 12 ساعة، لذا سأعود لاحقًا لأرى ما حدث في إعدادك @ariznaf

هل تستخدم HTTPS خارج الحاوية؟

هل تفحصت مصدر الصفحة لمعرفة الروابط المستخدمة للصور الرمزية؟

يبدو أن force_https غير مفعّل.

لا أستطيع القيام بذلك الآن، إذ يجب أن أبدأ من الصفر مرة أخرى.

لقد حاولت نسخ جميع الملفات (مع إيقاف discourse في المصدر) لكن ذلك لم ينجح أيضًا (مشاكل في قاعدة البيانات).

سأحاول البدء من جديد، وتثبيت discourse نظيف، ثم استعادة النسخة الاحتياطية التي تم إنشاؤها باستخدام discourse.

سأتحقق، شكرًا لك.

يبدو أن محاولة استعادة قواعد البيانات أو نقلها من مضيف إلى آخر أصعب مما هو متوقع.

شكرًا لكما.

طالما أنك لا تستخدم وكيلًا عكسيًا، وتم إعداد منصة الوجهة بشكل صحيح وتمثلها بشكل دقيق، فإن العملية تكون عادةً بسيطة للغاية.

حسنًا، باستثناء إذا كان هناك تحديث لـ Discourse نفسه أو للإضافات التي تستخدمها (أنا أستخدم فقط بضع إضافات رسمية + معاينات قائمة المواضيع وبعض المكونات)، فكلما حاولت محاكاة استعادة، واجهت نوعًا من المشاكل. أشعر أن نظام النسخ الاحتياطي سهل ومباشر، لكنه ليس قويًا بما يكفي عند نقل كل شيء إلى خادم آخر. كما أنه ليس مرنًا بما يكفي. يستغرق وقتًا طويلاً جدًا للانتهاء (لموقع ليس كبيرًا جدًا، فإن النسخ الاحتياطي الكامل يبلغ 3 جيجابايت فقط). كان لدينا في المنتدى القديم أكثر من 100 جيجابايت من البيانات، وكان من المستحيل عمل نسخة احتياطية لموقع بهذا الحجم باستخدام النظام الحالي.

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

آه، حسنًا.
شكرًا جزيلاً.
لم أكن أعرف أنهم يعاد بناءهم في الخلفية.
إذن الأمر يتعلق بالانتظار.

كنت أغضب من استخدام rake posts:rebuild وأشياء من هذا القبيل.

لقد أنقذتني من الكثير من المتاعب. شكرًا جزيلاً.

يمكنك تسريع العملية بالانتقال إلى /sidekiq/scheduled في منتداك والضغط على زر “Trigger” بجوار مهمة CreateMissingAvatars.

واو، هناك عالم كامل مخفي هناك في /sidekiq :slight_smile:

لقد جربت ما اقترحته.

لكن مهمة CreateMissingAvatars مُجدولة وتعمل، لكنها تتوقف تقريبًا على الفور، حيث تستغرق بضع مللي ثوانٍ فقط للإكمال. لقد حاولت تشغيلها يدويًا (باستخدام Trigger) لكنها تتوقف مرة أخرى على الفور بنتيجة OK.

لكن الصور الرمزية لا تزال خاطئة.
كنت أستخدم الآن إعداداتي الأصلية، مع استماع discourse على منفذ (socket) و nginx كوكيل عكسي (reverse proxy).

سأحاول الآن إزالة nginx وتشغيل discourse على المنافذ 80 و 443.

مرحبًا @ariznaf

استيقظت هذا الصباح بعد أن كنت خارج الشبكة لمدة 12 ساعة، وعُدت إلى إعداداتنا socket-only.yml، فكل شيء عاد إلى طبيعته مرة أخرى.

إذن، على الأقل في طرفنا من عالم discourse الشاسع، كل شيء على ما يرام في أرض الحاويتين مع nginx كعكس عكسي للاتصال بمقبس يونكس مرة أخرى.

كاننا قد انتقلنا إلى إعدادات الواجهة الأمامية باستخدام nginx قبل حوالي ست ساعات من ملاحظة الشذوذ، وكان كل شيء على ما يرام.

بناءً على هذه التلميح المفيد من @riking (كما هو معتاد، شكراً جزيلاً لكين)

صور الرموز الشخصية المُعاد تدويرها المختلفة غير مدرجة في النسخة الاحتياطية، بل الصور الأصلية فقط. سيستغرق الأمر بعض الوقت حتى تكتمل المهمة المجدولة وتوليد الإصدارات المُعاد تدويرها لكل رمز شخصي.

Screen Shot 2020-04-17 at 9.06.09 AM

أفضل تخمين لي هو أنه عندما قمنا بـ التحويل إلى nginx، لم نلاحظ أي مشاكل لأن صور الرموز الشخصية العديدة كانت مُخزنة بالفعل في الذاكرة المؤقتة، ولم تكن عملية إعادة التوليد قد انتهت بعد؛ لذا مع مرور الوقت، انتهت صلاحية التخزين المؤقت لتلك الصور وبدأ الشذوذ في الظهور.

لذلك، غادرتُ الشبكة (ولا يزال حاوية socket-only.yml تعمل في الخلفية، غير نشطة) لمدة 12 ساعة، واستيقظتُ في الصباح، وقد قام sidekiq بسحره خلال الليل (هنا) كما فعل @riking (دعم رائع، بالمناسبة، كين، في كل موضوع هنا في meta).

يبدو أن هذا السيناريو يؤكد ما اقترحه @riking.

بصراحة، كلما استخدمنا Discourse أكثر، كلما أحببناه أكثر. فالنتوءات والشذوذات مثيرة للاهتمام جدًا، وإعداد الحاويتين رائع حقًا.

تبدو حاوياتنا حاليًا كما يلي:

# ls -l containers
-rw-r--r-- 1 discourse root 1124 Apr 15 11:29 data.yml
-rw-r--r-- 1 discourse root 3939 Apr 16 07:45 socket-only.yml
-rw-r--r-- 1 discourse root 3784 Apr 16 07:28 socket.yml
-rw-r--r-- 1 discourse root 3921 Apr 15 11:50 web-only.yml

ما أعجبه في هذا هو أنه حتى عندما نواجه مشكلة، مثل شذوذ إعادة توليد الرموز الشخصية هذه، يمكننا التبديل بسهولة ذهابًا وإيابًا بين socket-only.yml و web-only.yml.

في هذه الحالة، عدنا إلى web-only (أثناء عملية إعادة التوليد هذه)، ثم عدنا إليها بعد انتهاء العملية (لأن جميع الحاويات لا تزال تعمل). وعندما نقوم بإعادة بناء الحاوية، يمكننا التبديل بين هذه الحاويات والإعدادات بسهولة تامة.

بعد عقدين من تشغيل منتدى LAMP، أصبحنا أكثر إعجابًا بـ Discourse، من جانب إدارة النظام.

شريط جانبي (رأي تحريري):

بالطبع، هذا فوق مستواي هنا في meta، لكنني أعتقد أن إعداد الحاويتين الأساسي (بدون عكس عكسي) يجب أن يكون الافتراضي، لأنه سهل الإعداد جدًا، ونكسب منه أكثر بكثير من أي “عقوبة” متصورة لوجود ملفين yml.

من جهتي، جربت استعادة النظام باستخدام نسخة الاحتياطية التي تم إنشاؤها عبر الواجهة فقط.

وكما ذُكر، فقدنا صور الرموز التعريفية (الأفاتار) وبعض الأمور الأخرى البسيطة.

حاولت اتباع الإرشادات التي قدمها @riking، لكن دون جدوى.

جربت تحديث صور الأفاتار بإجبار عملية التنفيذ، لكن انتهى الأمر بحالة “OK” بعد بضع ميلي ثوانٍ دون أن يتم توليد الصور.

وبما أننا كنا مستعجلين في نقل المحتوى، أوقفت المنتدى على الخادم القديم، ونقلت جميع المحتوى في الحاويات والمجلدات المشتركة باستخدام tar، ثم ثبّتت discourse على الخادم الجديد (دون إجراء الإعداد الأولي)، ونقلت هناك المجلدات المشتركة ومجلدات الحاويات، وأعدت بناء التطبيق.

الآن، يعمل كل شيء على الخادم الجديد.

لقد أصبحت عملية الاستعادة من نسخة احتياطية أكثر إشكالية مما توقعت (رغم أنها تبدو مباشرة بناءً على تعليمات إعادة التثبيت والاستعادة عبر الواجهة).

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

أحب discourse كثيرًا.
فمنذ انتقالنا من منتديات تقليدية أخرى، نجد أحيانًا صعوبة في العثور على ما نريده.
والواجهة النظيفة لا تساعد في هذه الحالات.

لكن عندما تجد ما تبحث عنه أخيرًا، ستجده في مكانه الصحيح وتعمل الأمور بطريقة ذكية.

نحن نواجه مشاكل فقط مع الاستعادة من نسخة احتياطية.
وأحيانًا مع الاستخدام المكثف للذاكرة المؤقتة (Caching).

يستغرق discourse وقتًا للتحميل لأول مرة في متصفحك، لكن بعد ذلك يعمل بسرعة، لأن معظم المعالجة تتم على جهازك، ويستخدم كمية كبيرة من التخزين المؤقت (صور الأفاتار، الصور، ملفات CSS…).
التطبيق لا يسترجع المعلومات الموجودة بالفعل على جهازك، مما يوفر الكثير من العمل على الخادم (على الأقل هذا ما يبدو لي بناءً على تجربتي).

عندما أحاول الانتقال من خادم إلى آخر، أو إعادة تثبيت discourse من الصفر، أستمر في رؤية المحتوى القديم حتى لو قمت بتحديث العرض.

لم أستطع التخلص من ذلك حتى قمت بمسح سجل التصفح في المتصفح.
وهذا شغلني وأربكني لفترة طويلة.

بالمناسبة، هل تُحفظ صور الأفاتار إذا اخترت حفظ الصور المصغرة المحفوظة في النسخة الاحتياطية؟
هل تعتقد أنه من الأفضل حفظها؟
منتدانا ليس كبيرًا جدًا، لكن حفظ 36000 صورة استغرق وقتًا طويلاً.

مرحبًا @ariznaf،

حجم نسخنا الاحتياطي الكامل هو نفسه، حوالي 3 جيجابايت مضغوطة بالكامل بصيغة gzip.

حتى الآن، لم أواجه أيًا من المشاكل التي ذكرتها في منشورك (فوق هذا مباشرة، #13).

هل تستعيد من سطر الأوامر أم من واجهة المستخدم؟

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

هذا خبر سار. تهانينا.

شكرًا لاهتمامك.

لقد اتبعت التعليمات الواردة في الدروس التوجيهية باستخدام الواجهة. لكنني لا أعرف كيفية الاستعادة من سطر الأوامر (للنسخ الاحتياطية التي تم أخذها باستخدام واجهة Discourse).

دعني أشرح:

كان عليّ نقل الخادم من a.domain.com إلى b.domain.com.
يتم الوصول إلى منتدى Discourse عبر HTTPS باستخدام شهادة SSL مخصصة (لدينا شهادات SSL نطاقية واسعة).
تم تثبيت Discourse باستخدام socket، مع تعيين HOST NAME إلى a.domain.com.
قمنا بتكوين nginx كوكيل عكسي لإعادة توجيه حركة مرور http (المنفذ 80) بشكل دائم إلى https (المنفذ 443)، بينما تعمل https (المنفذ 443) كوكيل عكسي لحركة مرور https، مع إعادة توجيهها إلى الـ socket الذي يستمع إليه Discourse.

كان لدي نسخة احتياطية (عبر الواجهة) من a.domain.com مخزنة في سلة S3، تتضمن قاعدة البيانات والملفات المرفقة، ولكن ليس الصور المصغرة (بحجم حوالي 3 جيجابايت).

لقد قمت بتثبيت nginx ونسخت ملف التكوين من a.domain.com بعد تغيير اسم المضيف من a.domain.com إلى b.domain.com.

ثم قمت بتثبيت Discourse عن طريق استنساخه من GitHub (كما هو موصى به في دليل التثبيت خلال 30 دقيقة).
بعد ذلك، شغلت إعدادات Discourse (مع إيقاف nginx) وقمت بتكوينه باستخدام HOSTNAME b.domain.com.

ثم دخلت إلى تثبيت b.domain.com الجديد مسجّلًا الدخول كمسؤول.
باستخدام الواجهة، قمت بتكوين النسخ الاحتياطية للوصول إلى سلة S3، وقمت بتفعيل قدرات الاستعادة للمسؤول، واستعدت آخر نسخة احتياطية.

بعد ذلك، يتم تسجيل خروجك من Discourse نظرًا لوجود مستخدمين جدد، وتكوينات جديدة، وما إلى ذلك.

عدت إلى سطر الأوامر، وقمت بتحرير ملف app.yml ونسخت التكوين من الخادم الأصلي (a.domain.com) مع تغيير اسم المضيف فقط إلى b.domain.com.

ثم نفذت الأمر ./launcher rebuild all، وبعد اكتمال العملية، شغلت nginx.

تمكنت من الوصول إلى منتدى Discourse، لكن الصور الرمزية (الأفاتار) فقدت، وهناك بعض المشاكل الأخرى المتعلقة بالصور المصغرة.

شكرًا لك على هذه التفاصيل الرائعة @ariznaf

بصراحة، لست من محبي خدمات التخزين السحابي مثل S3، لذا أعتقد أنه من الأفضل أن أتخلى عن أي أفكار إضافية بما أننا لسنا “مستخدمي S3”…

تقول إن الصور الرمزية مفقودة، لكن هل قمت بفحص مصدر الصفحة لمعرفة من أين يتم طلبها؟

هل لا تزال موجودة في S3؟

لماذا كان عليك تغيير نطاقات النطاق الفرعي؟

وللتوضيح، هل قمت بتغيير كل من الخادم المادي وعنوان DNS؟

يقول ريكينغ إن النظام يجب أن يعيد بناء المصغرات. لكن المهمة بدت وكأنها اكتملت.

سأحاول مرة أخرى. الآن لقد حللتها بطريقة أخرى.

في S3، يتم حفظ النسخ الاحتياطية فقط، بينما تُخزن الصور والملفات المرفوعة محليًا.

لكن يجب أن أجري اختبارات الاستعادة لمعرفة ما هي المشكلة.
سأتحقق من المكان الذي يحاول النظام فيه استرجاع الصورة منه.

لكنه أظهر صورة كظل أبيض، لذا فإن الرابط ليس تالفًا، بل ربما قام النظام بتغييرها لأنه لا يحتوي على صورة مصغرة.