SYSTEM

أعِد تحميل جميع القواميس الداخلية. تكون القواميس الداخلية معطّلة افتراضيًا. يعيد دائمًا Ok. بغضّ النظر عن نتيجة تحديث القواميس الداخلية.

يعيد الاستعلام SYSTEM RELOAD DICTIONARIES تحميل القواميس التي تكون حالتها LOADED (راجع العمود status في system.dictionaries)، أي القواميس التي سبق تحميلها بنجاح. تُحمَّل القواميس افتراضيًا بأسلوب التحميل عند الطلب (راجع dictionaries_lazy_load)، لذلك بدلًا من تحميلها تلقائيًا عند بدء التشغيل، تُهيَّأ عند أول وصول إليها باستخدام الدالة dictGet أو بتنفيذ SELECT على الجداول التي تستخدم ENGINE = Dictionary.

الصياغة

SYSTEM RELOAD DICTIONARIES [ON CLUSTER cluster_name]

يعيد تحميل القاموس dictionary_name بالكامل، بغضّ النظر عن حالته (LOADED / NOT_LOADED / FAILED). ويُرجع دائمًا Ok. بصرف النظر عن نتيجة تحديث القاموس.

SYSTEM RELOAD DICTIONARY [ON CLUSTER cluster_name] dictionary_name

يمكن التحقق من حالة القاموس عبر الاستعلام عن الجدول system.dictionaries.

SELECT name, status FROM system.dictionaries;

يفرّغ القاموس dictionary_name لتحرير الذاكرة التي يستخدمها إذا كانت حالة القاموس هي LOADED. ويُعاد تحميل القاموس تلقائيًا عند الحاجة إليه مجددًا.

SYSTEM UNLOAD DICTIONARY dictionary_name

يمكن التحقق من حالة القاموس عبر الاستعلام عن جدول system.dictionaries.

SELECT name, status FROM system.dictionaries;

يفرّغ الاستعلام SYSTEM UNLOAD DICTIONARIES جميع القواميس التي تكون حالتها LOADED (راجع العمود status في system.dictionaries)، أي القواميس التي سبق تحميلها بنجاح.

SYSTEM UNLOAD DICTIONARIES

يفرّغ جميع نماذج CatBoost من الذاكرة.

الصياغة

SYSTEM RELOAD MODELS [ON CLUSTER cluster_name]

يلغي تحميل نموذج CatBoost الموجود في model_path.

الصياغة

SYSTEM RELOAD MODEL [ON CLUSTER cluster_name] <model_path>

يعيد تحميل جميع الدوال المعرفة من قبل المستخدم القابلة للتنفيذ المسجَّلة، أو إحداها، من ملف التهيئة.

الصياغة

SYSTEM RELOAD FUNCTIONS [ON CLUSTER cluster_name]
SYSTEM RELOAD FUNCTION [ON CLUSTER cluster_name] function_name

يعيد حساب جميع المقاييس غير المتزامنة. ونظرًا إلى أن المقاييس غير المتزامنة تُحدَّث دوريًا استنادًا إلى الإعداد asynchronous_metrics_update_period_s، فلا تكون هناك حاجة عادةً إلى تحديثها يدويًا باستخدام هذه العبارة.

SYSTEM RELOAD ASYNCHRONOUS METRICS [ON CLUSTER cluster_name]

يمسح ذاكرة التخزين المؤقت الداخلية لـ DNS في ClickHouse. وأحيانًا (في الإصدارات القديمة من ClickHouse) يكون من الضروري استخدام هذا الأمر عند تغيير البنية التحتية (مثل تغيير عنوان IP لخادم ClickHouse آخر أو للخادم الذي تستخدمه القواميس).

للحصول على إدارة أكثر سهولة (وتلقائية) لذاكرة التخزين المؤقت، راجع المعلمات disable_internal_dns_cache وdns_cache_max_entries وdns_cache_update_period.

يمسح ذاكرة تخزين العلامات المؤقتة.

يمسح ذاكرة التخزين المؤقت للفهرس الأساسي، التي تحتفظ بالمفاتيح الأساسية لجداول MergeTree في الذاكرة. يُضبط حجمها باستخدام الإعداد primary_index_cache_size على مستوى الخادم.

يمسح ذاكرة التخزين المؤقت للبيانات الوصفية الخاصة بـ Iceberg.

يمسح ذواكر التخزين المؤقت لكل عنوان URL في Confluent Schema Registry والمستخدمة بواسطة التنسيق AvroConfluent. تُسقِط هذه العملية كلاً من ذاكرة التخزين المؤقت لجلب المخططات (id → schema) وذاكرة التخزين المؤقت لتسجيل المخططات (subject + schema → id)، لذا ستعود عمليات القراءة والكتابة اللاحقة إلى خادم السجل. ويكون ذلك مفيدًا عندما يكون مخطط قد حُذف أو أُعيدت كتابته على جانب السجل، أو للتحقق من خاصية idempotency الخاصة بالسجل في الاختبارات.

يمسح ذاكرة التخزين المؤقت للبيانات الوصفية لملفات Parquet.

يمسح ذاكرة التخزين المؤقت الموجودة في الذاكرة لملفات البيانات الوصفية المحلَّلة الخاصة بـ Paimon (manifest lists وmanifests).

يمسح ذاكرة التخزين المؤقت للمضلعات الثابتة المُعالجة مسبقًا والمستخدمة من قِبل الدالة pointInPolygon. ويظل حد الحجم المُعدّ (إعداد الخادم point_in_polygon_cache_size) دون تغيير، لذلك تواصل ذاكرة التخزين المؤقت قبول الإدخالات بعد ذلك. ولتعطيل ذاكرة التخزين المؤقت بدلًا من ذلك، اضبط point_in_polygon_cache_size على 0.

