كيفية التحكم في فوضى عمليات الرفع المتغيرة من S3 إلى المحلي

الدعم
1

بعد 4-5 سنوات من الاستخدام، قررت أخيرًا استعادة ملفاتي التي تم تحميلها من سلة AWS S3 إلى خادمي المحلي لموقع الويب المحلي الصغير جدًا الخاص بي (https://BathindaHelper.com).
نظرًا لمعرفتي المحدودة، فقد عهدت بهذه المهمة إلى أحد أصدقائي مقابل مبلغ معقول جدًا. قام بتكوين الموقع للتحميلات المحلية، ولكن بطريقة ما، تعرض نصف الصور تقريبًا من أصل 3000 صورة، حوالي 50٪، للتلف من مصدرها. لم يتقاض مني صديقي أي مقابل وطلب مني إعادة الموقع إلى النسخة الاحتياطية (التي تم إنشاؤها قبل تسليمه السيطرة في 11 أبريل 2025).

على أي حال، أصبحت كسولًا لمدة شهر تقريبًا، ولم أقم بالاستعادة. حتى قررت إصلاح الأمور بمساعدة روبوت المساعد للمناقشة / روبوت ChatGPT AI. وأنشأت نسخة أخرى من موقعي القديم على جهاز الكمبيوتر المحمول الخاص بي الذي يعمل بنظام Ubuntu محليًا.

نجحت في إنشاء نسخة من موقعي الأصلي على جهاز الكمبيوتر المحمول الخاص بي عن طريق وضع “t.” أمام اسم النطاق الأصلي الخاص بي. الآن هذا (المسمى موقع مرحلي) يعمل بشكل جيد تمامًا بالنسبة لي، ولكنه يحتوي على نشاط حتى 11 أبريل 2025 فقط.

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

ضع في اعتبارك أنني جربت العديد من مهام rake للهجرة أو لإعادة توصيل الاتصال المفقود بالصور، دون أي نجاح.

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

لاحظت أيضًا أنه بدون هذا الاتصال، يتم حذف تلك الصور “اليتيمة” تلقائيًا من الخادم. ولكن لحسن الحظ، أقوم بمزامنتها مرة أخرى من الموقع المرحلي أو من سلة S3 الخاصة بي إلى خادم الإنتاج الخاص بي.

أخيرًا المشكلة، بكلمات، أكثر أو أقل، ChatGPT، هي أن الخادم المرحلي يحتوي إما على الإصدارات النهائية المطبوخة، والتي لا علاقة لها بعناوين URL الأولية (القصيرة). والإنتاج، الذي يفتقد عناوين URL النهائية المطبوخة للصور، لا يمكنه الحصول على عناوين URL الصحيحة لتلك الصور ويتراجع إلى عناصر نائبة “شفافة”.

ويقترح ChatGPT عليّ نسخ الإصدار المطبوخ من المشاركات المرحلية إلى الإصدار المطبوخ للإنتاج. وهو ما لا يبدو فكرة جيدة جدًا بالنسبة لي.

2

الصياغة الدقيقة من ChatGpt حول موقفنا:

  • في كل من بيئة الاختبار والإنتاج، post.raw متطابق ويحتوي على إشارات upload://....
  • في بيئة الاختبار، تظهر الصور، ولكن الاستعلام عن Post.find(12849).uploads لا يعطي أي نتائج - مما يعني عدم وجود إدخالات في جدول uploads أو post_uploads لهذه الملفات حتى في بيئة الاختبار.
  • لذلك، تظهر الصور في بيئة الاختبار فقط لأن HTML المطبوخ من قبل الترحيل يحتوي على روابط /uploads/default/original/... الكاملة.
  • ولكن نظرًا لأن الإنتاج تم إعادة خبزه بعد الترحيل، فإن نفس المحتوى الخام يفشل الآن في الحل، ويعود إلى العنصر النائب transparent.png.

:white_check_mark: لا تزال ملفات التحميل موجودة على القرص

جميع ملفات الصور (بما في ذلك تلك الخاصة بالتحميلات المفقودة) لا تزال موجودة تحت /var/www/discourse/public/uploads/default/original/ على كل من بيئة الاختبار والإنتاج. ولكن لا يمكن لـ Discourse حلها بعد الآن نظرًا لعدم وجود إدخالات uploads الخاصة بها.

3

الطريقة السهلة للقيام بذلك كانت، ولا تزال، تفعيل الإعداد https://meta.discourse.org/t/enable-hidden-setting-to-include-s3-uploads-in-the-backups/276535، وعمل نسخة احتياطية، ثم استعادتها على خادم غير مهيأ لـ S3 (سأقوم بذلك على خادم جديد لتجنب كسر الخادم القديم إذا حدث خطأ ما). ولكن يبدو أن الموقع الإنتاجي معطل أيضًا، لذا من المحتمل ألا يساعد ذلك على الإطلاق.

إذا كنت قد أفسدت جدول Uploads بحيث يحتوي على مسارات S3 متعددة فيه، فإن المهمة تكون أصعب بكثير.

بدلاً من ChatGPT، أوصي بـ https://ask.discourse.com/، والذي يعرف على الأقل عن Discourse، ولكنه ربما لن يكون مفيدًا جدًا.

سألقي نظرة على Uploads.pluck(:url) وأرى ما هو موجود.

3 إعجابات