حسنًا، لقد اكتشفت الأمر بعد التعمق في قاعدة البيانات. يبدو أنها بقايا (71 تحميلًا) من بيئة S3 الأصلية التي لم تعد قيد الاستخدام (أو بالأحرى، بيئة S3 متاحة ولكنها غير مستخدمة بشكل أساسي، لأنها لم تكن فعالة من حيث التكلفة).
انتهى بي الأمر بفعل هذا:
من الخادم الأصلي:
./launcher enter app
sudo -u postgres psql discourse
SELECT url FROM uploads WHERE url NOT LIKE '%ExpectedS3DomainGoesHere%'
(استبدل ExpectedS3DomainGoesHere بعنوان URL الفعلي الذي تستخدمه لتكوين S3 الخاص بك)
سيؤدي هذا إلى الحصول على عناوين URL للعمل معها، لأننا بحاجة إلى القيام ببعض الأشياء.حيث تكون عناوين URL من مستودعات أقدم على عناوين URL مختلفة، استخدم عميل Amazon S3 (أو عميل الواجهة الخلفية لتخزين S3 الخاص بك)، و:
أ. قم بمزامنة مستودعات عناوين URL غير المتوقعة إذا كانت متاحة إلى التخزين المحلي.
ب. قم بمزامنة العناصر من المحلي إلى المستودع الجديد.
discourse remap OLD-URL-FROM-DB NEW-URL-FROM-DB
بينما تم اقتراح هنا استخدام DbHelper.remap، فإن وظيفة إعادة التعيين من discourse عملت بشكل جيد.تأكد من ترحيل البيانات.
rails uploads:migrate_to_s3وقت إعادة التشكيل!
rails posts:rebakeقم بعمل نسخة احتياطية للموقع مرة أخرى على الجهاز/الخادم ‘الأصلي’. قم بتنزيل هذا التحديث الأخير.
من خادم الوجهة الجديد:
قم بإعداد Discourse كما هو متوقع، وانسخ app.yml وما شابه من الخادم الأصلي إلى الخادم الجديد في
/var/discourse/containers/للتأكد من أن إعادة البناء تصل إلى المكونات الإضافية المناسبة، وما إلى ذلك.
تأكد من التعليق على أي إدخالاتDISCOURSE_BACKUP_LOCATION: s3في app.yml، إذا كنت تعمل مع نسخ احتياطية محلية. واجهت بعض المشكلات مع S3 الذي كان غريبًا مع ملفات النسخ الاحتياطي التي تم اقتطاعها، لذا اتخذت النهج المحلي للاستعادة.اتبع الخطوات في Restore a backup from the command line لوضع النسخة الاحتياطية على الخادم الخاص بك واستعادتها. بما في ذلك خطوات إعادة البناء.
كان هذا مؤلمًا بالنسبة لي لحله، ولكنه تم حله بمجرد أن تعمقت في جدول التحميلات في قاعدة البيانات. ولكن، يبدو أن هذا قد نجح، لذا…