يمسح ذاكرات التخزين المؤقت للرموز وترويسة الفهرس النصي وpostings.

إذا أردت مسح إحدى هذه الذاكرات المؤقتة بشكل منفصل، يمكنك تشغيل

• SYSTEM CLEAR TEXT INDEX TOKENS CACHE,
• SYSTEM CLEAR TEXT INDEX HEADER CACHE، أو
• SYSTEM CLEAR TEXT INDEX POSTINGS CACHE

يمسح ذاكرة التخزين المؤقت لعلامات الفهارس الثانوية (لتخطي البيانات).

يفرّغ ذاكرة التخزين المؤقت للكتل غير المضغوطة الخاصة بالفهارس الثانوية (لتخطي البيانات).

يمسح ذاكرة التخزين المؤقت للملفات المُعيَّنة في الذاكرة.

يمسح userspace page cache، وهي ذاكرة ClickHouse المؤقتة الخاصة داخل الذاكرة للبيانات المقروءة من طبقة التخزين الأساسية.

يمسح ذاكرة التخزين المؤقت الخاصة بفهرس تشابه المتجهات.

يمسح ذاكرة التخزين المؤقت لمجمّعات اتصالات HTTP المستخدمة في الاتصالات الصادرة.

يمسح ذاكرة التخزين المؤقت لعملاء S3.

يحمّل علامات الجدول إلى ذاكرة تخزين العلامات المؤقتة. كما تُحمَّل أيضًا علامات الفهرس الثانوية إلى ذاكرة التخزين المؤقت لعلامات الفهرس.

SYSTEM PREWARM MARK CACHE [ON CLUSTER cluster_name] [db.]table

يحمّل الفهارس الأساسية لجدول MergeTree إلى ذاكرة التخزين المؤقت للفهرس الأساسي.

SYSTEM PREWARM PRIMARY INDEX CACHE [ON CLUSTER cluster_name] [db.]table

يمسح ذاكرة التخزين المؤقت للبيانات الوصفية للقرص المحدد.

SYSTEM DROP DISK METADATA CACHE <disk_name>

يُطابِق الحالة الموجودة في الذاكرة لذاكرة التخزين المؤقت لنظام الملفات في ClickHouse مع ملفات ذاكرة التخزين المؤقت الموجودة فعليًا على القرص، ويُرجع cache_name وpath وsize المُنزَّل لكل جزء ملف مخزَّن مؤقتًا. ويمكن استخدام اسم ذاكرة تخزين مؤقت اختياري لقصر العملية على ذاكرة تخزين مؤقت واحدة.

SYSTEM SYNC FILESYSTEM CACHE ['<cache_name>']

يحذف ذاكرة التخزين المؤقت الموزعة. استخدم CONNECTIONS لحذف الاتصالات المخزنة مؤقتًا بخوادم ذاكرة التخزين المؤقت الموزعة فقط، أو مرّر معرّف خادم لاستهداف خادم واحد.

SYSTEM DROP DISTRIBUTED CACHE [CONNECTIONS | 'server_id']

يمكن حذف النسخ المتماثلة المعطّلة لجداول ReplicatedMergeTree باستخدام الصيغة التالية:

SYSTEM DROP REPLICA 'replica_name' FROM TABLE database.table;
SYSTEM DROP REPLICA 'replica_name' FROM DATABASE database;
SYSTEM DROP REPLICA 'replica_name';
SYSTEM DROP REPLICA 'replica_name' FROM ZKPATH '/path/to/table/in/zk';

ستزيل الاستعلامات مسار النسخة المتماثلة لـ ReplicatedMergeTree في ZooKeeper. ويكون ذلك مفيدًا عندما تكون النسخة المتماثلة متوقفة ولا يمكن إزالة بياناتها الوصفية من ZooKeeper باستخدام DROP TABLE لأنه لم يعد هناك مثل هذا الجدول. ولن يؤدي ذلك إلا إلى حذف النسخة المتماثلة غير النشطة/القديمة، ولا يمكنه حذف النسخة المتماثلة المحلية، لذا يُرجى استخدام DROP TABLE لهذا الغرض. ولا يقوم DROP REPLICA بحذف أي جداول، كما لا يزيل أي بيانات أو بيانات وصفية من القرص.

الأول يزيل البيانات الوصفية للنسخة المتماثلة 'replica_name' من الجدول database.table. والثاني يفعل الأمر نفسه لجميع الجداول المتماثلة في قاعدة البيانات. والثالث يفعل الأمر نفسه لجميع الجداول المتماثلة على الخادم المحلي. والرابع مفيد لإزالة البيانات الوصفية لنسخة متماثلة متوقفة عندما تكون جميع النسخ المتماثلة الأخرى للجدول قد حُذفت. ويتطلب تحديد مسار الجدول بشكل صريح. ويجب أن يكون هو نفسه المسار الذي مُرِّر إلى الوسيطة الأولى لمحرك ReplicatedMergeTree عند إنشاء الجدول.

يمكن حذف النسخ المتماثلة المعطّلة لقواعد بيانات Replicated باستخدام الصياغة التالية:

SYSTEM DROP DATABASE REPLICA 'replica_name' [FROM SHARD 'shard_name'] FROM DATABASE database;
SYSTEM DROP DATABASE REPLICA 'replica_name' [FROM SHARD 'shard_name'];
SYSTEM DROP DATABASE REPLICA 'replica_name' [FROM SHARD 'shard_name'] FROM ZKPATH '/path/to/table/in/zk';

