أود فتح نقاش حول أفضل الممارسات لأداء مهام الصيانة الأساسية على مثيل Discourse مع تقليل أو إلغاء وقت التوقف عن العمل.\n\nالمهام مثل تغيير إعدادات الموارد الهامة (مثل UNICORN_WORKERS، DISCOURSE_SIDEKIQ_WORKERS، DISCOURSE_DB_POOL) أو تطبيق التحديثات الرئيسية تتطلب عادةً launcher rebuild app، والتي يمكن أن تستغرق وقتًا طويلاً، أحيانًا 30 دقيقة أو أكثر.\n\nسؤالي هو:\nما هي الاستراتيجيات الموصى بها لمسؤولي النظام لأداء هذه التحديثات الأساسية وتغييرات التكوين بأقل قدر من وقت التوقف عن العمل للمستخدمين؟\n\nهل هناك أي تقنيات متقدمة، مثل عمليات النشر الأزرق/الأخضر أو استراتيجيات النشر الأخرى بدون توقف، مدعومة أو موصى بها لـ Discourse؟ أم أن عملية rebuild القياسية هي الطريقة الوحيدة المدعومة، ويجب أن يركز التركيز على تحسين وقت إعادة البناء نفسه؟\n\nأنا مهتم بسماع آراء أي شخص لديه خبرة في إدارة المثيلات الكبيرة أو ذات حركة المرور العالية وما هو سير العمل الخاص بهم للصيانة.\n\nشكرًا على أي رؤى!
إذا كان لديك تثبيت يحتوي على حاويتين، فسيتم بناء الحاوية الجديدة بينما تعمل الحاوية القديمة. وقت التعطل هو فقط مقدار الوقت الذي يستغرقه تشغيل الحاوية الجديدة. المشكلة الوحيدة هي أنك بحاجة إلى ذاكرة وصول عشوائي كافية لبناء حاوية بينما تعمل الأخرى.
الانتقال من حاوية مستقلة إلى حاويات ويب وبيانات منفصلة، ولكنني عادةً ما أنقل جهازًا افتراضيًا جديدًا.
إذا كنت تريد وقت تعطل صفر، فأنت بحاجة إلى موازن تحميل يحافظ على تشغيل الحاوية القديمة حتى تبدأ الحاوية الجديدة بالكامل. ثم تقوم بإيقاف تشغيل الحاوية القديمة وتجري عمليات الترحيل بعد التحديث.
هل يمكنك وضع حاويتي بيانات في حالة تجاوز الفشل؟
هل تستخدم جهازًا افتراضيًا منفصلاً للبيانات عادةً؟
يعد Discourse مستقرًا جدًا لدرجة أن هذا غير ضروري في معظم عمليات التثبيت (ولكن أعتقد أنه قد تفكر فيه لمتطلبات التوفر العالي جدًا أو إذا كنت تستضيف آخرين؟!)
لا أعتقد أنني واجهت انقطاعًا واحدًا في 7 سنوات بسبب “خلل” إنتاجي …
أكثر اللحظات خطورة في حياة Discourse تكون دائمًا عند إعادة البناء.
يمنحك إعداد الحاوية المزدوجة القدرة على تمهيد بناء جديد قبل الالتزام به، على الرغم من أن هذا لن يلتقط بعض أخطاء وقت التشغيل بالطبع.
المشكلة هي أنه إذا تم تشغيل عمليات الترحيل الخاصة بك، فقد تحتاج إلى الالتزام بالبناء الجديد، ولذلك ستحاول عادةً تتبع مصدر هذه الأخطاء وإصلاحها بدلاً من التراجع.
بشكل عام، لا يحاول الأشخاص التراجع …
أنتقل إلى جهاز افتراضي جديد عند إجراء إعادة تكوين كبيرة.
من الممكن تشغيل نسخة طبق الأصل من PostgreSQL، ولكنها تتطلب الكثير من العمل.
هل النسخة الاحتياطية للقراءة أفضل؟
نعم! النسخة المتماثلة! هذه هي الكلمة التي يستخدمونها. وبعد ذلك، إذا مات الآخر، يمكنك التبديل السريع إلى النسخة المتماثلة.