@schleifer مرحبًا، هل يمكننا الحصول على إرشادات بعد ذلك، من فضلك؟
حسنًا، هذا شيء يمكننا العمل معه. أولاً، انقل جميع الملفات الموجودة في /default/* إلى /original/1X/*.
هذا معروف لدينا ولكن ليس لقاعدة البيانات. الخطوة التالية ستعدل المسار لجميع التحميلات في قاعدة البيانات. قبل تغيير أي شيء آخر، دعنا نتحقق من الصحة.
ابدأ وحدة تحكم قاعدة البيانات:
cd /var/discourse
./launcher enter
rails db
شغّل هذا الاستعلام لمراجعة هذا الاستعلام:
select id,url from uploads where id > 0 and url not like '//PREFIX/original/%'
ستحتاج إلى استبدال PREFIX بـ BUCKET + ‘.s3.dualstack.’ + REGION + ‘.amazonaws.com’، مما يعطي شيئًا مثل //pesioforum.s3.dualstack.us-west-2.amazonaws.com/original/%.
يجب أن يُرجع ذلك (0 rows). إذا لم يكن الأمر كذلك، فسنكون بحاجة إلى خطوات إضافية.
هناك 7 ملفات مرفقة لاستعلامك، ولا يوجد منها أي ملف من S3.
إذن، جميع روابط S3 تشير فقط إلى النسخة الأصلية، صحيح؟ الملفات المرفقة السبعة تعود لفترة ما قبل بدء استخدام S3 للرفع (أكتوبر 2018).
من بين روابط S3 (2614 رابط):
2368 رابط تستخدم //pesioforum.s3.dualstack.ap-south-1.amazonaws.com
246 رابط تستخدم //pesioforum.s3.ap-south-1.amazonaws.com
كلا الرابطين يعملان، ونذكر ذلك هنا لأنه قد يؤثر على أي تعبير نمطي (regex) قد نستخدمه.
@schleifer يرجى مساعدتنا في إكمال هذا. 
حسنًا، يجب أن تكون جاهزًا لنقل الملفات من /default/ إلى /original/1X.
يمكنك نقلها إلى S3 بتشغيل الأمر rake s3:upload_assets
نقطة النهاية dualstack تعمل مع IPv6 و IPv4. أما الأخرى فهي تعمل مع IPv4 فقط.
يوجد نص برمجي داخل الصورة لإعادة تعيين السلاسل النصية في قاعدة البيانات. قبل تشغيله، قم دائمًا بنسخ احتياطي عبر /admin/backups (القائمة المنسدلة → Admin → Backups).
هذا يجب أن يصلح الـ 246:
discourse remap '//pesioforum.s3.ap-south-1.amazonaws.com/original/' '//pesioforum.s3.dualstack.ap-south-1.amazonaws.com/original/'
بعد نقل كل شيء من /default/ إلى /original/1X/، يمكننا إعادة تعيين تلك الملفات في قاعدة البيانات. ولكن قبل ذلك، يجب أن نتأكد من أن كل شيء في /original/2X موجود فعليًا.
هل يعيد هذا الاستعلام نفس عدد الصفوف مثل عدد الكائنات الفعلية تحت هذا المسار في الدلو؟:
select url from uploads where url like '//pesioforum.s3.dualstack.us-west-2.amazonaws.com/original/2X/%'
مرحبًا @schleifer
يمكنك ترحيل تلك الملفات إلى S3 بتشغيل
rake s3:upload_assets
نفذت هذا الأمر، فتم رفع الأصول (مثل ملفات JS وCSS وغيرها) للموقع. لكن لم يتم رفع 7 ملفات.
وجدت أمر rake uploads:migrate_to_s3 وأردت التأكد من أنه المهمة الصحيحة لهذا الغرض.
يوجد نص برمجي في الصورة لإعادة تعيين السلاسل النصية في قاعدة البيانات
نجح هذا الإجراء، ولم تعد هناك أي روابط قديمة غير متوافقة مع dualstack في جدول uploads.
لكن قبل ذلك، يجب أن نتأكد من وجود كل شيء في
/original/2Xفعليًا.
للأسف، هذا ليس هو الحال. فهناك 521 ملفًا في حوض S3، بينما يحتوي جدول uploads على 2186 سجلًا.
اختبرت بعض الملفات التي لم تكن موجودة في /original/2X/ كما هو مطلوب، ووجدت أنها جميعًا موجودة في /default/.
مثال: من جدول uploads،
https://pesioforum.s3.dualstack.ap-south-1.amazonaws.com/original/2X/8/806a660beb158e9f06d07ffcd2370b389bbd250b.jpeg غير موجود، لكن نفس الملف موجود في
https://pesioforum.s3.dualstack.ap-south-1.amazonaws.com/default/806a660beb158e9f06d07ffcd2370b389bbd250b.jpeg
في هذه المرحلة، كحل مؤقت لمرة واحدة، نحن مستعدون لنقل جميع الملفات من /original/2X/{}/ إلى /original/1X/ وتحديث المنشورات وما إلى ذلك بالروابط الجديدة.
بالإضافة إلى ذلك، يتم رفع الملفات الجديدة بشكل صحيح إلى 2X على أي حال.
أها، نعم، تلك هي المهمة التي كنت أقصدها بالفعل. يجب أن تنقل آخر سبعة ملفات.
في الواقع، هذه هي أفضل خيار في هذه المرحلة. انسخ جميع الملفات من بادئة المسار الفرعية /2X/ الخاصة بها وانقل كل شيء إلى /1X/.
بعد وضع كل شيء في مكانه، إليك أمرًا يجب أن يحدث جميع إدخالات قاعدة البيانات:
discourse remap --regex "//pesioforum\.doublestack\.s3\.ap-south-1\.amazonaws\.com/original/[1234]X/([0-9a-f]/){0,}" "//pesioforum.doublestack.s3.ap-south-1.amazonaws.com/original/1X/"
(تذكّر التحذير السابق حول أخذ نسخة احتياطية.)
بعد ذلك، قد تحتاج بعض المنشورات إلى إعادة بناء نسختها HTML عبر قائمة المفتاح الإنجليزي. إذا كان هناك أكثر من عدد قليل، فيمكنك إعادة بناء الكل باستخدام rake posts:rebake.
@schleifer نجح ذلك! مع تعبير نمطي مُعدّل وإعادة بناء لجميع المنشورات، تعمل معظم الصور والملفات المرفقة بشكل جيد.
لا تزال بعض الصور (غير المنشورات) ترتبط بـ /optimized/، لكن يمكننا إصلاح ذلك يدويًا. مثال: الشعارات في سمات مختلفة، إلخ.
شكرًا جزيلاً لمساعدتك!
مرحبًا، لقد واجهنا مشكلة مماثلة لهذه في بيئتنا أيضًا، وكنا نأمل في الحصول على مساعدة لحلها.
مشكلتنا مشابهة لهذه المشكلة بعدة جوانب:
- لدينا نفس القيمة مدرجة تحت
s3 upload bucketوs3 backup bucket. - واجهنا هذه المشكلة عند ترقية Discourse:
الإصدار القديم: v2.3.0.beta3
الإصدار الجديد: v2.5.0.beta6
- قمت بالدخول إلى حاوية Discourse واستعلام قاعدة البيانات:
SELECT id,url FROM uploads where id > 0 and url not like '//acme-forum.s3.dualstack.us-west-2.amazonaws.com/original/%';
id | url
----+----------------------------------------------------------------------------------------------------
1 | /uploads/default/original/1X/eb17xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxc33.png
2 | /uploads/default/original/1X/b87fxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxv21.png
78 | //acme-forum.s3-us-west-2.amazonaws.com/original/1X/1205xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxv045.png
(3 rows)
- قمت بالدخول إلى حاوية Discourse واستعلام قاعدة البيانات:
select url from uploads where url like '//acme-forum.s3.dualstack.us-west-2.amazonaws.com/original/3X/%';
//acme-forum.s3.dualstack.us-west-2.amazonaws.com/original/3X/6/2/6267xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxf607c.jpeg
(7953 rows)
- تحققت من عدد العناصر الموجودة في ./original/3X/، والإجابة هي
251عنصر.
السؤال:
- نحن نستخدم
dualstackولا أريد إعادة تعيين عناوين URL الخاصة بنا لعدم استخدامها. - يبدو هيكل المجلدات لدينا مختلفًا، لدينا أشياء مثل
3X/X/Y(مثل:3X/7/a)، لذا كيف يمكنني نقل كل شيء منdefaultإلى3X/*، فلن يتم تعيينه بشكل صحيح بعد ذلك.
فكريتي الحالية هي كتابة سكريبت سيستند إلى مخرجات الخطوة 4 لمعرفة مكان نقل الملف مرة أخرى إلى مجلد ./original/3X/X/Y.
المشكلة الوحيدة هي أنه عندما قمت بذلك، لم يكن dualstack يستضيف هذا الملف بعد. ما أعنيه هو أنه عند استبدال الملف بـ original/3X/X/Y، يمكنني رؤيته عند الانتقال إلى:
مكسور https://acme-forum.s3.dualstack.us-west-2.amazonaws.com/original/3X/6/b/6b6xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxa001.png
تحديث: اتضح أن نقطة نهاية dualstack لم تكن مكسورة كما ظننت، لقد ارتكبت خطأً عندما نسخت ملف الصورة في الأصل إلى ./original/3X/6/b حيث نسيت السماح بالقراءة للجميع.
لذا، سؤالي هو:
هل سيكون خيارًا عمليًا لي وضع ملفات الصور من ./default مرة أخرى إلى ./original/3X/x/y ثم عدم تعديل قاعدة البيانات على الإطلاق؟
حسنًا، لدي تحديث.
يبدو أنني أستطيع التنبؤ بمكان وجود صور ./original، لكنني لا أعرف كيفية إصلاح صور ./optimized.
في منتدانا، إذا تصفحت أحد منشوراتنا، يحاول عرض صورة ./optimized.
هل توجد طريقة لمعرفة أي صورة هي صورة optimized؟
فكرتي هي أن الصور المحسنة تنتهي بـ _2_10x10.png، هل هذا افتراض معقول؟ إذا كان الأمر كذلك، فهل سيكون من المجدي استخدام سكريبت لنسخ أي شيء يحتوي على شيء مثل _2_10x10.png إلى مجلد optimized، وأي شيء لا يحتوي عليه، مباشرة إلى مجلد ./original؟
مثال:
GET https://acme-forum.s3.dualstack.us-west-2.amazonaws.com/optimized/3X/c/c/ccaxxxxxxxxxxxxxxxxxxxxxxxxxxxx85_2_690x268.png
[HTTP/1.1 403 Forbidden 0ms]
شكرًا!
@41821 إذا كانت عناوين URL في جدول uploads صحيحة وتعمل، ولكن المنشورات لا تزال تحاول تحميل الصور المحسّنة، فسيؤدي مسح جدول optimized_images وإعادة بناء جميع المنشورات إلى حل المشكلة: discourse=> delete from optimized_images;
شكرًا جزيلاً لك على الملاحظات، في الواقع، لقد نجحت في حل المشكلة (إذا كان يمكن تسميتها كذلك) من خلال كتابة سكريبت ينقل الصورة من المجلد /default مرة أخرى إلى /optimized بناءً على اسم الملف. يبدو أن هذا قد نجح ولا أواجه أي مشاكل بعد الآن.
ومع ذلك، إذا حدث هذا مرة أخرى في المستقبل، فسأفعل ما اقترحته وأحذف كل شيء من optimized_images ثم أعيد عملية البناء.
شكرًا!