مشابه لـ SYSTEM DROP REPLICA، لكنه يزيل مسار النسخة المتماثلة لقاعدة البيانات Replicated من ZooKeeper عندما لا تكون هناك قاعدة بيانات يمكن تنفيذ DROP DATABASE عليها. يُرجى ملاحظة أنه لا يزيل النسخ المتماثلة لـ ReplicatedMergeTree (لذا قد تحتاج أيضًا إلى SYSTEM DROP REPLICA). اسمَا الـ shard والنسخة المتماثلة هما الاسمان اللذان تم تحديدهما في وسائط المحرك Replicated عند إنشاء قاعدة البيانات. كذلك، يمكن الحصول على هذين الاسمين من العمودين database_shard_name وdatabase_replica_name في system.clusters. إذا كان بند FROM SHARD غير موجود، فيجب أن يكون replica_name اسم النسخة المتماثلة الكامل بالتنسيق shard_name|replica_name.

يمسح الذاكرة المؤقتة للبيانات غير المضغوطة. يُفعَّل أو يُعطَّل التخزين المؤقت للبيانات غير المضغوطة باستخدام الإعداد use_uncompressed_cache على مستوى الاستعلام/المستخدم/ملف التعريف. يمكن تهيئة حجمه باستخدام الإعداد uncompressed_cache_size على مستوى الخادم.

يمسح ذاكرة التخزين المؤقت للتعبيرات المترجمة. يمكن تمكين ذاكرة التخزين المؤقت للتعبيرات المترجمة أو تعطيلها عبر الإعداد compile_expressions على مستوى الاستعلام/المستخدم/ملف التعريف.

يمسح ذاكرة التخزين المؤقت لشرط الاستعلام.

يمسح ذاكرة التخزين المؤقت لرؤوس التشفير. تحتفظ هذه الذاكرة برؤوس التشفير المقروءة من بداية الملفات المشفّرة، ويستخدمها مسار القراءة التجريبي use_reader_executor لتجنّب إعادة قراءتها؛ ويُضبط حجمها من خلال إعداد الخادم encryption_header_cache_size.

SYSTEM CLEAR QUERY CACHE;
SYSTEM CLEAR QUERY CACHE TAG '<tag>'

يمسح ذاكرة التخزين المؤقت للاستعلام. إذا تم تحديد وسم، فلا تُحذف إلا عناصر ذاكرة التخزين المؤقت للاستعلام التي تحمل الوسم المحدد.

يمسح ذاكرة التخزين المؤقت للمخططات المحمّلة من format_schema_path.

الأهداف المدعومة:

• Protobuf: يزيل تعريفات رسائل Protobuf المستوردة من الذاكرة.
• Files: يحذف ملفات المخططات المخزّنة مؤقتًا والمحفوظة محليًا في format_schema_path، والتي تُنشأ عند تعيين format_schema_source إلى query. ملاحظة: إذا لم يتم تحديد أي هدف، فستُمسح كلتا الذاكرتين المؤقتتين.

SYSTEM CLEAR|DROP FORMAT SCHEMA CACHE [FOR Protobuf/Files]

يُفرِّغ رسائل السجل المخزّنة مؤقتًا إلى جداول النظام، مثل system.query_log. ويكون مفيدًا أساسًا لأغراض استكشاف الأخطاء وإصلاحها، لأن معظم جداول النظام لها فاصل تفريغ افتراضي قدره 7.5 ثانية. وسيؤدي هذا أيضًا إلى إنشاء جداول النظام حتى إذا كانت قائمة انتظار الرسائل فارغة.

SYSTEM FLUSH LOGS [ON CLUSTER cluster_name] [log_name|[database.table]] [, ...]

إذا كنت لا تريد تفريغ كل شيء، يمكنك تفريغ سجل واحد أو عدة سجلات بعينها بتمرير إما اسمها أو الجدول الهدف الخاص بها:

SYSTEM FLUSH LOGS query_log, system.query_views_log;

يعيد تحميل تهيئة ClickHouse. يُستخدم عندما تكون التهيئة مخزنة في ZooKeeper. لاحظ أن SYSTEM RELOAD CONFIG لا يعيد تحميل تهيئة USER المخزنة في ZooKeeper، وإنما يعيد تحميل تهيئة USER المخزنة في users.xml فقط. لإعادة تحميل جميع إعدادات USER، استخدم SYSTEM RELOAD USERS

SYSTEM RELOAD CONFIG [ON CLUSTER cluster_name]

يعيد تحميل جميع مخازن الوصول، بما في ذلك: users.xml، ومخزن الوصول المحلي على القرص، ومخزن الوصول المُكرَّر (في ZooKeeper).

SYSTEM RELOAD USERS [ON CLUSTER cluster_name]

يُغلق ClickHouse عادةً (مثل service clickhouse-server stop / kill {$pid_clickhouse-server})

ينهي عملية ClickHouse قسرًا (مثل kill -9 {$ pid_clickhouse-server})

يدير نقاط التتبّع باستخدام ميزة XRay من LLVM، وهي متاحة عندما يُبنى ClickHouse باستخدام ENABLE_XRAY=1. ويتيح ذلك تصحيح الأعطال وتحليل الأداء في بيئة الإنتاج من دون تعديل الشيفرة المصدرية وبأقل تكلفة إضافية ممكنة. وعند عدم إضافة أي نقطة تتبّع، تكون كلفة الأداء مهملة تقريبًا، لأنه لا يضيف سوى قفزة إضافية إلى عنوان قريب في بداية تلك الدوال ونهايتها التي يزيد طولها على 200 تعليمة.

