لقد قمنا للتو بإصدار صورة حاوية جديدة تمامًا سيتم استخدامها في عملية ./launcher rebuild app التالية. وكالمعتاد، لا حاجة لتغيير أي من إعداداتك طالما أنك اتبعت دليل التثبيت القياسي الرسمي لمنصة Discourse. ومع ذلك، توجد ميزات جديدة ستساعد بعض المنشآت.
Redis 6
نستخدم Redis بشكل مكثف في العديد من الأماكن داخل Discourse، سواء كان ذلك للذاكرة المؤقتة (cache)، أو Sidekiq، أو MessageBus، أو الأقفال الموزعة، أو حدود المعدل. وبشكل عام، كان خيارًا قويًا وموثوقًا لنا.
ومع ذلك، في أحمال عمل محددة جدًا، قد يصبح Redis عنقًا زجاجة. وبسبب الطبيعة أحادية الخيط لـ Redis، مقترنةً بعدم قدرتنا على استخدام مثيلات متعددة بسبب نصوص LUA الخاصة بنا، فقد كان هذا عائقًا صعب التجاوز.
لحسن الحظ، يأتي Redis 6 مع دعم لاستخدام مجموعة خيوط (thread pool) لعمليات الإدخال/الإخراج، وقد أثبتت اختباراتنا أنه يعمل بشكل ممتاز مع مجموعات Discourse التي تعاني من اختناقات في Redis.
لذا، إذا كنت تعمل على جهاز يحتوي على عدد كبير من أنوية المعالج، وتُظهر المقاييس أن Redis يكافح للتعامل مع الحمل، فيمكنك الآن الاختيار لاستخدام الخيوط لعمليات الكتابة عبر قسم المعاملات params في ملف app.yml:
params:
redis_io_threads: "4" # القيمة 1 تعطل هذه الميزة، والقيم الأكبر من 1 تستخدم n-1 خيطًا إضافيًا لعمليات الكتابة
صورة أصغر حجمًا
قررنا في وقت مبكر من المشروع إصدار صورة حاوية كبيرة لتسهيل تشغيل Discourse على الأشخاص غير التقنيين، وللتعامل مع جميع التبعيات الضرورية، وإدارة الإصدارات، والترقيات، وما إلى ذلك.
ومع ذلك، تجاوزنا مؤخرًا حجم 1 جيجابايت للصورة المضغوطة، وكان ذلك كبيرًا جدًا.
وللتخفيف من الحجم المتزايد باستمرار للصورة، قمنا بنقل كود مصدر Discourse داخل الصورة من نسخة كاملة من الكود إلى “استنساخ سطحي” (shallow clone) يحتوي فقط على أحدث إصدار من الكود.
هذا التغيير يجعل حجم الصورة المضغوطة أصغر بنسبة 25%، مما يؤدي إلى الحاجة لمساحة خادم أقل وإعادة بناء أسرع عند إصدار صورة جديدة. كما يجب أن يتحكم في نمو الصورة بمرور الوقت.
لقد اختبرنا ذلك في بيئات tests-passed/beta/stable، مع كل من عمليات إعادة البناء وتحديثات الويب، ولم يكسر أي من المسارات القياسية. ومع ذلك، قد يحتاج المستخدمون الذين يقومون بأشياء git غير تقليدية في خطافات app.yml إلى تكييف تخصيصاتهم.
ألا تستخدم المواقع المتعددة قاعدة بيانات واحدة ومساحات مفاتيح Redis القياسية؟ حسب علمي، قواعد بيانات Redis هي طبقة رقيقة، ولدينا أوامر تعبر حدودها، لذا لا ينبغي الاعتماد على ذلك.
أوه. إذن ليس موقعًا متعددًا، بل عدة نسخ تعمل على جهاز واحد وكل منها يحتاج إلى قاعدة بيانات Redis منفصلة. قمت بزيادة القيمة الافتراضية من 16 إلى 50 فقط لأنني كنت كسولًا جدًا للحفاظ على تحكم دقيق في قواعد بيانات Redis قيد الاستخدام.
إذن، هل يجب أن أشغل حاوية Redis منفصلة لكل نسخة، أظن؟
لحسن الحظ، تعلمت هذا على خادم يُستخدم فقط للاختبار.
بالنسبة للمواقع الأخرى، هل يجب أن أعطيها قاعدة بيانات Redis جديدة وأتجاهل ما تم جدولته؟ أم أقوم بنسخ احتياطي واستعادة؟
بالمناسبة، لم ألاحظ أي مشاكل في التداخل بين القنوات خلال العام الماضي أو نحو ذلك. وهناك طريقة لتحديد قاعدة البيانات.
تعديل: حسنًا، الخبر الجيد هو أنه يمكنني الدخول إلى الحاوية، وتعديل ملف redis.conf، وإعادة تشغيله، وسيعمل مرة أخرى.
إذا كانت لديك أي تلميح حول كيفية نقل موقع من DISCOURSE_REDIS_DB: 12 في حاوية Redis واحدة إلى حاوية Redis أخرى، فستكون سعيدًا جدًا لسماعه. أو ربما لا تهتم بالمهام المجدولة؟
هذا ما كنت أظنه، حيث لا أعرف أي طريقة تحاول النسخ الاحتياطي من خلالها استعادته (لكن هناك الكثير مما لا أعرفه). يبدو أنني يمكنني فعل ذلك بهذه الطريقة: https://stackoverflow.com/questions/23222616/copy-all-keys-from-one-db-to-another-in-redis، ويبدو أن هذا نجح في اختبار أجريته للتو، لكن سيكون من الأسهل بكثير تعديل خطة اللعب الخاصة بي لإنشاء حاوية Redis جديدة واستخدامها.
شكرًا لك.
الآن يجب أن أقرر ما إذا كنت سأنفذ هذه خوادم Redis على خادم قاعدة البيانات أم على خادم الويب…
[quote=“sam, post:10, topic:171437, full:true”]
نعم، يستخدم الموقع المتعدد قاعدة بيانات واحدة
[/quote] إذن إلى ماذا يشير db_id: 2 في إعدادات الموقع المتعدد؟
فقط تأكد من إعادة تشغيل Unicorn مباشرة بعد ذلك، حتى يعيد إنشاء المهام المجدولة.
ستفقد أي شيء في قائمة الانتظار، لذا تحتاج إلى اختيار وقت مناسب للقيام بذلك.
وهناك طريقة لتحديد قاعدة البيانات.