Cloud instance مقفلة بالكامل للكتابة 8 ساعات — SqliteWriteConnectionMutex، إعادة تشغيل لوحة التحكم متعطلة

أسئلة
,
1

وصف المشكلة/الخطأ/السؤال

ملاحظة: أنا على علم بأن النموذج يوجّه مشاكل Cloud إلى help@n8n.io — تم تقديم التذكرة بالفعل وتم التأكيد عليها تلقائياً مع توقع استجابة في غضون 3 أيام. أنشر هنا لأن المثيل قد تم قفله بالكامل لمدة 8+ ساعات، وإعادة تشغيل لوحة تحكم المسؤول قد توقفت بنفسها، ولا توجد أي إجراءات متبقية من جانب العميل.

مثيل الإنتاج الخاص بنا على Cloud غير قادر على إجراء أي كتابة في قاعدة البيانات منذ 2026-08-18 ~22:52 UTC. 83 سير عمل نشط معطّل. خطة Pro.

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

إعادة التشغيل المحاولة: طلبت ترقية إصدار من لوحة تحكم المسؤول لفرض إعادة التشغيل. حالة Workspace تُظهر “قيد التقدم” على n8n@1.123.69 دون الدوران، بينما يستمر المثيل في تقديم الطلبات على الإصدار القديم — يبدو أن العملية لا تنتهي.

السجل على هذا المثيل: تنظيف جداول الأعطال في جدول التنفيذ في 2026-07-20 و07-30 و08-02 و08-13 يُظهر أن العامل مات تقريباً أسبوعياً. تم استرجاعها تلقائياً. هذه لم تسترجع.

ذات صلة: Timeout waiting for lock SqliteWriteConnectionMutex — مستخدم Cloud Pro يبلّغ عن هذا عدة مرات يومياً عبر العديد من سير العمل (أكتوبر 2025، v1.112.6)، بما في ذلك نفس أعراض النقر على المجلد. أبلغوا بأن إعادة التشغيل ولا الترقية حلّتها، وأكد مستخدم ثانٍ نفس الخطأ، وتم إغلاق الموضوع بدون حلّ من الموظفين. بعد عشرة أشهر، أنا أواجه نفس الفشل على 1.123.69.

لذا أطلب شيئين: (1) إعادة تشغيل قسري لهذا المثيل، و(2) السبب الفعلي ومسار الإصلاح. هل هذا قيد معروف من SQLite write contention على Cloud بهذا الحمل — 83 سير عمل نشط، ~8,000 تنفيذ/شهر — وإذا كان الأمر كذلك، هل deployment مدعوم بـ Postgres أو مخصص هو الحل؟ إعادة تشغيل تترك المثيل فاشلاً مرة أخرى في الأسبوع القادم ليست حلاً.

المثيل: htzone.app.n8n.cloud

ما رسالة الخطأ (إن وجدت)؟

Timeout waiting for lock SqliteWriteConnectionMutex to become available

مقاسة من console المتصفح:

  • GET /rest/workflows?limit=1 → 200 في 274ms (القراءات سليمة)
  • POST /rest/tags → لا استجابة، تم الإجهاض عند 35,005ms
  • GET /rest/projects/…/folders/…/tree → 500 بعد 60,084ms (انتظارا قفل مكدسة لمدة 30 ثانية)
  • GET /rest/workflows?includeFolders=true → 500 مع خطأ mutex أعلاه
  • GET /rest/insights/summary و/rest/data-tables-global/limits → نفس خطأ mutex
  • صفر تنفيذات في حالة new أو running — لا شيء يتم تنفيذه، لذا يبدو أن هذا اتصال عالق وليس معاملة حية

استجابات Webhook: {"code":0,"message":"There was a problem executing the workflow"}

يرجى مشاركة سير العمل الخاص بك

غير قابل للتطبيق — هذا على مستوى المثيل، وليس خاص بسير عمل. لا يمكن لأي سير عمل أن ينفذ.

شارك الناتج الذي أرجعته العقدة الأخيرة

غير قابل للتطبيق — لا يمكن أن يبدأ أي تنفيذ.

المعلومات حول إعداد n8n الخاص بك

  • إصدار n8n: 1.123.69
  • قاعدة البيانات (الافتراضي: SQLite): SQLite (تُدار على الـ Cloud)
  • إعداد n8n EXECUTIONS_PROCESS (الافتراضي: own, main): الافتراضي (يُدار على الـ Cloud، غير قابل للتكوين)
  • تشغيل n8n عبر (Docker، npm، n8n cloud، تطبيق سطح المكتب): n8n Cloud
  • نظام التشغيل: N/A (مُدار) — العميل: Chrome
2

مرحباً @Uri_Ironi_HitechZone، بينما تنتظر الرد، إليك بعض الأشياء التي قد تساعدك:

الموارد المقترحة

تم مطابقتها تلقائياً مع سؤالك.

المستندات:

المنتدى:

@Igor_Ziemczyk، @ihortom - لقد ساعدتما في مشاكل مشابهة من قبل، هل يمكنكما أن تلقيا نظرة؟

اقتُرحت تلقائياً من قبل روبوت المجتمع الخاص بـ n8n. إنه برنامج تجريبي - يرجى مشاركة ملاحظاتك هنا.

3

مرحباً @Uri_Ironi_HitechZone أهلاً وسهلاً!
كل عملية كتابة على Cloud تمر عبر اتصال كتابة SQLite واحد خلف mutex مدته 30 ثانية، مشترك بين كل تنفيذ متزامن وكل محرر وكتابة REST، وهذا هو السبب في بقاء القراءات بصحة جيدة بينما أي شيء يلمس مسار الكتابة يتراكم انتظارات لمدة 30 ثانية. العملية التي تتعطل في منتصف المعاملة تترك ذلك الاتصال محتفظاً به، وتغيير الإصدار يجلس عند “In progress” لأن العملية القديمة لن تنهي بينما هي كذلك. عادة ما يكون تغيير الإصدار إعادة تشغيل مدتها 1 إلى 2 دقيقة، لذا في 8 ساعات لا يوجد شيء متبقٍ من جانب العميل، فقط n8n يمكنه مسح ذلك الاتصال.
فيما يتعلق بالتكرار: Pro-1 يحتوي على 640MiB RAM و20 millicore CPU قابل للانفجار، مع استخدام n8n نفسه حوالي 180MiB، و Pro يقص عند 25000 عملية تنفيذ أو 30 يوم. 83 سير عمل نشط بحوالي 8k عملية تنفيذ/شهر يترك حوالي لا توجد هامش على مسار الكتابة هذا، وهذا يتناسب مع عمليات التنظيف الأسبوعية التي تشهدها. الرافعة التي لديك هي الكتابة بكمية أقل: Admin Panel > Manage > Executions to Save، وألغِ تحديد عمليات الإنتاج الناجحة. Pro-2 هو الخطوة التالية عند 1280MiB و80 millicore.
لا يمكن اختيار Postgres على Cloud، DB_TYPE هي متغير يدوي الاستضافة، لذا يعني الدعم بـ Postgres الاستضافة الذاتية.

إذا انتهى بك الحال إلى الموازنة بين تلك الخطوة، فهذا يغطي المقايضات:

5

شكراً لإخبارنا بهذا، لقد أنشأنا CAT-4137 كتذكرة تطوير داخلية للنظر في المسألة.