يضيف نقطة تتبّع جديدة. يمكن فحص الدوال التي أُضيفت إليها تتبّع في جدول النظام system.instrumentation. ويمكن إضافة أكثر من handler واحد إلى الدالة نفسها، وسيُنفَّذ بالترتيب نفسه الذي أُضيفت به تتبّع. يمكن جلب الدوال المطلوب تتبّعها من جدول النظام system.symbols.

توجد ثلاثة أنواع مختلفة من handler يمكن إضافتها إلى الدوال:

Syntax

SYSTEM INSTRUMENT ADD FUNCTION HANDLER [ARGUMENTS]

حيث تكون FUNCTION أي دالة أو جزءًا فرعيًا من دالة، مثل QueryMetricLog::startQuery، ويكون المعالج أحد العناصر التالية

يطبع النص المُمرَّر كوسيطة وأثر المكدس عند ENTRY أو EXIT للدالة.

SYSTEM INSTRUMENT ADD 'QueryMetricLog::startQuery' LOG ENTRY 'this is a log printed at entry'
SYSTEM INSTRUMENT ADD 'QueryMetricLog::startQuery' LOG EXIT 'this is a log printed at exit'

يتوقف لمدة ثابتة من الثواني، سواء عند ENTRY أو EXIT:

SYSTEM INSTRUMENT ADD 'QueryMetricLog::startQuery' SLEEP ENTRY 0.5

أو لعدد عشوائي من الثواني بتوزيع منتظم، مع تحديد الحدين الأدنى والأقصى مفصولين بمسافة:

SYSTEM INSTRUMENT ADD 'QueryMetricLog::startQuery' SLEEP ENTRY 0 1

يقيس الوقت المستغرَق بين ENTRY وEXIT في الدالة. تُخزَّن نتيجة التنميط في system.trace_log، ويمكن تحويلها إلى تنسيق تتبّع أحداث Chrome.

SYSTEM INSTRUMENT ADD 'QueryMetricLog::startQuery' PROFILE

يزيل نقطة تتبّع واحدة بإحدى الطريقتين التاليتين:

SYSTEM INSTRUMENT REMOVE ID

كلّها باستخدام الكلمة المفتاحية ALL:

SYSTEM INSTRUMENT REMOVE ALL

مجموعة من المعرّفات الناتجة عن استعلام فرعي:

SYSTEM INSTRUMENT REMOVE (SELECT id FROM system.instrumentation WHERE handler = 'log')

أو جميع نقاط التتبّع التي تتطابق مع قيمة function_name معيّنة:

SYSTEM INSTRUMENT REMOVE 'QueryMetricLog::startQuery'

يمكن جمع معلومات نقطة التتبّع من جدول النظام system.instrumentation.

يمكن لـ ClickHouse إدارة جداول Distributed. عند إدراج مستخدمٍ بياناتٍ في هذه الجداول، ينشئ ClickHouse أولًا قائمة انتظار للبيانات المطلوب إرسالها إلى عُقد عنقود، ثم يرسلها بشكل غير متزامن. يمكنك إدارة معالجة قائمة الانتظار باستخدام الاستعلامات STOP DISTRIBUTED SENDS وFLUSH DISTRIBUTED وSTART DISTRIBUTED SENDS. ويمكنك أيضًا إدراج البيانات الموزعة بشكل متزامن باستخدام الإعداد distributed_foreground_insert.

يعطّل توزيع البيانات في الخلفية عند إدراج البيانات في الجداول الموزعة.

SYSTEM STOP DISTRIBUTED SENDS [db.]<distributed_table_name> [ON CLUSTER cluster_name]

يُجبر ClickHouse على إرسال البيانات إلى عُقد العنقود بشكل متزامن. وإذا كانت أي من العُقد غير متاحة، فإن ClickHouse يرفع استثناءً ويوقف تنفيذ الاستعلام. يمكنك إعادة محاولة الاستعلام حتى ينجح، وسيحدث ذلك عندما تعود جميع العُقد للعمل.

يمكنك أيضًا تجاوز بعض الإعدادات عبر العبارة SETTINGS، وقد يكون ذلك مفيدًا لتجاوز بعض القيود المؤقتة، مثل max_concurrent_queries_for_all_users أو max_memory_usage.

SYSTEM FLUSH DISTRIBUTED [db.]<distributed_table_name> [ON CLUSTER cluster_name] [SETTINGS ...]

يُفعِّل توزيع البيانات في الخلفية عند إدراج البيانات في الجداول الموزعة.

SYSTEM START DISTRIBUTED SENDS [db.]<distributed_table_name> [ON CLUSTER cluster_name]

يُغلق المقبس وينهي الاتصالات الحالية مع الخادم على المنفذ المحدد وباستخدام البروتوكول المحدد، وذلك بشكلٍ منظم.

ومع ذلك، إذا لم تكن إعدادات البروتوكول المقابلة محددة في إعداد clickhouse-server، فلن يكون لهذا الأمر أي تأثير.

SYSTEM STOP LISTEN [ON CLUSTER cluster_name] [QUERIES ALL | QUERIES DEFAULT | QUERIES CUSTOM | TCP | TCP WITH PROXY | TCP SECURE | HTTP | HTTPS | MYSQL | GRPC | POSTGRESQL | PROMETHEUS | CUSTOM 'protocol']

