تغيير سلة s3 للتحميلات

مرحباً!

نحن نقوم بنقل جميع ملفاتنا/صورنا بين خدمتين مختلفتين متوافقتين مع S3 (كلتاهما مساحات Digital Ocean، إذا كان ذلك يهم)، وقد قررت أننا عالقون في حالة سيئة جداً.

سأبدأ بشرح كيفية إجراء عملية الهجرة:

  1. قمنا بنسخ/مزامنة الدلو الأولي إلى الدلو الجديد باستخدام rclone
  2. تم تحديث جميع المراجع في صفحة “الملفات” في إدارة Discourse لتشير إلى نقاط النهاية الجديدة
  3. تم تشغيل إعادة الخبز (re-bake)

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

حجم الدلو حوالي 60 جيجابايت، لذا فهو (حتى لو لم يكن هائلاً) كمية بيانات ضخمة جداً.

لقد أعيدت بناء الحاوية، وحاولت استعادة الأشياء من “tombstone”، وقمت تقريباً بكل ما يمكنني التفكير فيه أو العثور عليه في منتدى الدعم أو مهام rake.
كما جربت استبدال قاعدة البيانات (عبر discourse remap).

كل صورة تبدو حالياً في المحتوى المخبز بهذا الشكل تقريباً:

<img src="https://xxxx.xxxxx.xx/images/transparent.png" alt="image" data-orig-src="upload://h8UudilPhVsGnNmvlJ5lQYEr8PT.jpeg" width="375" height="500">

وهذا يجعلني أعتقد أن الب64-sha للرابط إما تالفة أو أن تجزئة الصورة (image sha) تغيرت لسبب ما.

هل قام أحدكم بهذا من قبل؟ هل جميع الصور مفقودة للأبد؟ (نعم نعم، لدي نسخة احتياطية والصور القديمة، لذا أعرف أن هناك طريقة).

إعجابَين (2)

قد يكون من الجدير بالذكر أنني حاولت استخدام رابط CDN الموفر لحاوية المساحات أيضًا (مع إعادة التوليد).

إعجاب واحد (1)

مخرجات من التحميلات المفقودة:

rake posts:missing_uploads
البحث عن تحميلات مفقودة على: default
إصلاح التحميلات المفقودة:
🚫
تفقدت 17075 تحميلًا للمنشورات.

تفقدت 16906 تحميلًا.
واحد من أصل 16906 هو تحميل وفق المخطط القديم.
تأثرت 14646 منشورًا من أصل 139801 منشور.

تحتوي post_uploads على 3448 إدخالًا
تحتوي optimized_images على 25681 إدخالًا
تحتوي uploads على 5764 إدخالًا

إعجاب واحد (1)

يمكنك الاطلاع على Moving from one S3 bucket to another

أعتقد أن لدي مسودة لكيفية القيام بذلك سأحاول نشرها غدًا.

5 إعجابات

سيكون ذلك مفيدًا جدًا، شكرًا جزيلاً لك!

إعجاب واحد (1)

مرحبًا @Jite!

جرب هذا لترَ ما إذا كان يعمل معك. إذا نجح، سأقوم بإنشاء دليل تعليمي (howto) مناسب.

الدلاء القديمة

يفترض هذا أنك تستطيع تثبيت وتكوين أداة لنقل بياناتك من الدلو القديم إلى جهاز محلي، ثم تكرار العملية من المحلي إلى الدلو الجديد. راجع aws cli sync (التي يمكن تكوينها لدلاء غير تابعة لـ AWS) و gsutil rsync للحصول على معلومات. إذا كانت لديك كميات هائلة من البيانات أو كنت تنقل بين دلاء تابعة لنفس المزود، فقد ترغب في استكشاف طرق تنقل البيانات مباشرة بين الدلاء.

ادخل إلى دليل مناسب كمساحة مؤقتة (مثلاً: mkdir temp-bucket; cd temp-bucket) قبل تنفيذ أمر مشابه للآتي. تتضمن هذه الأمثلة مفاتيح -n و --dry-run لعرض ما سيحدث. إذا بدا ذلك مناسبًا لما تريده، شغّل الأمر مرة أخرى دون هذا المفتاح.

نقل البيانات القديمة من الدلو القديم إلى المحلي

    gsutil  rsync -r -n  gs://=OLD= .

أو

    aws s3 sync s3://=OLD= .

نقل البيانات من المحلي إلى الدلو الجديد

    gsutil rsync -r -n . gs://=NEW=

أو

    aws s3 sync . s3://=NEW=

تحديث قاعدة البيانات لاستخدام الدلو الجديد

ستنفذ هذه الأوامر من وحدة تحكم Rails. للوصول إليها، قم بما يلي:

cd /var/discourse
./launcher enter app
rails c

بالنسبة للدلو الجديد، قم برفع صورة باستخدام الإعدادات الجديدة وقم بما يلي:

Upload.last.url

يجب أن ترى شيئًا مثل:

=> "//discourse-bucket.s3.dualstack.us-east-2.amazonaws.com/`original/2X/7/12345fbea574afc4e02db80107e6682430aede2c.png"

ستحصل بعد ذلك على discourse-bucket.s3.dualstack.us-east-2.amazonaws.com للدلو الجديد. احصل على اسم المضيف للدلو القديم بنفس الطريقة من ما سبق.

استخدم هذا للتحقق من أن الرفع موجود حيث تعتقد:

Upload.order(Arel.sql('RANDOM()')).limit(10).pluck(:id, :url)

الآن، ستقوم بتحديث قاعدة البيانات لاستخدام الدلو الجديد بدلاً من القديم. سيقوم DbHelper.remap باستبدال جميع الوقوع في جميع الجداول.

DbHelper.remap("//=OLDHOST=/","//=NEWHOST=/")

قد يتطلب الانتقال إلى AWS مسح s3_endpoint.

ملاحظة: إذا كان لديك s3_endpoint مُعرّف في إعدادات الموقع (SiteSettings) في قاعدة البيانات وقمت بالتبديل إلى AWS (حيث لا يُحتاج إلى نقطة نهاية)، فستحتاج إلى مسح إعداد الموقع هذا بعد بناء الحاوية الجديدة مع الإعدادات المحدثة (أو بعد استعادة قاعدة بيانات تحتوي على هذا الإعداد).

إعادة بناء المنشورات التي تشير إلى الدلو بدلاً من CDN S3

إذا كان لديك منشورات تربط مباشرة بالدلو الجديد (ربما لم تكن لديك s3_cdn_url مُعرّفة من قبل)، فإليك كيفية إعادة بناء المنشورات التي تحتاج إلى ذلك فقط.

احصل على المنشورات:

  posts=Post.where("cooked like '%=NEWHOST=%'")

انظر كم عدد:

  posts.count

أعد بناء هذه المنشورات:

  posts.each do |p| p.rebake! end

أو، ببساطة استبدل الدلو بـ CDN:

posts.each do |p|
  p.cooked.gsub!(/=NEWHOST=/,"=CDN=")
  p.save!
end

8 إعجابات

شكرًا لك على الرد.

هذا هو ما فعلته في المرة السابقة، لكنني جربت ذلك مرة أخرى. المشكلة هي أن posts.count يعيد 0. جميع المنشورات تحتوي على ملف transperent.png في المحتوى المطبوخ، وتحتوي على تجزئة في المحتوى غير المطبوخ.

هل هناك طريقة لجعل النظام يحل الصورة بشكل صحيح أثناء عملية التحضير؟

إعجاب واحد (1)

حسناً، هذا التعديل المطبوخ يعمل فقط لتجنب إعادة الإنشاء. إذا لم تنجح إعادة الإنشاء، فهذا يعني أن هناك خطأً آخر. ربما تكون الأصول غير في المكان الذي تعتقد أن discourse يفترضه؟

إعجاب واحد (1)

حسناً، هذا ممكن، لكن “النقل” كان في الغالب نقلًا واحدًا لواحد لجميع الملفات في الدلو، ههه…

إعجابَين (2)

إذن يمكنك استبدال رابط الدلو القديم بالجديد وسيتم ذلك بنجاح؟

هل تبدو القيم في “التحميلات” صحيحة؟

إعجاب واحد (1)

أنا خائف قليلاً من أن العودة إلى الدلو القديم قد تُطلق مهمة لنقل كل شيء إلى علامة “تومبستون” لأنها أصبحت “قديمة” الآن، ولكن نعم، يبدو أن قاعدة البيانات تشير إلى الصور الصحيحة (الموقع الجديد)، المشكلة هي ببساطة في المنشورات القديمة التي لا تحل إلى الصورة الصحيحة (أظن…).

إعجاب واحد (1)

بعد تشغيل مهمة Rake لاستعادة الملفات المحذوفة (toombstone recovery) ثم مهمة Rake لإصلاح الملفات المرفقة المفقودة (fix_missing_uploads)، نجحت أخيرًا في بدء “إصلاح” الصور.
يبدو أنها تقوم بتحميل الصور وإعادة رفعها مرة أخرى، وتستغرق ذلك وقتًا طويلاً جدًا وتستهلك موارد كثيرة جدًا، ولكن على الأقل سيعود المستخدمون إلى صورهم!

شكرًا لك على المساعدة @pfaffman :slight_smile:

3 إعجابات

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.