تم إلغاء عملية الاستعادة أثناء نقل التحميلات إلى S3

الدعم
1

I’ve been running into issues trying to run a restore on our Staging Discourse instance. Staging is running v2.4.0.beta1 +36. Any idea where the breakdown might be or where to look? Thanks in advance!

Below is the end of the log output:

[2019-07-16 20:08:12] ALTER TABLE
[2019-07-16 20:08:12] ALTER TABLE
[2019-07-16 20:08:12] ALTER TABLE
[2019-07-16 20:08:12] ALTER TABLE
[2019-07-16 20:08:12] Migrating the database...
[2019-07-16 20:08:16] Reconnecting to the database...
[2019-07-16 20:08:16] Reloading site settings...
[2019-07-16 20:08:16] Disabling outgoing emails for non-staff users...
[2019-07-16 20:08:16] Clearing emoji cache...
[2019-07-16 20:08:16] Disabling readonly mode...
[2019-07-16 20:08:16] Clear theme cache
[2019-07-16 20:08:22] Extracting uploads...
[2019-07-16 20:08:40] Migrating uploads to S3...
[2019-07-16 20:08:46] Restore process was cancelled!
[2019-07-16 20:08:46] Trying to rollback...
[2019-07-16 20:08:46] Rolling back...
[2019-07-16 20:08:47] Cleaning stuff up...
[2019-07-16 20:08:47] Removing tmp '/var/www/discourse/tmp/restores/default/2019-07-16-200516' directory...
[2019-07-16 20:08:48] Unpausing sidekiq...
[2019-07-16 20:08:48] Marking restore as finished...
2

Is something wrong with your S3 config?

3

Do you see more output running discourse restore BACKUP_FILENAME from the command line?

4

I will check this next and report back. Thank you.

5

Below is the output after running discourse restore BACKUP_FILENAME from the command line. Any feedback is appreciated, thanks!

Disabling outgoing emails for non-staff users...

Clearing emoji cache...

Disabling readonly mode...

Clear theme cache

Extracting uploads...

Migrating uploads to S3...

Checking if default already migrated...

524 of 9474 uploads are not migrated to S3. S3 migration failed for db 'default'.

321 posts are not remapped to new S3 upload URL. S3 migration failed for db 'default'.

Looking for missing uploads on: default

Fixing missing uploads: 

..........................................................................................................

116 post uploads are missing.

116 uploads are missing.

106 of 116 are old scheme uploads.

98 of 83342 posts are affected.

rake posts:missing_uploads identified 98 issues. S3 migration failed for db 'default'.

No posts require rebaking

Migrating uploads to S3 for 'default'...

Some uploads were not migrated to the new scheme. Please run these commands in the rails console

SiteSetting.migrate_to_new_scheme = true

Jobs::MigrateUploadScheme.new.execute(nil)

Restore process was cancelled!

Trying to rollback...

Rolling back...

Cleaning stuff up...

Removing tmp '/var/www/discourse/tmp/restores/default/2019-07-22-172918' directory...

Unpausing sidekiq...

Marking restore as finished...

Notifying 'system' of the end of the restore...

Finished!

[FAILED]

Restore done.
6

That’s a known problem. I’ll fix it tomorrow.

8

Following up on this front to see if the fix has been implemented? Thanks!

9

No, it’s not fixed yet. But, as a workaround, you could temporarily disable the enable_s3_uploads site setting before creating the backup.

10

Following up on the long term fix for this challenge. Thanks!

11

Was this ever resolved? I’m getting the same issue when trying to migrate to a new server. I’m going to try the workaround.

12

This just bit me for a relatively large migration.

13

أنا متأكد تقريبًا من أنني تعرضت لهذه المشكلة أيضًا، وأعتقد أنه يجب تصنيفها كخطأ.
(إذا كانت مختلفة، فلا تتردد في نقلها إلى موضوع جديد منفصل)

من المهم جدًا أن يعمل استعادة النسخ الاحتياطية.

لاحظ أن سبب الفشل ليس واضحًا عند استخدام واجهة المستخدم الخاصة بالمسؤول والنقر على استعادة بجوار اسم النسخة الاحتياطية، ستحصل على:

...
جاري نقل التحميلات إلى S3...
تم إلغاء عملية الاستعادة!
...

إكمال الاستعادة عبر سطر الأوامر يمنحك تفاصيل أكثر:

discourse enter app
discourse restore example-net-2020-01-02-033557-v20191219112000.tar.gz
...
إعادة الاتصال بقاعدة البيانات...
إعادة تحميل إعدادات الموقع...
تعطيل البريد الصادر للمستخدمين غير الموظفين...
مسح ذاكرة التخزين المؤقت للرموز التعبيرية...
تعطيل وضع القراءة فقط...
مسح ذاكرة التخزين المؤقت للمظهر...
استخراج التحميلات...
إعادة تعيين خرائط التحميلات...
إعادة تعيين خرائط '//forum-example-net.s3.dualstack.eu-west-2.amazonaws.com/' إلى '/uploads/default/'
optimized_images=3
uploads=1
جاري نقل التحميلات إلى S3...
التحقق مما إذا كانت النسخة الافتراضية قد تم نقلها بالفعل...
6 من أصل 12 تحميلًا لم يتم نقلها إلى S3. فشل نقل S3 لقاعدة البيانات 'default'.
1 منشور لم يتم إعادة تعيين خرائطه إلى عنوان URL جديد للتحميل على S3. فشل نقل S3 لقاعدة البيانات 'default'.
البحث عن التحميلات المفقودة على: default

لا توجد تحميلات منشورات مفقودة.
يرجى توفير متغيرات البيئة التالية:
    - DISCOURSE_S3_BUCKET
    - DISCOURSE_S3_REGION
    وأي واحد مما يلي:
    - DISCOURSE_S3_ACCESS_KEY_ID
    - DISCOURSE_S3_SECRET_ACCESS_KEY
    أو
    - DISCOURSE_S3_USE_IAM_PROFILE
تم إلغاء عملية الاستعادة!
محاولة التراجع...
جاري التراجع...
تنظيف الأشياء...
إسقاط الدالة من مخطط discourse_functions
إزالة المجلد المؤقت '/var/www/discourse/tmp/restores/default/2020-01-06-222212'...
إلغاء إيقاف sidekiq...
تحديد الاستعادة على أنها منتهية...
إشعار 'النظام' بنهاية الاستعادة...
تم!
[فشل]
تمت الاستعادة.

أضفت كود تصحيح أخطاء بسيط إلى uploads.rake مباشرة قبل عبارة “يرجى توفير متغيرات البيئة التالية” لتفريغ متغيرات البيئة:

puts "ENV: " + ENV.inspect

لم يكن ENV يحتوي على أي متغيرات DISCOURSE_S3_* مضبوطة.

هل هناك سبب منطقي لعدم سحب هذه البيانات من الإعدادات؟

14

أعتقد أن الفكرة هي أنه إذا كان لديك ملفات مُحمَّلة على S3، فستقوم بنسخ احتياطي لقاعدة البيانات فقط، ولن يفشل ذلك لأنه لن يتضمن الملفات المُحمَّلة.

15

بالتأكيد، لكن هذا لا يفيد عندما يكون النسخ الاحتياطي الذي تملكه يتضمن الملفات المرفوعة.

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

16

أتفق. كما أن نقل جميع الملفات المرفوعة إلى S3 مهمة معقدة نسبيًا وتتطلب استخدام CDN لـ S3.

17

لا حاجة لتحويل هذا إلى bug. الأمر على عاتقي وقد قضيت بالفعل وقتًا طويلاً في إعادة هيكلة عملية الاستعادة، وإضافة العديد من الاختبارات، وجعلها أكثر موثوقية. سأقوم بإجراء بعض التعديلات الإضافية لجعل الاستعادة إلى S3 أقل عرضة للتوقف ولإظهار المزيد من المعلومات في واجهة المستخدم للمسؤول.

18

حسب علمي، تم إعادة هيكلة عملية النسخ الاحتياطي/الاستعادة، لكنني اكتشفت للتو أن هذه المشكلة لا تزال قائمة.
فشل محاولة استعادة نسخة احتياطية في الإصدار التجريبي beta11 كانت قد فعّلت خيار enable s3 uploads، مع ظهور الرسالة التالية:

[2020-02-18 09:51:38] جاري استعادة الملفات المرفوعة، قد يستغرق هذا بعض الوقت...
[2020-02-18 09:51:38] EXCEPTION: يرجى توفير متغيرات البيئة التالية:
  - DISCOURSE_S3_BUCKET
  - DISCOURSE_S3_REGION
  وإما:
  - DISCOURSE_S3_ACCESS_KEY_ID
  - DISCOURSE_S3_SECRET_ACCESS_KEY
  أو:
  - DISCOURSE_S3_USE_IAM_PROFILE

