فشل Rake uploads:migrate_from_s3

نعم، لكنك تجاوزت ذلك في نقطتك رقم 2، وبفعل ذلك عدت إلى وضع الملفات في S3.

تُستخدم إعدادات ملف app.yml فقط عند إعادة بناء الحاوية، وتُستخدم لتعبئة ملف config/discourse.conf في الحاوية قيد البناء.

آه! إذن، إذا كان لدي أي متغيرات s3_ في ملف conf/discourse.conf، فإن Discourse يعتقد أن رفع الملفات عبر S3 مفعل؟ حسنًا… فهمت… سأقوم بإزالتها وأحاول مرة أخرى.

على الأرجح هناك واحد فقط هو المهم… لستُ على حاسوبي الآن للتحقق مما قد يُسبب ذلك، ولكن إذا تم تفعيل هذا الشرط، أتوقع أن موقعك سيرفع جميع الملفات الجديدة إلى S3.

يعمل، يعمل، يعمل، يعمل ويعمل! رائع!!! شكرًا جزيلاً لك على كل ما تبذله من جهد وعلى شرح ما أحتاجه بفارغ الصبر. من الرائع أن نبدأ هذا العمل.

إذن، لدي بعض الأسئلة السريعة فقط لكي أفهم ما يحدث بشكل أفضل…

كنت أقوم بتشغيل دفعة مكونة من 100 عنصر في كل مرة. خلال الدورات القليلة الأولى، كانت الأداة تنقل المنشورات (?)، ولكن الآن تقوم فقط بنسخ الصور. لدي آلاف المنشورات، وكل منشور يحتوي عادةً على صورة واحدة فقط… لذا لست متأكدًا من السبب أو الكيفية التي “نفدت” منها المنشورات المراد نقلها؟ ماذا يعني نقل منشور؟ إذن هذا هو السؤال الأول: ما الذي يحدث بالضبط؟ :wink:

السؤال الثاني أبسط. الآن عند تشغيل الأداة، تقوم فقط بنسخ الصور، لكنني ألاحظ أن صور 2X يتم نسخها محليًا إلى مجلد 3X:

Downloaded 27/100: //my-forum-storage.s3.dualstack.us-east-1.amazonaws.com/original/2X/1/14c56ef9f1dddb7b7a6f14e920234e0f714ea699.jpeg to /uploads/default/original/3X/1/4/14c56ef9f1dddb7b7a6f14e920234e0f714ea699.jpeg

لاحظ أن الرابط يتغير من 2X/1/xyz.jpeg إلى 3X/1/4/xyz.jpeg (مسار مجلد إضافي هناك)

هل هذا كل شيء مقبول؟

أخيرًا، قمت بفحص عشوائي للصور وتبدو جيدة، ولكن بما أنني لا أعرف أي منشور ترتبط به هذه الصورة، فلا يمكنني حقًا إجراء فحص “مباشر” على المنتدى وأن أكون متأكدًا بنسبة 100% أن المستخدمين يرون الشيء الصحيح. كيف يمكنني ربط اسم ملف jpeg بمنشور في المنتدى؟

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

لذا، انتهيت بتحديد حد كبير بمجرد أن تأكدت من انتقالي إلى المرحلة التالية، شيء مثل هذا:

bin/rake uploads:batch_migrate_from_s3[100,100000]

يهاجر هذا الأمر أول الرفع (uploads) التي يجدها في المنشورات؛ فلا توجد تكاملية مرجعية من مراجعات post.raw إلى رفع معين وكائن الرفع في قاعدة البيانات. يبحث عن المنشورات التي تحتوي على أي مراجعات لروابط عادية أو عناوين بروتوكول وهمية upload:// تمثل محتوى بعيدًا، حيث يحتاج على الأقل إلى إعادة طهي المنشور بعد الهجرة، إن لم يكن حفظ تعديل كما هو الحال مع الروابط الأساسية التي تشير مباشرة إلى S3. عندما لا يجد أي محتوى في منشور يحتاج إلى هجرة، ينتقل إلى العنصر التالي.

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

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

أهلاً، ممتاز. أرى هذا في مخرجات التقدم:

تم ترحيل جميع تحميلات المنشورات. جاري ترحيل تحميلات الملفات الشخصية...
تم ترحيل جميع تحميلات الملفات الشخصية. جاري ترحيل التحميلات الأخرى غير المنشورات...

ما المقصود بـ “التحميلات غير المنشورات”؟ يبدو أن كل العمل المتبقي هنا—حيث إن ترحيل المنشورات وتحميلات الملفات الشخصية لا يُحدث أي تغيير.

شكرًا لك على الطمأنة بخصوص مسارات التحميلات الخام!

لست متأكدًا مما إذا كان ذلك يحدث أم لا، لكن لا بأس—موقعي يستخدم SSO، لذا أقوم بنقل رابط الصورة الرمزية في كل مرة يسجل فيها المستخدم الدخول (أو يغير صورته على الموقع الرئيسي).

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

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

حاليًا، عندما أقوم بتشغيل أمر rake، يبدو أنه يقوم بتحميل/رفع الصور مباشرة أثناء تشغيل الدفعة. أدخل أمر rake، فيعالج 300 صورة بالضبط (أقوم بتشغيلها على دفعات من 300) ثم يتوقف.

إذن، السؤال المهم هو: هل يمكن وضع هذه التحميلات من S3 إلى القرص المحلي في قائمة انتظار؟ هل يمكن أن يكون قد تراكم نوع من الدفعات ثم حدث ذلك في الساعة 5 صباحًا وأسقط منتدياتي؟ :frowning:

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

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

نعم، الأمر غامض بالنسبة لي. أعني، أنا لا أشغل الدُفعات في كثير من الأحيان — فأنا أدخل الأمر يدويًا في كل مرة وأشاهد تنفيذه. ليس لدي أي منشورات أو ملفات تعريف أخرى للهجرة؛ كل ما تبقى هو “ملفات أخرى مُحمَّلة”. عند تشغيل الدفعة، يبدو أنها تُحمِّل من S3 ثم تُحمِّل مجددًا إلى Digital Ocean مباشرة. (ولم أرَ أي شيء في Sidekiq يوحي بأن هناك أي شيء في طابور الانتظار.)

أحاول البحث عن أي سجلات أخرى قد تُشير إلى ما حدث في الساعة 5:35 صباحًا.

اقرأ الموضوع بالكامل.

لكن معظمه بدا مربكًا بالنسبة لي. على الرغم من أنني على دراية تامة بأوامر Docker/Container وأوامر Rails الأساسية.

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

كنت أستخدم خانتين مختلفتين من S3 في فترتين مختلفتين من السنة. لدي حوالي 1000 منشور ونفس العدد تقريبًا من الصور.
الآن قمت بنسخ جميع الصور من خانات S3 إلى خادمي المحلي. هل يمكن لأحد أن يخبرني كيف يمكنني إعادة تعيين عناوين URL الخاصة بـ Discourse بحيث تكون هذه الصور متصلة بشكل صحيح بالمنشورات؟