@pnoeric بما أنك مهتم بوقت تشغيل الموقع، فقد أردت أن أنقل إليك ما تعلمته حتى الآن.
أجريت عملية الترحيل مباشرة، كما ذكرت. إذا لم أقم بتقييد معدل الترحيل، فإن الطوابير التي تقوم بمهام مثل إشعار المستخدمين بنشاط بعضهم البعض ستنسد، مما يقلل من تجربة المستخدم على الموقع.
تم ترحيل حوالي 500 منشور يحتوي على مقاطع فيديو وحوالي 30 ألف منشور يحتوي على صور، واستغرقت العملية حوالي أسبوعين للإكمال.
إذا كنت ترغب في تجربة الكود الذي استخدمته، فهو متاح حاليًا في:
يمكنك تنزيله ونسخه إلى تطبيقك لاستبدال محتويات lib/tasks/uploads.rake الحالية.
باستخدام هذا الكود، يمكنك القيام بما يلي:
bin/rake uploads:batch_migrate_from_s3[100,1000]
سيأخذ هذا الأمر في الاعتبار 1000 منشور فقط يحتوي على ملفات مرفقة، ويرسل الملفات من الحد الأقصى لـ 100 منشور قبل التوقف؛ في كل مرة يعدل فيها المنشور فعليًا بعد ترحيل الملفات المرفقة، سينتظر حتى تصبح الطابور فارغًا قبل البدء في التالي.
إذا قمت بنسخ الملف، فسيؤدي ذلك إلى كسر تحديثات الموقع المستقبلية_ ما لم تُلغِ التغيير. أسهل طريقة لإلغاء التغيير بعد أن تكون راضيًا هي ببساطة ./launcher rebuild app (على الرغم من أنني كمطور أستخدم git checkout HEAD lib/tasks/uploads.rake لإلغاء تعديلاتي…)
لاحظت أنه على الأقل مع مساحات Digital Ocean، أحيانًا يجب علي إعادة المحاولة عدة مرات قبل نجاح الترحيل. لا يعطي السكربت الحالي أي تحذير عند حدوث ذلك، وعليك فقط الاستمرار في تشغيله والانتظار لمعرفة النتيجة. لدي طلب سحب (PR) قيد المراجعة يطبع الأخطاء في هذه الحالة حتى تعرف على الأقل أن شيئًا ما قد فشل.
…
أضفت حلقة إعادة محاولة بسيطة، بالإضافة إلى رسالة الخطأ، ويبدو أن حلقة إعادة المحاولة تحل المشكلة. أيضًا، كان التحقق من القواعد الحالية يتم على محتوى المنشورات القديمة، مما قد يكسر الترحيل ويترك المنشورات التي تحتاج إلى إعادة طهي بصمت؛ وقد أصلحت ذلك أيضًا. لن ترغب بالتأكيد في إجراء ترحيل دون الحصول على إصلاح التحقق على الأقل، وهو أحد الالتزامات في طلب السحب (PR) الخاص بي قيد المراجعة حاليًا.
…
لقد أكملت عملية الترحيل، إلى أقصى حد من معرفتي. يحتوي طلب السحب (PR) الخاص بي على جميع الكود الذي استخدمته لإكمال الترحيل. لم يتم مراجعته بعد. أقترح متابعة التحديثات في Migrate_from_s3 problems إذا كنت ترغب في ذلك.