مشكلة في إعادة البناء بسبب بطء إغلاق قاعدة البيانات

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

الإخراج:

2023-04-19 18:28:31.298 UTC [42] LOG:  received fast shutdown request
2023-04-19 18:28:33.651 UTC [65] LOG:  shutting down
2023-04-19 18:28:33.974 UTC [42] LOG:  database system is shut down


FAILED
--------------------
Pups::ExecError: su postgres -c 'psql discourse -c "alter schema public owner to discourse;"' failed with return #<Process::Status: pid 59 exit 2>
Location of failure: /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/exec_command.rb:117:in `spawn'
exec failed with the params "su postgres -c 'psql $db_name -c \\\"alter schema public owner to $db_user;\\\"'"
bootstrap failed with exit code 2
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.
./discourse-doctor may help diagnose the problem.
c13e1ba313de8fc84f6e2fb0f88197a908803c39791283effb8c82f55b56b6dc
Command exited with non-zero status 1
1.85user 1.84system 3:21.56elapsed 1%CPU (0avgtext+0avgdata 36996maxresident)k
197608inputs+368outputs (1133major+96509minor)pagefaults 0swaps

هل أنت على الفرع التجريبي؟

يمكنك محاولة إعادة تشغيل حاويتك باستخدام

 ./launcher start app

ولكن هذا هو ما يجب أن يفعله discourse-doctor.

ستحتاج إلى تقديم المزيد من المخرجات لأن الخطأ أعلى مما قمت بتضمينه.

إعجابَين (2)

نعم، نحن على فرع بيتا. أنا دائمًا أشغل داخل nohup، لذلك لدي السجل الكامل.

لا يزال Discourse-doctor يعمل، لكنه لم يفشل بعد لذا لدي أمل.

https://pastebin.mozilla.org/iw2zc5zd

تعديل: أعادنا Discourse-doctor إلى العمل.

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

إعجاب واحد (1)

\u003e * 2023-04-19 18:28:26.755 UTC [45] LOG: لم يتم إيقاف تشغيل نظام قاعدة البيانات بشكل صحيح؛ جاري الاسترداد التلقائي

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

هذا لا علاقة له بالتغييرات المدرجة هنا، وهي مشكلة في Discourse منذ عام 2016 على الأقل.

6 إعجابات

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

المصطلحات المتعلقة بـ beta مربكة إلى حد ما. لوحة تحكم المسؤول تقول إننا نعمل بنسخة تجريبية (beta)، هل كان هناك مكان آخر كان يجب أن نبحث فيه؟ فهمي هو أن النسخة التجريبية (beta) موصى بها لـ discourse بناءً على إعلانات الإصدار التي تثبط استخدام الفرع المستقر (stable).

إعجاب واحد (1)

الافتراضي هو في الواقع tests_passed، والذي يعتبر جاهزًا للإنتاج.

إعجاب واحد (1)

ما هو حجم قاعدة البيانات لديك؟ هل هي على SSD؟ ما مقدار ذاكرة الوصول العشوائي لديك؟

وجود حاوية بيانات منفصلة سيتطلب عددًا أقل من عمليات إعادة تشغيل قاعدة البيانات.

متى تم تحديد 60 ثانية للإغلاق الآمن؟ كم عدد التثبيتات الآن أكبر بكثير مما كان طبيعيًا في ذلك الوقت؟

من الناحية المثالية، يجب أن يكون انتظار 60 ثانية هذا عبارة عن انتظار حلقة مغلقة، مع حد. يبدو أن الحد يجب أن يكون أعلى، إذا كان هناك الآن العديد من الحالات التي أصبحت الآن عرضة للخطر.

إعجابَين (2)

إنها 105 جيجابايت، على قرص SSD، وجهاز افتراضي بسعة 16 جيجابايت، وقد أعطيت Postgres مجمع تخزين مؤقت بسعة 8 جيجابايت.

أعتقد أنني رأيت أن ذلك كان في عام 2016 على الأقل. ولكن الأمور قد تغيرت. تعديل: إليك تحديث جديد.

لا أعتقد أن الكثيرين في تثبيت قياسي، حيث كان الأمر كذلك منذ البداية تقريبًا.

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

إعجاب واحد (1)

سننظر في الأمر، هل طريقة التبديل موثقة؟ وهل هناك أي مزايا أخرى لن يوفرها زيادة مؤقت الـ 60 ثانية؟

لقد قمت بزيادته إلى 10 دقائق بالأمس

4 إعجابات

رائع، افترضت أنه كان ينشر الالتزام الأصلي في عام 2016. إذن، هل هناك أي مزايا لنا على الإطلاق؟

يمكنك الاطلاع على Move from standalone container to separate web and data containers

يمكنك بناء حاوية جديدة بينما تستمر الحاوية القديمة في العمل. لا تحتاج إلى إيقاف قاعدة البيانات لبناء حاوية جديدة.

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

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

إذا لم تكن على PG13 فيجب عليك إصلاح ذلك.

سأقوم بإنشاء خادم جديد والانتقال إليه.

نحن الآن، كان ذلك لا مفر منه في نهاية المطاف! بالإضافة إلى قاعدة البيانات، احتجنا أيضًا إلى الترقية من الإصدار 18.04LTS الذي لم يعد مدعومًا.

إعجاب واحد (1)

مع قاعدة بيانات بهذا الحجم، يجب عليك نقلها إلى حاوية مخصصة
سيؤدي ذلك إلى تسريع عمليات إعادة البناء بشكل كبير وتبسيط كل شيء بالنسبة لك

إعجاب واحد (1)

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

إذًا، هل تريد الانتقال بسرعة إلى حاويات ويب وبيانات منفصلة

إعجاب واحد (1)