ما الذي يحدث للعروض المُجسَّدة القابلة للتحديث عند إعادة تشغيل الخادم

لماذا قد تُحدَّث جميع العروض المُجسَّدة القابلة للتحديث دفعةً واحدة عند إعادة تشغيل الخادم، وكيف يمكن إعادة تشغيلها واحدًا تلو الآخر.

إذا لم تكن عمليات تحديث العرض المُجسَّد القابل للتحديث مُنسَّقةً عبر ClickHouse Keeper، فإنه ينسى موعد آخر تحديث له، ومن ثَمّ قد يُحدَّث مجددًا بمجرد أن يصبح الخادم جاهزًا. وإذا كان الخادم يضم عددًا كبيرًا من هذه العروض، أو عروضًا مبنية على مجموعات بيانات ضخمة، فقد تنطلق عمليات تحديث كاملة كثيرة لمجموعات البيانات في آنٍ واحد، وذلك في اللحظة التي يكون فيها الخادم أقل قدرةً على استيعابها.

​

ما العروض التي تحافظ على جدولها الزمني؟

تُنسَّق عمليات التحديث عبر ClickHouse Keeper للعروض الموجودة في قاعدة بيانات Replicated. وينطبق الأمر نفسه في ClickHouse Cloud على قاعدة بيانات Shared. ويمكن للعرض المنتمي إلى عائلة APPEND في أيٍّ من قاعدتَي بيانات Cloud هاتين أن يُعفى من التنسيق باستخدام SETTINGS all_replicas = 1؛ أما على خادم ClickHouse مفتوح المصدر، فلا يتوفر هذا التنسيق إلا في قاعدة بيانات Replicated. ويحتفظ العرض غير الخاضع للتنسيق بوقت آخر تحديث له في الذاكرة فقط، لذا تجعله إعادة التشغيل متأخرًا عن موعده في أي جدول زمني عادي. ولا يؤدي RANDOMIZE FOR إلى توزيع عمليات التحديث هذه على فترات زمنية متباعدة.

​

قد تؤدي عمليات التحديث الإضافية أيضًا إلى تكرار البيانات

يُضيف العرض من نوع APPEND نتيجة كاملة أخرى. أما العرض من نوع APPEND INCREMENTAL غير المنسَّق، فيفقد مؤشره المخزَّن في الذاكرة عند إعادة التشغيل ما لم يكن جدول الهدف المعاملاتي الخاص به قد ثبّت هذا المؤشر، فيعيد بذلك معالجة الصفوف التي سبق أن أضافها.

يَحُدّ تشغيل العروض على مراحل، كما هو موضح أدناه، من عدد عمليات التحديث التي تعمل في آنٍ واحد، لكنه لا يمنع تشغيلها. ويتجنّب العرض من نوع APPEND الإضافة الزائدة إذا لم تشغّله إلا حين يحين موعد تحديثه التالي أصلًا. أما العرض من نوع APPEND INCREMENTAL الذي فقد مؤشره، فلا يجني أي فائدة من اختيار التوقيت، لأنه متى عمل في المرة التالية سيعيد معالجة جدول المصدر بالكامل ويُضيف تلك النتيجة؛ لذا أبقِه متوقفًا إلى أن تتمكن من استيعاب الصفوف المكررة أو إزالتها.

​

إبقاء جميع طرق العرض متوقفة عند بدء تشغيل الخادم

عيِّن stop_refreshable_materialized_views_on_startup في ملف تعريف الإعدادات الخاص بالخادم نفسه، أي ملف التعريف المحدد في system_profile، وإن لم يكن محددًا فيُستخدم default_profile ثم default. هذا الإعداد تجريبي:

/etc/clickhouse-server/users.d/refreshable_materialized_views.xml

<clickhouse>
    <profiles>
        <default>
            <stop_refreshable_materialized_views_on_startup>1</stop_refreshable_materialized_views_on_startup>
        </default>
    </profiles>