• إذا جرى تحديد المُعدِّل CUSTOM 'protocol'، فسيتم إيقاف البروتوكول المخصّص الذي يحمل الاسم المحدد، والمُعرَّف في قسم البروتوكولات ضمن إعدادات الخادم.
• إذا جرى تحديد المُعدِّل QUERIES ALL [EXCEPT .. [,..]]، فسيتم إيقاف جميع البروتوكولات، ما لم يُنص على خلاف ذلك باستخدام العبارة EXCEPT.
• إذا جرى تحديد المُعدِّل QUERIES DEFAULT [EXCEPT .. [,..]]، فسيتم إيقاف جميع البروتوكولات الافتراضية، ما لم يُنص على خلاف ذلك باستخدام العبارة EXCEPT.
• إذا جرى تحديد المُعدِّل QUERIES CUSTOM [EXCEPT .. [,..]]، فسيتم إيقاف جميع البروتوكولات المخصّصة، ما لم يُنص على خلاف ذلك باستخدام العبارة EXCEPT.

يسمح بإنشاء اتصالات جديدة عبر البروتوكولات المحددة.

ومع ذلك، إذا لم يكن الخادم على المنفذ والبروتوكول المحددين قد أُوقِف باستخدام الأمر SYSTEM STOP LISTEN، فلن يكون لهذا الأمر أي تأثير.

SYSTEM START LISTEN [ON CLUSTER cluster_name] [QUERIES ALL | QUERIES DEFAULT | QUERIES CUSTOM | TCP | TCP WITH PROXY | TCP SECURE | HTTP | HTTPS | MYSQL | GRPC | POSTGRESQL | PROMETHEUS | CUSTOM 'protocol']

يمكن لـ ClickHouse إدارة العمليات التي تُنفَّذ في الخلفية في جداول MergeTree.

يتيح إيقاف عمليات الدمج في الخلفية للجداول من عائلة MergeTree:

SYSTEM STOP MERGES [ON CLUSTER cluster_name] [ON VOLUME <volume_name> | [db.]merge_tree_family_table_name]

يتيح بدء عمليات الدمج في الخلفية لجداول عائلة MergeTree:

SYSTEM START MERGES [ON CLUSTER cluster_name] [ON VOLUME <volume_name> | [db.]merge_tree_family_table_name]

يوفّر إمكانية إيقاف الحذف التلقائي للبيانات القديمة في الخلفية وفقًا لـ تعبير TTL للجداول ضمن عائلة MergeTree: يُرجع Ok. حتى إذا لم يكن الجدول موجودًا أو لم يكن يستخدم محرك MergeTree. ويُرجع خطأ إذا كانت قاعدة البيانات غير موجودة:

SYSTEM STOP TTL MERGES [ON CLUSTER cluster_name] [[db.]merge_tree_family_table_name]

يوفّر إمكانية بدء عمليات الدمج في الخلفية لحذف البيانات القديمة وفقًا لـ تعبير TTL للجداول في عائلة MergeTree: يعيد Ok. حتى إذا لم يكن الجدول موجودًا. ويعيد خطأً إذا لم تكن قاعدة البيانات موجودة:

SYSTEM START TTL MERGES [ON CLUSTER cluster_name] [[db.]merge_tree_family_table_name]

يوفّر إمكانية إيقاف عمليات نقل البيانات في الخلفية وفقًا لـ تعبير TTL للجدول مع العبارة TO VOLUME أو TO DISK للجداول في عائلة MergeTree: يعيد Ok. حتى إذا لم يكن الجدول موجودًا. ويعيد خطأً عندما لا تكون قاعدة البيانات موجودة:

SYSTEM STOP MOVES [ON CLUSTER cluster_name] [[db.]merge_tree_family_table_name]

يوفّر إمكانية بدء عمليات نقل البيانات في الخلفية وفقًا لـ تعبير TTL للجدول مع عبارتي TO VOLUME وTO DISK للجداول في عائلة MergeTree: يُرجع Ok. حتى إذا لم يكن الجدول موجودًا. ويُرجع خطأً عندما لا تكون قاعدة البيانات موجودة:

SYSTEM START MOVES [ON CLUSTER cluster_name] [[db.]merge_tree_family_table_name]

يحذف نسخة احتياطية مجمّدة بالاسم المحدد من جميع الأقراص. لمعرفة المزيد عن إلغاء تجميد الأجزاء بشكل منفصل، راجع ALTER TABLE table_name UNFREEZE WITH NAME

SYSTEM UNFREEZE WITH NAME <backup_name>

انتظر حتى يكتمل تحميل جميع أجزاء بيانات الجدول التي تُحمَّل بشكل غير متزامن (أجزاء البيانات القديمة).

SYSTEM WAIT LOADING PARTS [ON CLUSTER cluster_name] [db.]merge_tree_family_table_name

يمكن لـ ClickHouse إدارة عمليات النسخ المتماثل ذات الصلة التي تعمل في الخلفية في جداول ReplicatedMergeTree.

يوفّر إمكانية إيقاف عمليات الجلب في الخلفية للأجزاء المُدرجة للجداول ضمن عائلة ReplicatedMergeTree: يُرجِع دائمًا Ok. بغضّ النظر عن محرك الجدول، وحتى إذا لم يكن الجدول أو قاعدة البيانات موجودَين.

SYSTEM STOP FETCHES [ON CLUSTER cluster_name] [[db.]replicated_merge_tree_family_table_name]

يوفّر إمكانية بدء عمليات الجلب في الخلفية للأجزاء المُدخلة للجداول ضمن عائلة ReplicatedMergeTree: ويُرجع دائمًا Ok. بغضّ النظر عن محرك الجدول، وحتى إذا لم يكن الجدول أو قاعدة البيانات موجودًا.

SYSTEM START FETCHES [ON CLUSTER cluster_name] [[db.]replicated_merge_tree_family_table_name]

يتيح إيقاف عمليات الإرسال في الخلفية إلى النسخ المتماثلة الأخرى في العنقود للأجزاء الجديدة المُدرجة في جداول عائلة ReplicatedMergeTree:

