واجهنا مشكلة مشابهة لهذه: #bug:
https://meta.discourse.org/t/missing-user-profile-pictures/93844
هل توجد أي طريقة لاستعادة الصور الرمزية المفقودة؟
ملاحظة: جربت استخدام هذا الدليل وقمت بتشغيل أمر rake avatars:refresh لكن لم يحدث شيء.
هذه المشكلة تشبه الفيروس وتنتشر نحو المزيد من الصور الرمزية! ملاحظة غريبة كانت كالتالي:
في متصفح فايرفوكس، تُعرض بعض الصور الرمزية بينما تكون مفقودة في كروم. هذا لا يعني أنه لا توجد صور رمزية مفقودة في فايرفوكس؛ فهناك صور رمزية مفقودة في فايرفوكس أيضًا!
لقطة شاشة من فايرفوكس
لقطة شاشة من كروم
هل تم إصلاح هذا الخطأ حقًا؟ (https://meta.discourse.org/t/missing-user-profile-pictures/93844/8?u=pad_pors)
لقد صادفت نفس المشكلة وأقوم حالياً بالتحقيق فيها. في الحالة التي أتحقق منها، ترتبط المشكلة بالتخزين الخارجي.
@Pad_Pors هل لا تزال تواجه هذه المشكلة؟ أيضاً، هل قمت برفع ملفات أو هل لديك ملفات مخزنة في S3؟
سعيد بسماع أن خبيرًا يحقق في الأمر 
نعم، لا نزال نواجه هذه المشكلة، ونعم، كنا نستخدم تخزين التحميلات على S3، لكن لم يعد الأمر كذلك.
نفس الشيء بالنسبة لنا يا @angus، لدينا S3. أبلغنا إذا كنت بحاجة إلى بعض السجلات أو غير ذلك. شكرًا جزيلاً.
في الحالة التي أفحصها، تم نقل صور الرموز المفقودة إلى مجلد القبر (tombstone) في S3 بعد ترقية عبر سطر الأوامر وترقية يدوية لـ PostgreSQL من الإصدار 10 إلى 12. لا زلت غير متأكد من السبب الدقيق.
العثور على الملفات المرفوعة
@Jeremie_Leroy @Pad_Pors إذا أردتم التحقق مما إذا كان الأمر نفسه ينطبق في حالتكم، فإن الطريقة التي اتبعتها للتحقق من الرموز المفقودة في مجلد القبر (tombstone) في S3 هي كالتالي:
-
حصلت على قيمة SHA1 (وهي السلسلة المكونة من 16 حرفًا في عنوان URL للرفع) لرفع رمز معرف أنه تالف بعد الترحيل. قمت بذلك بأخذ معرف الرفع من عنوان URL للرمز التالف (وهو الجزء الأول من اسم الملف، على سبيل المثال، لملف
6254_2.pngيكون المعرف هو6254)، ثم استخدام هذا المعرف للبحث عن قيمة SHA1 الخاصة بالرفع في نسخة احتياطية حديثة من قاعدة البيانات. إذا لم تكن مرتاحًا لاستخدام سطر الأوامر، يمكنك تصور بياناتك في النسخة الاحتياطية باستخدام واجهة رسومية لـ PostgreSQL مثل Postico 2. -
قمت بالبحث عن قيمة SHA1 في مجلد القبر (tombstone) لحوض S3 ذي الصلة باستخدام واجهة سطر أوامر AWS (AWS CLI).
aws s3api list-objects --bucket <bucket_name> --query "Contents[?contains(Key, <sha1>)]" --prefix "tombstone"(يجب عليك تغيير
<bucket_name>و<sha1>)
إذا نجح الأمر، ستحصل على قائمة نتائج تبدو كالتالي:
{
"Key": "tombstone/original/2X/d/d7b553ff276fca054c7090e859ef5339fd1f936e.jpg",
"LastModified": "2020-05-16T11:45:03+00:00",
"ETag": ## سلسلة من الأحرف والأرقام،
"Size": 64580,
"StorageClass": "STANDARD",
"Owner": {
"ID": ## سلسلة من الأحرف والأرقام
}
}
لاحظ أن تاريخ 5/16 هو التاريخ الذي قمت فيه بالترقية. جميع الرموز التي تم وضعها في القبر بشكل غير صحيح تحمل طوابع زمنية من ذلك الوقت تقريبًا. أعتقد أن المشكلة استغرقت بعض الوقت لتظهر في بيئة الإنتاج، وظلت تظهر بشكل متقطع بسبب التخزين المؤقت (caching).
الاستعادة
بحسب فهمي، فإن UploadRecovery (ومهمة rake المرتبطة بها) مخصصة لرفع المنشورات فقط، ولا تتعامل مع الرموز الموضوعة في القبر (tombstoned avatars).
أنا حاليًا أبحث في إضافة (تصحيح) طريقة جديدة إلى UploadRecovery تستخدم recover_from_s3 لاستعادة رفعات الرموز.
إذا كان أي شخص يعرف طريقة أسهل لاستعادة الرموز الموضوعة في القبر بشكل خاطئ في S3، فأنا مستعد للاستماع.
@tgxworld هل لديك أي أفكار؟
هذا أمر صعب عليّ، هل هناك أشخاص آخرون في وضعنا؟ هل يستحق الأمر العمل على تحديث؟ @sam @codinghorror
شكرًا لك يا @angus على مشاركة مسار الفحص، لكننا لم نعد نستخدم AWS ولا S3 أيضًا، وفي الواقع، إذا لم أكن مخطئًا، فقد بدأت المشكلة بعد انتقالنا من AWS.
سأكون سعيدًا إذا تم حل المشكلة، لكن في الوقت الحالي، من الأسهل عليّ أن أطلب من أولئك المستخدمين القليل إعادة رفع صورهم الرمزية، وأتمنى ألا تنتشر المشكلة إلى مستخدمين جدد!
لقد تعاملت مع هذه المشكلة بنجاح على الموقع الذي أديره باستخدام نسخة معدلة من نفس المنطق الذي يستعيد الصور التي تم وضع علامة عليها بشكل خاطئ في المنشورات: discourse/lib/upload_recovery.rb at main · discourse/discourse · GitHub.
@Jeremie_Leroy جزء من السبب الذي دفعني إلى نشر الخطوات المذكورة أعلاه هو أن هناك أسبابًا محتملة متعددة لاختفاء صور المستخدمين. لمعرفة ما إذا كان هذا الحل سيعمل بالنسبة لك، يجب عليك أولاً التأكد من وجود صور مستخدمين تم وضع علامة عليها بشكل خاطئ، أي تحديد سبب المشكلة في حالتك.
كما أفهم أن إجراء هذا التحليل أمر صعب للغاية إذا لم تكن على دراية بالجوانب التقنية لمنصة Discourse. لقد قمت بتضمين الحل الذي استخدمته في إضافة يمكنك تجربتها على موقعك الخاص. راجع التعليمات أدناه.
@Pad_Pors إذا كنت مستعدًا فقط لطلب من المستخدمين إعادة رفع صورهم الشخصية، فأنصحك بالقيام بذلك بدلاً من محاولة تطبيق هذا الإصلاح.
تعليمات
يرجى ملاحظة أن هذا الإصلاح مخصص لحالات اختفاء صور المستخدمين عندما:
- تكون الملفات المرفقة مخزنة في S3
- تكون صور المستخدمين مفقودة لأنها تم وضع علامة عليها بشكل خاطئ
- لا يزال سجل الرفع الخاص بصورة المستخدم موجودًا
قم بذلك في وقت تكون فيه نشاطات المنتدى منخفضة وقم بإجراء نسخة احتياطية كاملة أولاً.
تثبيت هذه الإضافة
تضيف هذه الإضافة دالة recover_avatars إلى UploadRecovery، وتستخدم نسخة معدلة من نفس طريقة الاستعادة المستخدمة في الدالة الرئيسية recover لاستعادة الملفات المفقودة في المنشورات.
سيحتفظ هذا الإجراء بنسخة من صور المستخدمين “المستعادة” في مجلد العلامات (tombstone) لأغراض redundancy. سيتم إزالة هذه النسخ بواسطة مهمة الخلفية purge_deleted_uploads التي تعمل وفقًا للفترة المحددة في إعداد الموقع purge_deleted_uploads_grace_period_days.
الدخول إلى وحدة تحكم Rails
لاستخدام هذه الدالة، يجب عليك أولاً الدخول إلى الخادم عبر SSH، ثم الدخول إلى حاوية Docker وبدء وحدة تحكم Rails:
./launcher enter app
rails c
إجراء تجربة أولية
لمعرفة الملفات المرفقة التي ستحاول الدالة استعادتها من مجلد العلامات، قم أولاً بإجراء تجربة أولية:
UploadRecovery.new(dry_run: true, stop_on_error: false).recover_avatars
ستعرض لك هذه العملية قائمة بأسماء المستخدمين وروابط الملفات في S3. هذه هي ملفات الصور الشخصية التي ستحاول الدالة نقلها من مجلد العلامات في التشغيل الفعلي:
مثال على المخرجات:
user1 tombstone/original/2X/b/bc84397936074854226f1c6e9016099b7fc0aca7.jpeg
user2 tombstone/original/2X/b/b8588e7e45804406f2cbe86f2362c2ccf7f13155.jpg
user3 tombstone/original/2X/8/81a4e3b70cdc35e8f61bca87d276d0253152804a.jpeg
قارن هذه القائمة بالمستخدمين الذين تفتقد صورهم الشخصية على موقعك.
إجراء التشغيل الفعلي
غيّر قيمة dry_run إلى false لإجراء التشغيل الفعلي:
UploadRecovery.new(dry_run: false, stop_on_error: false).recover_avatars
التحقق
بمجرد اكتمال المهمة، تحقق من موقعك المباشر في نافذة تصفح خاصة جديدة (لتجنب مشاكل التخزين المؤقت). بمجرد الانتهاء، تأكد من إغلاق اتصال SSH النشط مع خادمك. لا ترغب في الدخول عن طريق الخطأ إلى وحدة تحكم Rails المفتوحة وإدخال أمر خاطئ.