[2020-02-18 09:51:38] /var/www/discourse/lib/file_store/to_s3_migration.rb:34:in `s3_options_from_env'
19

إذن، تم تمكين عمليات التحميل إلى S3 في قاعدة البيانات، لكن النسخ الاحتياطية لـ S3 غير مفعلة؟

20

صحيح، هذا يتعلق بهجرة التحميلات.

توجد بيانات اعتماد الوصول إلى S3 في قاعدة البيانات المستعادة، لذا لا داعي لطلب وجودها في متغير بيئة أيضًا.

تقديم متغيرات البيئة يؤدي إلى فشل أيضًا:

جاري استعادة التحميلات، قد يستغرق هذا بعض الوقت...
جاري التحقق مما إذا كانت db8015 قد هُجرت بالفعل...
200 من أصل 206 تحميل لم تُهجّر إلى S3. فشلت هجرة S3 لقاعدة البيانات 'db8015'.
5 مشاركات لم تُعاد تعيينها إلى عنوان URL جديد للتحميل في S3. فشلت هجرة S3 لقاعدة البيانات 'db8015'.
لا توجد مشاركات تتطلب إعادة خَبْز.
جاري هجرة التحميلات إلى S3 لـ 'db8015'...
جاري رفع الملفات إلى S3...
 - جاري سرد الملفات المحلية
 => 21 ملفًا
 - جاري سرد ملفات S3
. => 16 ملفًا
 - جاري مزامنة الملفات مع S3
.....................
جاري تحديث الروابط في قاعدة البيانات...
جاري إزالة الصور المحسّنة القديمة...
جاري وضع علامة على جميع المشاركات التي تحتوي على صناديق عرض خفيفة لإعادة خَبْزها...
تم وضع علامة على 5 مشاركات لإعادة الخَبْز.
استثناء: 183 من أصل 206 تحميل لم تُهجّر إلى S3. فشلت هجرة S3 لقاعدة البيانات 'db8015'.
/var/www/discourse/lib/file_store/to_s3_migration.rb:127:in `raise_or_log'
/var/www/discourse/lib/file_store/to_s3_migration.rb:74:in `migration_successful?'
/var/www/discourse/lib/file_store/to_s3_migration.rb:350:in `migrate_to_s3'
/var/www/discourse/lib/file_store/to_s3_migration.rb:61:in `migrate'
/var/www/discourse/lib/file_store/s3_store.rb:203:in `copy_from'
/var/www/discourse/lib/backup_restore/uploads_restorer.rb:48:in `restore_uploads'
/var/www/discourse/lib/backup_restore/uploads_restorer.rb:30:in `restore'
/var/www/discourse/lib/backup_restore/restorer.rb:58:in `run'
script/discourse:143:in `restore'

لا أعرف سبب هذا الفشل.

كانت معظم التحميلات موجودة بالفعل على S3، لذا فإن عبارة “200 من أصل 206 تحميل لم تُهجّر إلى S3” و"183 من أصل 206 تحميل لم تُهجّر إلى S3" غير صحيحة. عدد الملفات المحلية البالغ 21 ملفًا صحيح، وهناك حوالي 200 تحميل على S3 (قد يكون 206 أيضًا). لا أعرف أيًا من الأرقام الأخرى (183، 16).

لا أعرف أيضًا لماذا يحاول عملية الاستعادة نقل المزيد من التحميلات إلى S3؟ ألا يجب أن تأخذ الصور المحلية من النسخة الاحتياطية وتترك التحميلات الموجودة على S3 كما هي؟ أم أنني أغفل شيئًا؟

في النهاية، انتهيت بتعديل إعداد enable_s3_uploads في نسخة قاعدة البيانات إلى false، لكن هذا أدى إلى إعادة تعيين كل شيء إلى المحلية. وبما أن هناك بعض الصور لا تزال محلية، فقد تطلب الأمر جهدًا كبيرًا لتحديد أي منها يحتاج إلى إعادة تعيين إلى S3 وأيها لا يجب.

كل هذا على الإصدار 2.4.0 beta11.

21

لا يتم دعم دمج التحميلات المحلية مع التحميلات المخزنة على S3. نعم، أعلم أنه من الممكن الوقوع في مثل هذه الحالة عندما ينتقل شخص ما من التحميلات المحلية إلى S3 ولا يرحّل التحميلات الحالية إلى S3، لكن هذه قصة أخرى…

يتضمن استعادة نسخة احتياطية دائمًا إعادة تعيين الروابط إذا اكتشف النظام أي تغييرات تؤثر على عناوين URL الخاصة بالتحميل. ويشمل ذلك التبديل بين وضع الموقع المستقل ووضع الموقع متعدد المواقع، والتبديل بين التحميلات المحلية وS3، بالإضافة إلى التغييرات في إعدادات S3 وCDN. يتم استعادة جميع التحميلات في الموقع الصحيح بناءً على الإعدادات، سواء محليًا أو على S3.

من وقت لآخر، نواجه نسخًا احتياطية يفشل فيها إعادة تعيين الروابط تلقائيًا والهجرة إلى S3 لأسباب مختلفة. يمكنك توقع رؤية المزيد من التحسينات في بداية دورة تطوير الإصدار 2.5.