SYSTEM STOP REPLICATED SENDS [ON CLUSTER cluster_name] [[db.]replicated_merge_tree_family_table_name]

يتيح بدء عمليات الإرسال الخلفية إلى النُسخ المتماثلة الأخرى في العنقود للأجزاء الجديدة المُدرجة في الجداول ضمن عائلة ReplicatedMergeTree:

SYSTEM START REPLICATED SENDS [ON CLUSTER cluster_name] [[db.]replicated_merge_tree_family_table_name]

يتيح إيقاف مهام الجلب الخلفية من قوائم انتظار النسخ المتماثل المخزّنة في ZooKeeper للجداول ضمن عائلة ReplicatedMergeTree. أنواع مهام الخلفية الممكنة هي - عمليات الدمج، وعمليات الجلب، وعمليات mutation، وعبارات DDL التي تتضمن عبارة ON CLUSTER:

SYSTEM STOP REPLICATION QUEUES [ON CLUSTER cluster_name] [[db.]replicated_merge_tree_family_table_name]

يتيح بدء مهام الجلب الخلفية من قوائم انتظار النسخ المتماثل المخزّنة في ZooKeeper للجداول من عائلة ReplicatedMergeTree. أنواع المهام الخلفية الممكنة: عمليات الدمج، وعمليات الجلب، وعمليات التعديل، وعبارات DDL مع البند ON CLUSTER:

SYSTEM START REPLICATION QUEUES [ON CLUSTER cluster_name] [[db.]replicated_merge_tree_family_table_name]

يوقف تحميل الإدخالات الجديدة من سجل النسخ المتماثل إلى قائمة انتظار النسخ المتماثل في جدول ReplicatedMergeTree.

SYSTEM STOP PULLING REPLICATION LOG [ON CLUSTER cluster_name] [[db.]replicated_merge_tree_family_table_name]

يلغي الأمر SYSTEM STOP PULLING REPLICATION LOG.

SYSTEM START PULLING REPLICATION LOG [ON CLUSTER cluster_name] [[db.]replicated_merge_tree_family_table_name]

انتظر حتى تتم مزامنة جدول ReplicatedMergeTree مع النسخ المتماثلة الأخرى في العنقود، على ألا تتجاوز مدة الانتظار receive_timeout ثانية.

SYSTEM SYNC REPLICA [ON CLUSTER cluster_name] [db.]replicated_merge_tree_family_table_name [IF EXISTS] [STRICT | LIGHTWEIGHT [FROM 'srcReplica1'[, 'srcReplica2'[, ...]]] | PULL]

بعد تشغيل هذه التعليمة، يجلب [db.]replicated_merge_tree_family_table_name الأوامر من السجل المشترك للنسخ المتماثل إلى قائمة انتظار النسخ المتماثل الخاصة به، ثم ينتظر الاستعلام حتى تعالج النسخة المتماثلة جميع الأوامر التي تم جلبها. المعدِّلات التالية مدعومة:

• مع IF EXISTS (متاح منذ 25.6)، لن يُرجع الاستعلام خطأً إذا لم يكن الجدول موجودًا. يفيد ذلك عند إضافة نسخة متماثلة جديدة إلى عنقود، عندما تكون بالفعل جزءًا من تهيئة العنقود لكنها لا تزال في طور إنشاء الجدول ومزامنته.
• إذا جرى تحديد المعدِّل STRICT، فإن الاستعلام ينتظر حتى تصبح قائمة انتظار النسخ المتماثل فارغة. وقد لا ينجح STRICT أبدًا إذا كانت إدخالات جديدة تظهر باستمرار في قائمة انتظار النسخ المتماثل.
• إذا جرى تحديد المعدِّل LIGHTWEIGHT، فإن الاستعلام ينتظر فقط حتى تتم معالجة إدخالات GET_PART وATTACH_PART وDROP_RANGE وREPLACE_RANGE وDROP_PART. بالإضافة إلى ذلك، يدعم المعدِّل LIGHTWEIGHT عبارة FROM 'srcReplicas' اختيارية، حيث إن 'srcReplicas' هي قائمة مفصولة بفواصل تضم أسماء النسخ المتماثلة المصدر. يتيح هذا الامتداد مزامنة أكثر استهدافًا من خلال التركيز فقط على مهام النسخ المتماثل القادمة من النسخ المتماثلة المصدر المحددة.
• إذا جرى تحديد المعدِّل PULL، فإن الاستعلام يسحب إدخالات جديدة إلى قائمة انتظار النسخ المتماثل من ZooKeeper، لكنه لا ينتظر معالجة أي شيء.

ينتظر إلى أن تطبّق قاعدة البيانات المكرّرة المحددة جميع تغييرات المخطط من قائمة انتظار DDL الخاصة بتلك القاعدة.

الصياغة

SYSTEM SYNC DATABASE REPLICA replicated_database_name;

يوفّر هذا الأمر إمكانية إعادة تهيئة حالة جلسة ZooKeeper لجدول ReplicatedMergeTree، إذ يقارن الحالة الحالية مع ZooKeeper باعتباره المصدر المرجعي المعتمد، ويضيف مهام إلى قائمة انتظار ZooKeeper عند الحاجة. تتم تهيئة قائمة انتظار النسخ المتماثل استنادًا إلى بيانات ZooKeeper بالطريقة نفسها المتبعة في تعليمة ATTACH TABLE. وخلال فترة قصيرة، لن يكون الجدول متاحًا لإجراء أي عمليات.

SYSTEM RESTART REPLICA [ON CLUSTER cluster_name] [db.]replicated_merge_tree_family_table_name

