المنتدى غير متاح مع خطأ Redis في سجلات Unicorn (

[AxelTerizaki]

مرحباً.

أستضيف منتدين على جهازي، وكلاهما محدث (3.4.0.beta3-dev لأحدهما، ولا يمكنني التحقق من المنتدى الذي لا يمكن الوصول إليه).

تم تحديث أحد المنتديات في وقت سابق من هذا الأسبوع وتوقف فجأة عن العمل قبل يومين.

بمجرد تسجيل الدخول، تظهر رسالة “Oops” على كل صفحة.

ذهبت إلى الحاوية ونظرت إلى سجلات unicorn ويبدو أن هناك مشكلة في الاتصال بـ redis:

فشل في الإبلاغ عن الخطأ: خطأ في الاتصال بـ Redis على localhost:6379 (Errno::ECONNREFUSED) 3 خطأ في جلب المهمة: خطأ في الاتصال بـ Redis على localhost:6379 (Errno::ECONNREFUSED)
فشل في الإبلاغ عن الخطأ: خطأ في الاتصال بـ Redis على localhost:6379 (Errno::ECONNREFUSED) 3 خطأ في جلب المهمة: خطأ في الاتصال بـ Redis على localhost:6379 (Errno::ECONNREFUSED)
فشل في الإبلاغ عن الخطأ: خطأ في الاتصال بـ Redis على localhost:6379 (Errno::ECONNREFUSED) 3 خطأ في جلب المهمة: خطأ في الاتصال بـ Redis على localhost:6379 (Errno::ECONNREFUSED)
فشل في الإبلاغ عن الخطأ: خطأ في الاتصال بـ Redis على localhost:6379 (Errno::ECONNREFUSED) 3 خطأ في جلب المهمة: خطأ في الاتصال بـ Redis على localhost:6379 (Errno::ECONNREFUSED)
فشل في الإبلاغ عن الخطأ: خطأ في الاتصال بـ Redis على localhost:6379 (Errno::ECONNREFUSED) 3 استثناء المهمة: خطأ في الاتصال بـ Redis على localhost:6379 (Errno::ECONNREFUSED) sidekiq-exception
فشل في الإبلاغ عن الخطأ: خطأ في الاتصال بـ Redis على localhost:6379 (Errno::ECONNREFUSED) 3 استثناء المهمة: خطأ في الاتصال بـ Redis على localhost:6379 (Errno::ECONNREFUSED) sidekiq-exception
فشل في الإبلاغ عن الخطأ: خطأ في الاتصال بـ Redis على localhost:6379 (Errno::ECONNREFUSED) 3 استثناء المهمة: خطأ في الاتصال بـ Redis على localhost:6379 (Errno::ECONNREFUSED) sidekiq-exception
فشل في الإبلاغ عن الخطأ: خطأ في الاتصال بـ Redis على localhost:6379 (Errno::ECONNREFUSED) 3 استثناء المهمة: خطأ في الاتصال بـ Redis على localhost:6379 (Errno::ECONNREFUSED) sidekiq-exception
فشل في الإبلاغ عن الخطأ: خطأ في الاتصال بـ Redis على localhost:6379 (Errno::ECONNREFUSED) 3 استثناء المهمة: خطأ في الاتصال بـ Redis على localhost:6379 (Errno::ECONNREFUSED) sidekiq-exception
فشل في الإبلاغ عن الخطأ: خطأ في الاتصال بـ Redis على localhost:6379 (Errno::ECONNREFUSED) 3 استثناء المهمة: خطأ في الاتصال بـ Redis على localhost:6379 (Errno::ECONNREFUSED) sidekiq-exception
فشل في الإبلاغ عن الخطأ: خطأ في الاتصال بـ Redis على localhost:6379 (Errno::ECONNREFUSED) 2 خطأ في الاتصال بـ Redis على localhost:6379 (Errno::ECONNREFUSED) فشل الاشتراك، إعادة الاتصال خلال ثانية واحدة. مكدس الاستدعاء /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:398:in `rescue in establish_connection'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:379:in `establish_connection'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:115:in `block in connect'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:344:in `with_reconnect'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:114:in `connect'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:409:in `ensure_connected'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:269:in `block in process'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:356:in `logging'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:268:in `process'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:161:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rack-mini-profiler-3.3.1/lib/mini_profiler/profiling_methods.rb:89:in `block in profile_method'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis.rb:270:in `block in send_command'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis.rb:269:in `synchronize'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis.rb:269:in `send_command'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/commands/strings.rb:191:in `get'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/message_bus-4.3.8/lib/message_bus/backends/redis.rb:388:in `process_global_backlog'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/message_bus-4.3.8/lib/message_bus/backends/redis.rb:277:in `block in global_subscribe'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/message_bus-4.3.8/lib/message_bus/backends/redis.rb:289:in `global_subscribe'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/message_bus-4.3.8/lib/message_bus.rb:768:in `global_subscribe_thread'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/message_bus-4.3.8/lib/message_bus.rb:739:in `block in new_subscriber_thread'

المشكلة هي أنني لا أرى ما هو الخطأ، حيث يمكنني الاتصال بخادم redis في الحاوية عبر redis-cli وتعيين المفاتيح والحصول عليها بشكل جيد.

أرى العديد من المشكلات المماثلة في المنتدى ولكنها قديمة أو لم يتم حلها. هل يمكن لأحد المساعدة؟ يمكنني تقديم المزيد من المعلومات إذا لزم الأمر.

[pfaffman (Jay Pfaffman)]

هل كان هذا يعمل من قبل؟
متى بدأت؟
هل لديك نسختان من ملف app.yml قياسي، كل منهما بقالب Redis وpostgres خاص بها ومسارات مختلفة للبيانات؟
أحد الاحتمالات هو الأذونات. في مرحلة ما، تغير معرف المستخدم والمجموعة المستخدمان، لكنني لم أر ذلك يمثل مشكلة في الإعدادات ذات الحاوية الواحدة.

[AxelTerizaki]

شكراً لإلقائك نظرة على مشكلتي.

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

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

تعديل: للتوضيح، المنتديان هما ملفا yaml مختلفان، لذا لكل منهما حاويته الخاصة للعمل معها، ودلائل بيانات مختلفة بشكل واضح.

[pfaffman (Jay Pfaffman)]

@AxelTerizaki

لقد فشل بسبب خطأ غريب في postgres

هل فشل في النسخ الاحتياطي أم في الاستعادة؟

سيكون من المفيد لو قمت بتضمين الخطأ الغريب، ولكن إذا كان ذلك أثناء الاستعادة، فأنا أشك في أنه الخطأ الموصوف هنا: Restore failing with missing chat_mention function

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

[AxelTerizaki]

إنه موجود في النسخة الاحتياطية.

pg_dump: error: Dumping the contents of table "posts" failed: PQgetResult() failed.
pg_dump: error: Error message from server: ERROR:  could not open file "base/16384/17044": No such file or directory

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

[pfaffman (Jay Pfaffman)]

يبدو أن هذه مشكلة في قاعدة البيانات بالفعل.

هل قمت باستعادة نسخة احتياطية لنظام الملفات من قبل؟ هذا يبدو من نوع الأشياء التي قد تحدث إذا قمت بعمل نسخة احتياطية لنظام الملفات أثناء تشغيل قاعدة البيانات. إنه أحد الأسباب التي تجعلني لا أوصي بنسخ نظام الملفات الاحتياطية.

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

[AxelTerizaki]

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

هل المعلومات الموجودة في هذا الموضوع لا تزال صالحة لحالتي؟

[pfaffman (Jay Pfaffman)]

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

[AxelTerizaki]

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

آسف على إضاعة الوقت

[pfaffman (Jay Pfaffman)]

عظيم! يسعدني أن تلميحي قد ساعد! لم أكن لأفكر في ذلك أبدًا، لكنني لم أقم بتشغيل برنامج فيروسات منذ فترة طويلة جدًا.