لقد خضع منتدانا لتغيير كبير في البنية التحتية والآن لا يعمل بشكل جيد.
لقد قمت بترحيل قاعدة البيانات لتكون قاعدة بيانات مُدارة في digitalocean، ووضعت أصول S3 على نسخة minio مع cloudflare أمامها.
كما قمت بإعادة نشر discourse باستخدام جهاز افتراضي أصغر ولكنه لا يزال يحتوي على موارد كافية للتعامل مع الحمل.
مما يمكنني رؤيته، هناك استعلامات postgres تستغرق وقتًا طويلاً:
21 ثانية
19 ثانية
إذًا، هل تعكس ذلك؟
على الرغم من أنه ربما جرب آخرون ذلك وسيقدمون نصائح لتحسين هذا النوع من الإعداد.
لماذا هذا غير مدعوم؟
هل لدى discourse خيارات في ملف app.yml لقواعد البيانات الخارجية؟
أنا أحاول توسيع نطاق خادم كبير.
إعجاب واحد (1)
عذراً، سأقوم بإزالة ذلك الآن 
ما مدى قرب قاعدة البيانات المُدارة من مثيلك؟ هل هما في نفس الشبكة؟
نعم، الخادم هو أيضًا DO.
الآن سأقوم بتثبيت أساسي باستخدام الدليل المدعوم واستيراد قاعدة البيانات.
سأرى ما سيحدث بعد ذلك.
هل هناك طريقة لتشغيل عمليات ترحيل قاعدة البيانات هذه يدويًا؟
ولكن يبدو أن خادم بوستجريس الخاص بك غير كافٍ للتعامل مع الحمل؟ ما هو حجم قاعدة بياناتك؟ كم ذاكرة الوصول العشوائي لدى خادم بوستجريس الخاص بك؟
ربما كان يجب عليك الانتظار لترى ما إذا كان خادم بوستجريس الخاص بك يعمل أولاً؟
حسنًا، في الغالب يكون التثبيت القياسي فقط هو “المدعوم”. يجب أن تعمل قاعدة البيانات الخارجية، ولكنك تضيف مجموعة من المتغيرات التي يصعب تخمينها.
هذا أقل دعمًا، ما مدى كبره؟ ثم ما مدى كبر مجموعة من الأشياء؟ قاعدة البيانات، خادم قاعدة البيانات، القطرة التي تعمل عليها، النطاق الترددي بين القطرة وقاعدة البيانات. . . .
هذا مكان جيد للبدء، وبعد ذلك يمكنك البدء في التحقق من الأشياء.
عادةً ما يحدث ذلك عند تمهيد الحاوية، ولكن يمكنك الدخول إلى الحاوية و
cd /var/www/discourse
bin/rails db:migrate
إعجابَين (2)
حتى التثبيت البسيط الخالي لا يعمل، ولم يتم استعادة قاعدة البيانات على الإطلاق.
تم إجراء discourse-setup على جهاز افتراضي نظيف، والتسجيل لا يعمل.
حاولت الاستعادة عبر سطر الأوامر، و discourse restore لا يسرد النسخ الاحتياطية.
تعديل: نجح الأمر بعد إعادة بناء كاملة ثانية.