يستعيد نسخة متماثلة إذا كانت البيانات موجودة [على الأرجح] لكن بيانات ZooKeeper الوصفية مفقودة.

يعمل فقط على جداول ReplicatedMergeTree في وضع readonly.

يمكن تنفيذ الاستعلام بعد:

• فقدان جذر ZooKeeper /.
• فقدان مسار النسخ المتماثلة /replicas.
• فقدان مسار نسخة متماثلة فردية /replicas/replica_name/.

تُرفِق النسخة المتماثلة الأجزاء التي عُثر عليها محليًا وترسل معلومات عنها إلى ZooKeeper. ولا تُجلَب الأجزاء الموجودة على النسخة المتماثلة قبل فقدان البيانات الوصفية مجددًا من النسخ الأخرى ما لم تكن قديمة (لذا فإن استعادة النسخة المتماثلة لا تعني إعادة تنزيل جميع البيانات عبر الشبكة).

يستعيد نسخة متماثلة إذا كانت البيانات موجودة [من المحتمل] لكن البيانات الوصفية في ZooKeeper مفقودة.

الصياغة

SYSTEM RESTORE DATABASE REPLICA repl_db [ON CLUSTER cluster]

مثال

CREATE DATABASE repl_db
ENGINE=Replicated("/clickhouse/repl_db", shard1, replica1);

CREATE TABLE repl_db.test_table (n UInt32)
ENGINE = ReplicatedMergeTree
ORDER BY n PARTITION BY n % 10;

-- zookeeper_delete_path("/clickhouse/repl_db", recursive=True) <- root loss.

SYSTEM RESTORE DATABASE REPLICA repl_db;

الصياغة

SYSTEM RESTORE REPLICA [db.]replicated_merge_tree_family_table_name [ON CLUSTER cluster_name]

الصيغة البديلة:

SYSTEM RESTORE REPLICA [ON CLUSTER cluster_name] [db.]replicated_merge_tree_family_table_name

مثال

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

CREATE TABLE test(n UInt32)
ENGINE = ReplicatedMergeTree('/clickhouse/tables/test/', '{replica}')
ORDER BY n PARTITION BY n % 10;

INSERT INTO test SELECT * FROM numbers(1000);

-- zookeeper_delete_path("/clickhouse/tables/test", recursive=True) <- root loss.

SYSTEM RESTART REPLICA test;
SYSTEM RESTORE REPLICA test;

طريقة أخرى:

SYSTEM RESTORE REPLICA test ON CLUSTER cluster;

يوفّر إمكانية إعادة تهيئة حالة جلسات ZooKeeper لجميع جداول ReplicatedMergeTree، ويقارن الحالة الحالية مع ZooKeeper بوصفه المصدر المرجعي الصحيح، ويضيف مهام إلى قائمة الانتظار في ZooKeeper إذا لزم الأمر

يسمح بمسح ذاكرة التخزين المؤقت لنظام الملفات.

SYSTEM CLEAR FILESYSTEM CACHE [ON CLUSTER cluster_name]

سينفّذ نداء النظام sync.

SYSTEM SYNC FILE CACHE [ON CLUSTER cluster_name]

حمّل المفاتيح الأساسية للجدول المعني أو لجميع الجداول.

SYSTEM LOAD PRIMARY KEY [db.]name

SYSTEM LOAD PRIMARY KEY

يؤدي هذا الأمر إلى إلغاء تحميل المفاتيح الأساسية للجدول المحدد أو لجميع الجداول.

SYSTEM UNLOAD PRIMARY KEY [db.]name

SYSTEM UNLOAD PRIMARY KEY

أوامر للتحكم في المهام التي تُنفَّذ في الخلفية بواسطة Refreshable Materialized Views

راقب system.view_refreshes عند استخدامها.

عطّل التحديث الدوري للعرض المحدد أو لجميع العروض القابلة للتحديث. وإذا كان هناك تحديث جارٍ، فألغِه أيضًا.

إذا كان العرض ضمن قاعدة بيانات Replicated أو Shared، فإن STOP VIEW يؤثر فقط في النسخة المتماثلة الحالية، بينما يؤثر STOP REPLICATED VIEW في جميع النسخ المتماثلة.

SYSTEM STOP VIEW [db.]name

SYSTEM STOP VIEWS

فعِّل التحديث الدوري للعرض المحدد أو لجميع العروض القابلة للتحديث. ولا يؤدي ذلك إلى تشغيل تحديث فوري.

إذا كان العرض موجودًا في قاعدة بيانات Replicated أو Shared، فإن START VIEW يلغي أثر STOP VIEW، وSTART REPLICATED VIEW يلغي أثر STOP REPLICATED VIEW. كما يلغي START VIEW أثر PAUSE VIEW.

SYSTEM START VIEW [db.]name

SYSTEM START VIEWS

عطّل التحديث الدوري للعرض المحدد أو لجميع العروض القابلة للتحديث. وعلى خلاف SYSTEM STOP VIEW، فإن SYSTEM PAUSE VIEW لا يوقف تحديثًا قيد التنفيذ بالفعل: يُسمح للتحديث الجاري بأن يكتمل، ولا تُمنع إلا التحديثات اللاحقة.

يمكن التراجع عن ذلك باستخدام SYSTEM START VIEW أو SYSTEM START VIEWS.

SYSTEM PAUSE VIEW [db.]name

SYSTEM PAUSE VIEWS

نفّذ تحديثًا فوريًا خارج الجدولة لعرضٍ معيّن.

SYSTEM REFRESH VIEW [db.]name

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

