مستوى الثقة 0: 557 ولكن داخله 439
مستوى الثقة 1: 480 ولكن داخله 412
مستوى الثقة 2: 300 ولكن داخله 298
مستوى الثقة 3: 37 ولكن داخله 35
مستوى الثقة 4: 4 ولكن داخله 2
كما أن تنفيذ أمر “select count(*) from users” يعطي أيضًا 441، وهو ما يتطابق مع 439 + النظام + discobot.
يبدو أن الأرقام المعروضة لجميع المجموعات الأخرى في ملخص المجموعات صحيحة.
كيف يمكنني تصحيح الأرقام في الملخص؟
نحن نستخدم الإصدار الحالي 2.6.0.beta5 ( 698b7ace10 )، ولكن هذه المشكلة ربما كانت موجودة أيضًا في الإصدارات الأقدم.
حسنًا، حتى بعد 12 ساعة لا تزال القيم غير صحيحة؛ فقد تم تخفيض جميع القيم من مستوى الثقة 0 إلى مستوى الثقة 4 بمقدار 2 فقط (لسبب ما). تبدو عدادات المجموعات الأخرى صحيحة.
لا، كان آخر حذف لمستخدم قبل يومين بالفعل.
في الـ 14 يومًا الماضية، قمت بحذف 7 مستخدمين فقط.
في آخر 1.5 سنة، قمت بحذف أكثر من 2000 مستخدم. لدينا إضافة autosupend مفعلة، ونقوم بتعليق المستخدمين تلقائيًا الذين لم يمارسوا أي نشاط لأكثر من 365 يومًا. ثم نقوم بحذف هؤلاء المستخدمين المعلّقين تلقائيًا وجميع بياناتهم مرة واحدة على الأقل أسبوعيًا، لضمان امتثالنا للائحة حماية البيانات العامة للاتحاد الأوروبي (GDPR).
يعمل Sidekick بشكل جيد، ولا توجد مهام متوقفة.
بحسب ما أتذكر، لم يتغير عدد المهام التي فشلت في الأيام القليلة الماضية.
ما هي وظيفة الطابور 0f13eb003564dea87a7cc8f25560ba0e؟
هل هذا الطابور ضروري أم يجب حذفه؟
أعتقد أنني وجدت المشكلة؛ فجدول group_users لا يزال يحتوي على إدخالات لـ user_id لم تعد موجودة، ولم تعد مدرجة في جدول users. (إجمالي 182 إدخالًا لـ 117 user_id لا يوجد لها إدخال مطابق في جدول users).
إذن، يبدو أن قاعدة البيانات تحتوي على بعض التناقضات. لا أعرف كيف حدث ذلك.
والسؤال الآن هو: كيف يمكنني حل هذه المشكلة؟
هل يجب حذف الإدخالات من group_users التي لا يوجد لها إدخال مطابق في users يدويًا عبر أمر SQL؟