</clickhouse>

يستخدم هذا المثال ملف التعريف الافتراضي default. استبدله بملف التعريف المخصص system_profile إن كنت تستخدمه.

لا تُعدّ العبارة SYSTEM STOP VIEWS بديلًا مناسبًا، لأن حالة الإيقاف التي تضبطها لا تبقى قائمة بعد إعادة التشغيل.

​

تشغيل العروض واحدًا تلو الآخر

تُشغّل العبارة SYSTEM START VIEWS جميع العروض دفعة واحدة، مما يُحدث الذروة نفسها، لذا شغّل كل عرض على حدة باسمه، وانتظر حتى يكتمل تحديثه قبل تشغيل العرض التالي. ويعرض الجدول system.view_refreshes قائمة بهذه العروض. في ClickHouse Cloud، يكون جدول النظام هذا محليًا على مستوى كل عقدة، لذا افحص كل عقدة على حدة:

SYSTEM START VIEW my_database.my_view;
SYSTEM WAIT VIEW my_database.my_view;

لا يؤدي تشغيل العرض إلا إلى استئناف جدوله الزمني، وخلافًا لـ SYSTEM REFRESH VIEW فإنه لا يُطلق أي تحديث إضافي من جهته. أما العرض الذي حلّ موعد تحديثه أثناء إيقافه، فيكون متأخرًا أصلًا وفق ذلك الجدول، ولذا يُحدَّث فور تشغيله، وتبقى SYSTEM WAIT VIEW في حالة انتظار ما دام ذلك التحديث قيد التنفيذ.

العرض الذي ينتظر متطلبًا مسبقًا محددًا عبر REFRESH ... DEPENDS ON لا يبدأ التحديث بعد، لذا شغّل هذه العروض بعد العروض التي تعتمد عليها. أما الاعتماد الدائري فليس له ترتيب كهذا، وتؤدي إعادة التشغيل إلى كسر الدورة ما لم تُنسَّق عروضها: شغّل جميع الأعضاء، ثم نفّذ عبارة SYSTEM REFRESH VIEW نفسها التي نفّذتها لبدء الدورة عند إنشائها، وانتظر اكتمال ذلك التحديث. وإذا تطلّب بدء الرسم البياني أكثر من تحديث واحد من هذا النوع، فإنه يحتاج إلى المجموعة نفسها مجددًا. وقد يؤدي تفعيل عضو مختلف إلى بقاء الدورة خاملة، لأن العرض لا يستأنف عمله إلا بعد تحديث جميع متطلباته المسبقة. وبمجرد تفعيل الدورة فإنها تُحدَّث تلقائيًا، ولذا يتوقف التشغيل التدريجي، عرضًا تلو الآخر، عند نقطة التفعيل.

​

ما يعنيه ذلك لعمليات الأتمتة لديك

ما دام هذا الإعداد مُفعَّلًا، فإن أي إعادة تشغيل غير مخطط لها تُبقي جميع العروض المُجسَّدة القابلة للتحديث متوقفة، كما أن أي عرض يُنشأ حديثًا لا تبدأ عمليات تحديثه إلى أن يُشغَّل هو الآخر. ويُستثنى من ذلك RESTORE بالنسبة إلى العروض التي لا تكون عمليات تحديثها منسَّقة، إذ يُشغِّل كل عرض من هذا النوع يتضمنه، وقد يصبح هذا العرض عندئذٍ متأخرًا عن موعده فورًا فيعيد معالجة بيانات مصدره. أما العرض المنسَّق فلا تُشغِّله عملية الاستعادة، ولذلك يبقى متوقفًا إلى أن تُشغِّله بنفسك. لذا احرص على أن تتولى الأتمتة المسؤولة عن إعادة تشغيل الخوادم وإنشاء العروض لديك مهمةَ تشغيل هذه العروض أيضًا.