غير قادر على الترحيل إلى S3، وبالتالي غير قادر على الاستعادة من النسخ الاحتياطي

إذًا، لدي نسخة احتياطية من Discourse من خادمنا الأولي ونحاول نقل النظام إلى نظام جديد.

للأسف، هناك مشكلتان:

  1. أثناء الاستعادة، يذكر أن 71 من أصل 1073 ملفًا تم تحميله لم يتم ترحيله إلى S3، وبالتالي يفشل بشكل قاطع أثناء عملية الاستعادة.

  2. محاولة إصلاح هذا على المثيل الرئيسي عن طريق إعادة خبز المنشورات، وما إلى ذلك، يشير إلى أن بعض الملفات التي تم تحميلها لم يتم ترحيلها إلى S3 بعد، حتى عندما أحاول استخدام آلية uploads:migrate_to_s3 الخاصة بـ rake.

هل هناك أي طريقة للحصول على معلومات مفصلة من migrate_to_s3 حول الملفات التي لم يتم ترحيلها، حتى أتمكن من إصلاحها يدويًا؟ من الممكن أيضًا أنهم يشيرون إلى مستودع S3 ميت/فاشل كنا نقوم بالتحميل منه في البداية، باستثناء أن الأمور انفجرت في تلك المرحلة وقمنا ببساطة بتغيير آليات S3 (إلى MinIO بالطبع)، وكان لا يزال هناك أشياء قديمة موجودة في جانب AWS S3. وهو ما لا أعتقد أنه يمكنني ترحيله بسهولة إلى مثيل MinIO الخاص بي.

بدلاً من ذلك، هل هناك طريقة لتعطيل مدقق S3 للملفات التي تم تحميلها في آلية الاستعادة لأنني قمت بالفعل بفرض ترحيل الملفات التي تم تحميلها بنفسي بالفعل؟

إعجابَين (2)

حسنًا، لقد اكتشفت الأمر بعد التعمق في قاعدة البيانات. يبدو أنها بقايا (71 تحميلًا) من بيئة S3 الأصلية التي لم تعد قيد الاستخدام (أو بالأحرى، بيئة S3 متاحة ولكنها غير مستخدمة بشكل أساسي، لأنها لم تكن فعالة من حيث التكلفة).

انتهى بي الأمر بفعل هذا:

من الخادم الأصلي:

  1. ./launcher enter app

  2. sudo -u postgres psql discourse

  3. SELECT url FROM uploads WHERE url NOT LIKE '%ExpectedS3DomainGoesHere%'
    (استبدل ExpectedS3DomainGoesHere بعنوان URL الفعلي الذي تستخدمه لتكوين S3 الخاص بك)
    سيؤدي هذا إلى الحصول على عناوين URL للعمل معها، لأننا بحاجة إلى القيام ببعض الأشياء.

  4. حيث تكون عناوين URL من مستودعات أقدم على عناوين URL مختلفة، استخدم عميل Amazon S3 (أو عميل الواجهة الخلفية لتخزين S3 الخاص بك)، و:
    أ. قم بمزامنة مستودعات عناوين URL غير المتوقعة إذا كانت متاحة إلى التخزين المحلي.
    ب. قم بمزامنة العناصر من المحلي إلى المستودع الجديد.

  5. discourse remap OLD-URL-FROM-DB NEW-URL-FROM-DB
    بينما تم اقتراح هنا استخدام DbHelper.remap، فإن وظيفة إعادة التعيين من discourse عملت بشكل جيد.

  6. تأكد من ترحيل البيانات.
    rails uploads:migrate_to_s3

  7. وقت إعادة التشكيل!
    rails posts:rebake

  8. قم بعمل نسخة احتياطية للموقع مرة أخرى على الجهاز/الخادم ‘الأصلي’. قم بتنزيل هذا التحديث الأخير.

من خادم الوجهة الجديد:

  1. قم بإعداد Discourse كما هو متوقع، وانسخ app.yml وما شابه من الخادم الأصلي إلى الخادم الجديد في /var/discourse/containers/ للتأكد من أن إعادة البناء تصل إلى المكونات الإضافية المناسبة، وما إلى ذلك.
    تأكد من التعليق على أي إدخالات DISCOURSE_BACKUP_LOCATION: s3 في app.yml، إذا كنت تعمل مع نسخ احتياطية محلية. واجهت بعض المشكلات مع S3 الذي كان غريبًا مع ملفات النسخ الاحتياطي التي تم اقتطاعها، لذا اتخذت النهج المحلي للاستعادة.

  2. اتبع الخطوات في Restore a backup from the command line لوضع النسخة الاحتياطية على الخادم الخاص بك واستعادتها. بما في ذلك خطوات إعادة البناء.

كان هذا مؤلمًا بالنسبة لي لحله، ولكنه تم حله بمجرد أن تعمقت في جدول التحميلات في قاعدة البيانات. ولكن، يبدو أن هذا قد نجح، لذا…

5 إعجابات

ما ينجح غالبًا في هذه المواقف هو تعطيل تحميلات s3 مؤقتًا على المثيل الأصلي قبل أخذ نسخة احتياطية. بعد الاستعادة، يمكنك إعادة تمكين s3.

3 إعجابات

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