فشل استعادة النسخ الاحتياطي، لن يتوقف sidekiq ثم ينفد

لقد قمت بإعادة البناء هذا الصباح ثم حاولت استعادة نسخة احتياطية داخل الحاوية. أنا أستخدم الإصدار 2.6.0.beta5
(75a893fd61)، مع كل شيء داخل الحاوية.

عادةً ما تنجح عملية استعادة النسخة الاحتياطية (أي أنها نجحت سابقًا)، لكنها فشلت اليوم بالطريقة التالية:

Starting restore: app-2020-11-06-033740-v20201009190955.tar.gz
[STARTED]
'system' has started the restore!
Marking restore as running...
Making sure /var/www/discourse/tmp/restores/default/2020-11-06-084354 exists...
Copying archive to tmp directory...
Unzipping archive, this may take a while...
Extracting dump file...
Validating metadata...
  Current version: 20201103103401
  Restored version: 20201009190955
Enabling readonly mode...
Pausing sidekiq...
Waiting up to 60 seconds for Sidekiq to finish running jobs...
Waiting for sidekiq to finish running jobs... #2
Waiting for sidekiq to finish running jobs... #3
Waiting for sidekiq to finish running jobs... #4
Waiting for sidekiq to finish running jobs... #5
Waiting for sidekiq to finish running jobs... #6
Waiting for sidekiq to finish running jobs... #7
Waiting for sidekiq to finish running jobs... #8
Waiting for sidekiq to finish running jobs... #9
Waiting for sidekiq to finish running jobs... #10
EXCEPTION: Sidekiq did not finish running all the jobs in the allowed time!
/var/www/discourse/lib/backup_restore/system_interface.rb:89:in `block in wait_for_sidekiq'
/var/www/discourse/lib/backup_restore/system_interface.rb:84:in `loop'
/var/www/discourse/lib/backup_restore/system_interface.rb:84:in `wait_for_sidekiq'
/var/www/discourse/lib/backup_restore/restorer.rb:47:in `run'
script/discourse:143:in `restore'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/thor-1.0.1/lib/thor/command.rb:27:in `run'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/thor-1.0.1/lib/thor/invocation.rb:127:in `invoke_command'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/thor-1.0.1/lib/thor.rb:392:in `dispatch'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/thor-1.0.1/lib/thor/base.rb:485:in `start'
script/discourse:284:in `<top (required)>'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/cli/exec.rb:63:in `load'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/cli/exec.rb:63:in `kernel_load'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/cli/exec.rb:28:in `run'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/cli.rb:476:in `exec'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/vendor/thor/lib/thor/invocation.rb:127:in `invoke_command'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/vendor/thor/lib/thor.rb:399:in `dispatch'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/cli.rb:30:in `dispatch'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/vendor/thor/lib/thor/base.rb:476:in `start'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/cli.rb:24:in `start'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/exe/bundle:46:in `block in <top (required)>'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/friendly_errors.rb:123:in `with_friendly_errors'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/exe/bundle:34:in `<top (required)>'
/usr/local/bin/bundle:23:in `load'
/usr/local/bin/bundle:23:in `<main>'
Trying to rollback...
There was no need to rollback
Cleaning stuff up...
Removing tmp '/var/www/discourse/tmp/restores/default/2020-11-06-084354' directory...
Unpausing sidekiq...
Disabling readonly mode...
Marking restore as finished...
Notifying 'system' of the end of the restore...
Finished!
[FAILED]
Restore done.

بعد ذلك، كانت هناك عمليات Ruby تستهلك 100% من وحدة المعالجة المركزية لساعات. يُوصف هذه العملية على النحو التالي:

# ps aux | grep sidekiq
discour+    141  100  5.0 9302596 401484 ?      SNl  06:34 127:46 sidekiq 6.1.2 discourse [5 of 5 busy]

إذا قمت بإيقاف الحاوية وإعادة تشغيلها، فإن هذه العملية (sidekiq) تعود لاستهلاك 100% من وحدة المعالجة المركزية. ملف sidekiq.log فارغ، ولا يُظهر production.log شيئًا يذكر.

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

أشار إليّ شخص لطيف إلى وحدة تحكم Sidekiq، ويبدو أن Sidekiq مشغول بتوليد الصور المصغرة:

النسخ الاحتياطية التي أستخدمها لا تتضمن الصور المصغرة، لذا قد يكون هذا متوقعًا، باستثناء أنني قد شغّلت بالفعل أمر rake posts:rebake ثم أمر rake posts:rebake_uncooked_posts بعد استعادة النسخة الاحتياطية الاختبارية السابقة، فظننت أن ذلك كان سيؤدي إلى توليد جميع الصور المصغرة (استغرق أمر rebake حوالي ساعة واحدة لحوالي 100,000 منشور، بينما لم يفعل أمر rebake_uncooked شيئًا، كما أفترض أن إعادة التحضير الكاملة قد عالت كل شيء).

بافتراض أن هذا الحمل هو ما يمنع نجاح النسخة الاحتياطية، ألا يجب أن يؤدي استعادة نسخة احتياطية أولاً إلى تفريغ طوابير المهام؟

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

# rake posts:rebake_uncooked_posts
إعادة تحضير المنشورات غير المحضرة في الافتراضي

تم إنجاز 0 منشور!

هذا صحيح. عملية إعادة الخَبز تُصنّف مجموعة من المهام بدلاً من تنفيذها جميعًا فعليًا.

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

أعتقد أن هذا هو الحال.

شكرًا لك، هذا بدأ يصبح أكثر وضوحًا.

إذن، هل التسلسل الصحيح هو تدمير الحاوية أولاً، ثم (إعادة) بنائها، ثم الدخول إليها واستعادة النسخة الاحتياطية؟

إذا كان الأمر كذلك، فهذا رائع، رغم أنه ربما كان يمكن لـ Discourse تقديم هذه التلميح/التنبيه عند بدء الاستعادة داخل حاوية غير فارغة.

هذه هي الخيار النووي (وتعتقد أنك ستحتاج فقط إلى حذف بيانات Redis، ثم إعادة البناء). عادةً، لا يكون لديك ملايين الوظائف قيد التشغيل، لذا لا تشكل هذه مشكلة. لكن بما أنك تقوم على ما يبدو بإجراء عمليتي استعادة متتاليتين، ولم تكتمل العملية الأولى تمامًا عند بدء الثانية، فأنت حالة خاصة.

البديل الآخر هو الانتقال إلى /sidekiq وحذف جميع الوظائف الموضوعة في قائمة الانتظار. الأمر يتطلب بضع نقرات فقط.

اختبار جيد لاستعادة الكوارث إذن :smiley:

أنت محق في أن هذا ربما حالة خاصة إلى حد ما. لقد كنت أحاول تقليل وقت إعادة الخبز، لذا فإن استعادة النسخ الاحتياطية وقياس الوقت في ظروف مختلفة (استعادة بدون صور مصغرة تستغرق من يومين إلى 3 أيام لإكمال إعادة الخبز افتراضيًا!). كل هذا هو عمل تمهيدي لهجرة الموقع.

أعتقد أنني أفهم الكثير الآن، شكرًا لك. لكن بالنسبة لأمر حاسم مثل النسخ الاحتياطية، أعتقد أنه من المنطقي أن يضمن Discourse موثوقيته قدر الإمكان (مثل تفريغ طوابير Sidekiq قبل البدء)، أو إصدار تحذيرات واضحة بأن هناك خطوات أخرى مطلوبة إذا اكتشف مشاكل محتملة للاستعادة.

فقط أنت من يعرف القيام بذلك.

أقترح عليك إنشاء نسخة احتياطية مع الصور المصغرة (إعداد الموقع include_thumbnails_in_backups) عند رغبتك في الانتقال إلى خادم مختلف.

شكرًا لك! هذه خيار جربته أيضًا، لكن النسخ الاحتياطي، رغم أنه يزيد بحوالي 6 جيجابايت فقط، يستغرق حوالي ساعة إضافية لإنشائه. يبدو أن الخطوة المسؤولة عن تأخير الوقت هي خطوة tar — قد يكون هناك شيء في عتادي الأقدم يجعل الوصول إلى العديد من الملفات الصغيرة بطيئًا. مستوى الضغط Gzip مضبوط على 1، لذا أعتقد أن المشكلة محدودة بإدخال/إخراج البيانات وليس بمعالج المعالجة المركزية. يمكن للمضيف الجديد إنجاز نفس النسخة الاحتياطية في 30 إلى 40 دقيقة.

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