مجرد تنبيه للناس: لا تحاولوا هذا التحديث خلال أوقات الذروة.
تعمل ترقية الإصدار 2.6.0b2 على خادمنا منذ أكثر من 40 دقيقة، بينما تستغرق عادةً بضع دقائق فقط، وغالبًا ما تنتهي قبل أن تعود للتحقق. كنت قلقًا من أن يكون هناك عطل، لكن عند تسجيل الدخول إلى PostgreSQL، أرى تحديثًا ضخمًا قيد التنفيذ، ويبدو أنه يقوم بتغيير بيانات البحث في المنشورات للرسائل الخاصة.
آمل ألا يكون هناك عطل. أعتقد أنني سأكتشف ذلك. لا أريد حقًا إيقافه أو إعادة تشغيل الحاوية في منتصف الترقية.
الاستعلام قيد التنفيذ:
postgres=# SELECT pid, age(clock_timestamp(), query_start), usename, query
FROM pg_stat_activity
WHERE query != '<IDLE>' AND query NOT ILIKE '%pg_stat_activity%'
ORDER BY query_start desc;
pid | age | usename | query
-------+-----------------+-----------+---------------------------------------------------------------------------
-------------------
698 | | |
701 | | postgres |
699 | | |
697 | | |
696 | | |
14572 | 00:10:31.484201 | discourse | UPDATE post_search_data
+
| | | SET private_message = X.private_message
+
| | | FROM
+
| | | (
+
| | | SELECT post_id,
+
| | | CASE WHEN t.archetype = 'private_message' THEN TRUE ELSE FALSE END pri
vate_message +
| | | FROM posts p
+
| | | JOIN post_search_data pd ON pd.post_id = p.id
+
| | | JOIN topics t ON t.id = p.topic_id
+
| | | WHERE pd.private_message IS NULL OR
+
| | | pd.private_message <> CASE WHEN t.archetype = 'private_message' THEN T
RUE ELSE FALSE END+
| | | LIMIT 3000000
+
| | | ) X
+
| | | WHERE X.post_id = post_search_data.post_id
+
| | |
14573 | 00:47:02.814489 | discourse | SELECT pg_try_advisory_lock(2859260972035668690)
(7 rows)
كانت الترقية بطيئة للغاية بالنسبة لي حتى على الأجهزة السريعة المستضافة في مركز بيانات واحد. لست متأكدًا تمامًا من السبب، لكن من المؤكد أن هناك شيئًا يجب الانتباه إليه.
نعم، أقترح إضافة ملاحظة في سجل التغييرات تحذر المستخدمين من أن هذا التحديث سيستغرق وقتًا أطول بكثير من معظم التحديثات، وألا يقوموا بإيقافه أو اتخاذ أي إجراء جذري لأن ذلك متوقع.
لم يكن لموقعي المحلي الكثير من المنشورات، ومع ذلك كان بطيئًا بشكل ملحوظ. ليس بطيئًا لمدة 40 دقيقة، لكنه كان أبطأ بشكل ملحوظ مقارنة بالترقيات السابقة بحوالي 3 إلى 4 أضعاف، ربما؟
في الواقع، كان عليّ إلغاء عملية إعادة البناء وإعادة تشغيل التطبيق لأنني اعتقدت أنها علقت في الاستعلام الذي ذكرته. لدينا 6 ملايين منشور، وبعد حوالي 45 دقيقة لم تكن قد اكتملت بعد، لذا أظن أنني سأحتاج إلى الاستعداد لمدة ساعة على الأقل لإعادة البناء وتحذير مستخدمينا قبل ذلك.
لقد استخدمت للتو ساعة إيقاف واختبرت إعادة بناء (لموقع يحتوي على حوالي مليون منشور فقط) من الإصدار 2.6.0b1 إلى b2؛ ومن البداية إلى النهاية، استغرق الأمر 170 ثانية.
كان لدي موقع كبير فشل مرارًا وتكرارًا في عملية التمهيد. كان التثبيت يتكون من حاويتين، لذا استمرت الحاوية القديمة في العمل أثناء هجرة عملية التمهيد. وقد تمكنت في النهاية من حل المشكلة بتفعيل SKIP_POST_DEPLOYMENT_MIGRATIONS=1 لعملية التمهيد، ثم تشغيل عمليات الهجرة بعد بدء تشغيل الحاوية الجديدة. ومع وجود SKIP_POST_DEPLOYMENT_MIGRATIONS=1 في قسم ENV، كانت عملية الهجرة سريعة جدًا، مما سمح للموقع بالعمل بشكل طبيعي (وإن كان ربما بشكل أبطأ) أثناء تنفيذ عمليات الهجرة التي استغرقت أكثر من 20 دقيقة، حسب ظني.
أعتقد، دون أن أختبر ذلك بعد، أن استخدام نفس الحيلة سيساعد في تقليل وقت التوقف أثناء التثبيت ذو الحاوية الواحدة أيضًا. وإذا كنت محقًا، فستقوم بما يلي:
أضف SKIP_POST_DEPLOYMENT_MIGRATIONS=1 إلى ملف app.yml الخاص بك.
قم بتشغيل ./launcher rebuild app.
ثم ./launcher enter app.
بعد ذلك، شغّل SKIP_POST_DEPLOYMENT_MIGRATIONS=0 rake db:migrate.
أعد التعديل في app.yml إلى حالته الأصلية إلا إذا كنت تنوي تذكر إجراء عمليات الهجرة بعد كل ترقية.
ربما قم بإعادة البناء مرة أخرى للتأكد من عدم وجود أي مشاكل، خاصة أنك قد لا تتذكر ما قد يكون سببًا في تعطيل موقعك بعد أربعة أشهر عندما تحاول مرة أخرى، وعندها لن يكون لديك أي فكرة، وسيكون من الصعب على أي شخص تخمين ما قد يكون المشكلة.
لو كان هناك طريقة لجعل ./launcher يمرر SKIP_POST_DEPLOYMENT_MIGRATIONS=1 إلى العناصر دون الحاجة إلى تعديل ملف app.yml، لكان ذلك يجعل الأمور أقل تعقيدًا لمن يواجهون صعوبة في التحرير.
إذا تمكنت من إنجاز العمل في هذا المجال كما أعتقد أنني سأفعل، فسأنشئ موضوعًا جديدًا للإبلاغ عما توصلت إليه. لكن الدخان يجعلني معزولًا في غرفة لا أملك فيها شاشتي الكبيرة. (ألم يكن الوباء كافيًا؟! هل يجب أن يكون لدينا دخان أيضًا؟ وأنا لست حتى قريبًا بشكل خاص من النار تلك.)
هل هناك سبب تقني يجعل تغييرات قاعدة البيانات بعد الترقية بحاجة إلى أن تكون حجبًا افتراضيًا؟ هل توجد طريقة لتغيير هذا السلوك بحيث يتم إعادة تشغيل الموقع بسرعة بعد الترقيات المستقبلية، ثم يتم تنفيذ ما بعد الترقية في الخلفية؟
في رأيي، أي شيء ضروري لعمل التطبيق المُرقَّى، مثل DDL، يجب أن يكون جزءًا من الترقية نفسها، وليس في سكريبات ما بعد الترقية.
) شكرًا جزيلًا لك.