يمكن استخدامه مباشرةً بعد إنشاء refreshable materialized view جديد (من دون الكلمة المفتاحية EMPTY) لانتظار اكتمال التحديث الأولي.

إذا كان العرض موجودًا في قاعدة بيانات Replicated أو Shared database، وكانت عملية التحديث جارية على نسخة متماثلة أخرى، فإنه ينتظر اكتمال ذلك التحديث.

SYSTEM WAIT VIEW [db.]name

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

SYSTEM CANCEL VIEW [db.]name

أوامر مستقلة عن المحرك للتحكم في النشاط في الخلفية لجدول واحد، أو لجميع هذه الجداول على الخادم دفعةً واحدة. وتشمل:

• العروض المادية القابلة للتحديث (التحديث الدوري)، و
• محركات الجداول المتدفقة التي تستهلك باستمرار من مصدر خارجي: Kafka، وRabbitMQ، وNATS، وS3Queue، وAzureQueue.

بالنسبة إلى العرض المادي القابل للتحديث، يكون كل فعل اسمًا مستعارًا لأمر SYSTEM ... VIEW المقابل من إدارة العروض المادية القابلة للتحديث، لذا يتصرف SYSTEM STOP [db.]name تمامًا مثل SYSTEM STOP VIEW [db.]name، وهكذا.

تختلف صيغ الجدول الواحد وصيغ البدل في كيفية تعاملها مع الجداول التي لا يوجد لها نشاط في الخلفية. تُصدر صيغة الجدول الواحد (SYSTEM STOP [db.]table) خطأً إذا لم يكن الجدول المحدد محركًا متدفقًا ولا عرضًا ماديًا قابلًا للتحديث. أما صيغة البدل فتتخطى هذه الجداول بصمت، لذا يكون تشغيلها آمنًا دائمًا.

يوقف STOP وCANCEL الاستهلاك في أقرب وقت ممكن. بالنسبة إلى Kafka، وRabbitMQ، وNATS، فإنهما يوقفان القراءة من المصدر، لكنهما لا يقاطعان عملية insert بدأت بالفعل: إذ تكتمل الكتلة التي بدأت كتابتها في العروض المادية وتُثبّت. يقرأ S3Queue وAzureQueue البيانات ويُدرجانها ضمن خط معالجة واحد. عند تمكين إزالة التكرار (وهو الإعداد الافتراضي)، تُلغى عملية insert أيضًا وتُعاد معالجة الملفات لاحقًا. وعند تعطيل إزالة التكرار، تكتمل الدفعة قيد التنفيذ وتُثبّت بدلًا من ذلك (كما في المحركات المذكورة أعلاه) لتجنب تكرار الصفوف. تُستهلك البيانات التي قُرئت ولم تُثبّت بعد مجددًا لاحقًا، لذلك لا يُفقد شيء، باستثناء NATS الأساسي (من دون JetStream)، إذ لا يمكنه إعادة تسليمها ويتخلص منها.

لا يقاطع PAUSE عملية insert قيد التنفيذ، لذا لا يؤدي عادةً إلى فقدان أي بيانات. ويُعد NATS الأساسي الاستثناء: إذ يؤدي الإيقاف المؤقت إلى إيقاف الاستهلاك والتخلص من الرسائل التي تلقاها بالفعل ولم يُدرجها بعد، ولا يستطيع NATS الأساسي إعادة تسليمها.

أوقف النشاطات التي تعمل في الخلفية وأبقِها متوقفة: أوقف ما يعمل حاليًا، ولا تشغّل أي شيء آخر حتى SYSTEM START. وهو مكافئ لـ PAUSE + CANCEL.

SYSTEM STOP [db.]table
SYSTEM STOP ALL BACKGROUND

يستأنف النشاط بعد SYSTEM STOP أو SYSTEM PAUSE سابق. لا يؤدي ذلك إلى مقاطعة أي نشاط.

SYSTEM START [db.]table
SYSTEM START ALL BACKGROUND

أوقف أي نشاط في الخلفية، مع السماح للعمليات الجارية حاليًا بالانتهاء أولًا.

SYSTEM PAUSE [db.]table
SYSTEM PAUSE ALL BACKGROUND

يوقف النشاط الجاري حاليًا فقط، دون منع الأنشطة المستقبلية — يواصل الجدول التحديث أو الاستهلاك وفق جدوله الزمني. لا يفعل شيئًا إذا لم يكن هناك نشاط قيد التنفيذ.

SYSTEM CANCEL [db.]table
SYSTEM CANCEL ALL BACKGROUND

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

SYSTEM REFRESH [db.]table
SYSTEM REFRESH ALL BACKGROUND

يتطلب كل أمر امتياز المحرك المستهدف: SYSTEM VIEWS للعرض المادي القابل للتحديث، وSYSTEM STREAMING ENGINES للجدول المتدفق. وكلاهما يندرج ضمن SYSTEM BACKGROUND، لذا يتيح منح SYSTEM BACKGROUND التحكم في النشاط في الخلفية لجميع هذه الجداول. ولا تنطبق صيغ ALL BACKGROUND إلا على الجداول التي يملك المستخدم صلاحية التحكم فيها، وتتجاوز البقية بصمت.

ينتظر إلى أن تتم معالجة الملف المحدد أو أن يفشل نهائيًا ضمن جدول S3Queue أو AzureQueue المحدد. ويعود فورًا إذا كان الملف قد تمت معالجته بالفعل. ويُصدر خطأ إذا كان الملف قد فشل نهائيًا (بعد استنفاد جميع إعادة المحاولة).

SYSTEM FLUSH OBJECT STORAGE QUEUE [db.]table_name PATH 'path'