لقد قمنا ببناء واختبار forum Discourse الخاص بنا مع البحث المتعمد عن الثغرات قبل نشره بالكامل في بيئة الإنتاج. لقد قمت مؤخرًا بنقل منتدى الاختبار الذي كان مفعّلًا فيه رفع الملفات عبر S3 من خادم إلى آخر، وعند الاستعادة، تم إعادة كتابة جميع الروابط الخاصة بأي ملف مرفق إلى رابط المنتدى بدلاً من رابط S3…
لحسن الحظ، هذا منتدى اختباري، لذا لا نهتم كثيرًا بالبيانات، ومع ذلك أود أن:
أ. أصلح هذه المشكلة.
ب. أجد طريقة لتخفيف أو منع حدوث ذلك في بيئة الإنتاج.
لم تكن المشكلة تقتصر على المنشورات فحسب، بل شملت جميع الصور والوسائط والمحتوى والصور الرمزية (وهو أمر مثير للقلق)…
قبل الاستعادة، يمكنك تكوين S3 في موقع الوجهة ضمن ملف app.yml (وليس عبر لوحة التحكم الإدارية). بمجرد التأكد من إعداد ذلك والقدرة على الوصول إلى الدلو الصحيح، يمكنك المضي قدمًا في الاستعادة، وسيتم ربط الوسائط بشكل صحيح.
لقد قمنا فعليًا بذلك، وهذا هو السبب في أننا انتهينا إلى هذا الموقف.
نسخت ملف app.yml كما كان إلى الوجهة، ثم قمت بنسخ احتياطي من الملف الأصلي. كانت المشكلة في عملية الاستعادة، حيث تم إعادة كتابة عناوين URL عند الاستعادة، على الرغم من عدم تغيير أي شيء ولا تزال عمليات تحميل S3 مفعلة.
لقد تم حل هذه المشكلة في النهاية عن طريق إعادة البناء (نعتقد ذلك، فذاكرة التخزين المؤقت في Discourse قاسية جدًا، لذا بين العديد من الحلول التي جربناها، لا نعرف فعليًا ما الذي حل المشكلة)، ومع ذلك تظل الأسئلة دون إجابة حول كيفية إجراء عمليات الترحيل بأقل قدر من المشاكل، أو حتى الاستعادة من نسخة احتياطية إذا اضطررنا إلى ذلك في بيئة الإنتاج.
يبدو أنك قمت بتكوين S3 عبر إعدادات الموقع، وليس عبر متغيرات البيئة كما اقترح كريس. تحتاج عملية الاستعادة إلى معرفة تفاصيل S3، وهذا غير ممكن باستخدام إعدادات الموقع.
يمكنك أيضًا إنشاء نسخة احتياطية دون تضمين الملفات المرفوعة من خلال وحدة التحكم إذا رغبت في ذلك: discourse backup --sql_only
لن تؤدي استعادة مثل هذه النسخة الاحتياطية إلى إعادة كتابة روابط الملفات المرفوعة. لذا، طالما أن الخادم الجديد لديه وصول إلى نفس سلة S3، فإن هذه الطريقة ستنجح.
إعدادات S3 موجودة في ملف app.yml، وليس في إعدادات الموقع.
تعديل:
أدرك أنني لا أقدم شرحًا مفصلاً بما يكفي، وليس قصدي إخفاء التفاصيل.
نحن نستخدم OVH S3 وهو مُهيأ في ملف app.yml.
قمنا بنسخ احتياطي لمنتدى الاختبار لدينا دون تضمين الملفات المرفقة، لكن S3 كان مفعّلًا في تلك المرحلة.
ثم استعدنا النسخة على الموقع الجديد بنفس ملف app.yml تمامًا، وهنا بدأت المشكلة. وللتوضيح، فقد تم حل المشكلة حاليًا، لكنني غير متأكد مما إذا كان السبب هو إعادة خبزها عدة مرات من جانبي أو بسبب التخزين المؤقت العدواني في نظام Discourse. ولهذا السبب أحتاج إلى معرفة الطريقة الصحيحة للقيام بذلك بشكل صحيح من المحاولة الأولى. مخاوفي هي أنه إذا اضطررنا يومًا ما لاستعادة نسخة احتياطية على مثيل الإنتاج الخاص بنا وواجهنا هذه المشكلة، يجب أن أعرف بالضبط كيفية إصلاحها في أسرع وقت ممكن قبل أن يلاحظ المستخدمون ذلك.
كما ذكرت، إذا كنت ترغب في الاستعادة على خادم يستخدم نفس دلو S3، فتأكد من تكوين S3 في app.yml وإنشاء نسخة احتياطية بدون الملفات المرفوعة (discourse backup --sql_only). لن يتم إعادة كتابة روابط التحميل عند عدم احتواء النسخة الاحتياطية على الملفات المرفوعة.
إذا كنت ترغب في الاستعادة على خادم يستخدم دلو S3 مختلفًا، أو لا يحتوي على تكوين S3 على الإطلاق، فاستخدم نسخة احتياطية كاملة مع الملفات المرفوعة. سيتم إعادة كتابة روابط التحميل أثناء عملية الاستعادة.
هل أنت متأكد بنسبة 100% من أنك قمت بتكوين S3 الخاص بـ OVH عبر البيئة في app.yml على الخوادم وكلاهما واستخدمت نسخة احتياطية بدون ملفات مرفوعة (امتداد ملف .sql.gz)؟
عندما استعدته في البداية بعد إكمال عمليات التحميل، تعطل بالفعل، لذا اضطررت إلى مسح كل شيء والبدء من جديد هذه المرة، مع أخذ نسخة احتياطية دون التحميلات. وهنا بدأت المشكلة. كانت الروابط لا تزال مكتوبة بشكل غير صحيح.
لست متأكدًا من كيف حدث ذلك. عملية الاستعادة تتجاوز جميع الأكواد المتعلقة بالملفات المرفوعة (بما في ذلك إعادة كتابة روابط المرفقات) عند استعادة ملف .sql.gz.
ربما نتحدث عن أشياء مختلفة؟ أنا أقصد العمود url في جدول uploads، والذي يكون عادةً //your-s3-bucket/original/... مقابل /uploads/original في البيئة المحلية.
من المحاذير المهمة عند استعادة ملف .sql.gz هو عدم إعادة كتابة أي روابط على الإطلاق. يفترض النظام أن الخادم يمكن الوصول إليه عبر نفس اسم النطاق (hostname) للخادم الذي تم إنشاء النسخة الاحتياطية منه. ستحتاج إلى إعادة تعيين الروابط إذا قمت بتغيير أسماء النطاقات.
لم يتم تغيير أسماء النطاقات. تم فقط تحديث سجلات A، مع عمل نسخة احتياطية وإنهاء المهمة.
كانت صور رموز المستخدمين مفقودة (وذلك لأنني لم أنقل مجلد التحميلات). تم إعادة كتابة صور S3 للمرفقات/الوسائط لعنوان URL الخاص بالمنتدى، وليس عنوان URL الخاص بالدلو.
لذا، بينما كنت أتوقع أن تُكتب عناوين URL لعمليات تحميل S3 المذكورة أعلاه على النحو التالي: https://some-bucket-name-here.s3.bhs.io.cloud.ovh.net/optimized، فإنها في الواقع كانت https://forum.somedomainhere.com/uploads/optimized، وهو ما لن يعمل بالطبع.
يمكنني حرفيًا تشغيل خادم افتراضي آخر مرة أخرى وإجراء استعادة مباشرة إذا أردت مني التحقق من جميع الخطوات التي قمت بها.
استعدته ببساطة من خلال استعادة النسخة الاحتياطية من ملف sql.gz المخزن في S3، وحتى الآن، الشيء الوحيد الذي تعطل هو بعض صور المستخدمين وبعض المنشورات، لكن أعتقد أن ذلك يعود إلى عدم تحميلها على S3 عند إنشائها.
في بيئة الإنتاج، بافتراض أن كل شيء يسير على ما يرام منذ الإطلاق وأن كل شيء موجود في S3… إذا قمت باستعادة النسخة الاحتياطية، فلن أواجه نفس المشكلة الغريبة التي وردت في المنشور الأول، أليس كذلك؟
