SYSTEM RELOAD EMBEDDED DICTIONARIES
أعِد تحميل جميع القواميس الداخلية. تكون القواميس الداخلية معطّلة افتراضيًا. يعيد دائمًاOk. بغضّ النظر عن نتيجة تحديث القواميس الداخلية.
SYSTEM RELOAD DICTIONARIES
يعيد الاستعلامSYSTEM RELOAD DICTIONARIES تحميل القواميس التي تكون حالتها LOADED (راجع العمود status في system.dictionaries)، أي القواميس التي سبق تحميلها بنجاح.
تُحمَّل القواميس افتراضيًا بأسلوب التحميل عند الطلب (راجع dictionaries_lazy_load)، لذلك بدلًا من تحميلها تلقائيًا عند بدء التشغيل، تُهيَّأ عند أول وصول إليها باستخدام الدالة dictGet أو بتنفيذ SELECT على الجداول التي تستخدم ENGINE = Dictionary.
الصياغة
SYSTEM RELOAD DICTIONARY
يعيد تحميل القاموسdictionary_name بالكامل، بغضّ النظر عن حالته (LOADED / NOT_LOADED / FAILED).
ويُرجع دائمًا Ok. بصرف النظر عن نتيجة تحديث القاموس.
system.dictionaries.
SYSTEM UNLOAD DICTIONARY
يفرّغ القاموسdictionary_name لتحرير الذاكرة التي يستخدمها إذا كانت حالة القاموس هي LOADED.
ويُعاد تحميل القاموس تلقائيًا عند الحاجة إليه مجددًا.
system.dictionaries.
SYSTEM UNLOAD DICTIONARIES
يفرّغ الاستعلامSYSTEM UNLOAD DICTIONARIES جميع القواميس التي تكون حالتها LOADED (راجع العمود status في system.dictionaries)، أي القواميس التي سبق تحميلها بنجاح.
SYSTEM RELOAD FUNCTIONS
يعيد تحميل جميع الدوال المعرفة من قبل المستخدم القابلة للتنفيذ المسجَّلة، أو إحداها، من ملف التهيئة. الصياغةSYSTEM RELOAD ASYNCHRONOUS METRICS
يعيد حساب جميع المقاييس غير المتزامنة. ونظرًا إلى أن المقاييس غير المتزامنة تُحدَّث دوريًا استنادًا إلى الإعداد asynchronous_metrics_update_period_s، فلا تكون هناك حاجة عادةً إلى تحديثها يدويًا باستخدام هذه العبارة.SYSTEM CLEAR|DROP DNS CACHE
يمسح ذاكرة التخزين المؤقت الداخلية لـ DNS في ClickHouse. وأحيانًا (في الإصدارات القديمة من ClickHouse) يكون من الضروري استخدام هذا الأمر عند تغيير البنية التحتية (مثل تغيير عنوان IP لخادم ClickHouse آخر أو للخادم الذي تستخدمه القواميس). للحصول على إدارة أكثر سهولة (وتلقائية) لذاكرة التخزين المؤقت، راجع المعلماتdisable_internal_dns_cache وdns_cache_max_entries وdns_cache_update_period.
SYSTEM CLEAR|DROP MARK CACHE
يمسح ذاكرة تخزين العلامات المؤقتة.SYSTEM CLEAR|DROP PRIMARY INDEX CACHE
يمسح ذاكرة التخزين المؤقت للفهرس الأساسي، التي تحتفظ بالمفاتيح الأساسية لجداولMergeTree في الذاكرة.
يُضبط حجمها باستخدام الإعداد primary_index_cache_size على مستوى الخادم.
SYSTEM CLEAR|DROP ICEBERG METADATA CACHE
يمسح ذاكرة التخزين المؤقت للبيانات الوصفية الخاصة بـ Iceberg.SYSTEM CLEAR|DROP AVRO SCHEMA CACHE
يمسح ذواكر التخزين المؤقت لكل عنوان URL في Confluent Schema Registry والمستخدمة بواسطة التنسيقAvroConfluent. تُسقِط هذه العملية كلاً من ذاكرة التخزين المؤقت لجلب المخططات (id → schema) وذاكرة التخزين المؤقت لتسجيل المخططات (subject + schema → id)، لذا ستعود عمليات القراءة والكتابة اللاحقة إلى خادم السجل. ويكون ذلك مفيدًا عندما يكون مخطط قد حُذف أو أُعيدت كتابته على جانب السجل، أو للتحقق من خاصية idempotency الخاصة بالسجل في الاختبارات.
SYSTEM DROP PARQUET METADATA CACHE
يمسح ذاكرة التخزين المؤقت للبيانات الوصفية لملفات Parquet.SYSTEM CLEAR|DROP PAIMON METADATA CACHE
يمسح ذاكرة التخزين المؤقت الموجودة في الذاكرة لملفات البيانات الوصفية المحلَّلة الخاصة بـ Paimon (manifest lists وmanifests).SYSTEM CLEAR|DROP POINT IN POLYGON CACHE
يمسح ذاكرة التخزين المؤقت للمضلعات الثابتة المُعالجة مسبقًا والمستخدمة من قِبل الدالةpointInPolygon. ويظل حد الحجم المُعدّ (إعداد الخادم point_in_polygon_cache_size) دون تغيير، لذلك تواصل ذاكرة التخزين المؤقت قبول الإدخالات بعد ذلك. ولتعطيل ذاكرة التخزين المؤقت بدلًا من ذلك، اضبط point_in_polygon_cache_size على 0.
SYSTEM CLEAR|DROP TEXT INDEX CACHES
يمسح ذاكرات التخزين المؤقت للرموز وترويسة الفهرس النصي وpostings. إذا أردت مسح إحدى هذه الذاكرات المؤقتة بشكل منفصل، يمكنك تشغيلSYSTEM CLEAR TEXT INDEX TOKENS CACHE,SYSTEM CLEAR TEXT INDEX HEADER CACHE، أوSYSTEM CLEAR TEXT INDEX POSTINGS CACHE
SYSTEM CLEAR|DROP INDEX MARK CACHE
يمسح ذاكرة التخزين المؤقت لعلامات الفهارس الثانوية (لتخطي البيانات).SYSTEM CLEAR|DROP INDEX UNCOMPRESSED CACHE
يفرّغ ذاكرة التخزين المؤقت للكتل غير المضغوطة الخاصة بالفهارس الثانوية (لتخطي البيانات).SYSTEM CLEAR|DROP MMAP CACHE
يمسح ذاكرة التخزين المؤقت للملفات المُعيَّنة في الذاكرة.SYSTEM CLEAR|DROP PAGE CACHE
يمسح userspace page cache، وهي ذاكرة ClickHouse المؤقتة الخاصة داخل الذاكرة للبيانات المقروءة من طبقة التخزين الأساسية.SYSTEM CLEAR|DROP VECTOR SIMILARITY INDEX CACHE
يمسح ذاكرة التخزين المؤقت الخاصة بفهرس تشابه المتجهات.SYSTEM CLEAR|DROP CONNECTIONS CACHE
يمسح ذاكرة التخزين المؤقت لمجمّعات اتصالات HTTP المستخدمة في الاتصالات الصادرة.SYSTEM CLEAR|DROP S3 CLIENT CACHE
يمسح ذاكرة التخزين المؤقت لعملاء S3.SYSTEM PREWARM MARK CACHE
يحمّل علامات الجدول إلى ذاكرة تخزين العلامات المؤقتة. كما تُحمَّل أيضًا علامات الفهرس الثانوية إلى ذاكرة التخزين المؤقت لعلامات الفهرس.SYSTEM PREWARM PRIMARY INDEX CACHE
يحمّل الفهارس الأساسية لجدولMergeTree إلى ذاكرة التخزين المؤقت للفهرس الأساسي.
SYSTEM CLEAR|DROP DISK METADATA CACHE
يمسح ذاكرة التخزين المؤقت للبيانات الوصفية للقرص المحدد.SYSTEM SYNC FILESYSTEM CACHE
يُطابِق الحالة الموجودة في الذاكرة لذاكرة التخزين المؤقت لنظام الملفات في ClickHouse مع ملفات ذاكرة التخزين المؤقت الموجودة فعليًا على القرص، ويُرجعcache_name وpath وsize المُنزَّل لكل جزء ملف مخزَّن مؤقتًا. ويمكن استخدام اسم ذاكرة تخزين مؤقت اختياري لقصر العملية على ذاكرة تخزين مؤقت واحدة.
SYSTEM CLEAR|DROP DISTRIBUTED CACHE
يتوفر
SYSTEM CLEAR|DROP DISTRIBUTED CACHE فقط في ClickHouse Cloud.CONNECTIONS لحذف الاتصالات المخزنة مؤقتًا بخوادم ذاكرة التخزين المؤقت الموزعة فقط، أو مرّر معرّف خادم لاستهداف خادم واحد.
SYSTEM DROP REPLICA
يمكن حذف النسخ المتماثلة المعطّلة لجداولReplicatedMergeTree باستخدام الصيغة التالية:
ReplicatedMergeTree في ZooKeeper. ويكون ذلك مفيدًا عندما تكون النسخة المتماثلة متوقفة ولا يمكن إزالة بياناتها الوصفية من ZooKeeper باستخدام DROP TABLE لأنه لم يعد هناك مثل هذا الجدول. ولن يؤدي ذلك إلا إلى حذف النسخة المتماثلة غير النشطة/القديمة، ولا يمكنه حذف النسخة المتماثلة المحلية، لذا يُرجى استخدام DROP TABLE لهذا الغرض. ولا يقوم DROP REPLICA بحذف أي جداول، كما لا يزيل أي بيانات أو بيانات وصفية من القرص.
الأول يزيل البيانات الوصفية للنسخة المتماثلة 'replica_name' من الجدول database.table.
والثاني يفعل الأمر نفسه لجميع الجداول المتماثلة في قاعدة البيانات.
والثالث يفعل الأمر نفسه لجميع الجداول المتماثلة على الخادم المحلي.
والرابع مفيد لإزالة البيانات الوصفية لنسخة متماثلة متوقفة عندما تكون جميع النسخ المتماثلة الأخرى للجدول قد حُذفت. ويتطلب تحديد مسار الجدول بشكل صريح. ويجب أن يكون هو نفسه المسار الذي مُرِّر إلى الوسيطة الأولى لمحرك ReplicatedMergeTree عند إنشاء الجدول.
SYSTEM DROP DATABASE REPLICA
يمكن حذف النسخ المتماثلة المعطّلة لقواعد بياناتReplicated باستخدام الصياغة التالية:
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.
SYSTEM CLEAR|DROP UNCOMPRESSED CACHE
يمسح الذاكرة المؤقتة للبيانات غير المضغوطة. يُفعَّل أو يُعطَّل التخزين المؤقت للبيانات غير المضغوطة باستخدام الإعدادuse_uncompressed_cache على مستوى الاستعلام/المستخدم/ملف التعريف.
يمكن تهيئة حجمه باستخدام الإعداد uncompressed_cache_size على مستوى الخادم.
SYSTEM CLEAR|DROP COMPILED EXPRESSION CACHE
يمسح ذاكرة التخزين المؤقت للتعبيرات المترجمة. يمكن تمكين ذاكرة التخزين المؤقت للتعبيرات المترجمة أو تعطيلها عبر الإعدادcompile_expressions على مستوى الاستعلام/المستخدم/ملف التعريف.
SYSTEM CLEAR|DROP QUERY CONDITION CACHE
يمسح ذاكرة التخزين المؤقت لشرط الاستعلام.SYSTEM CLEAR|DROP ENCRYPTION HEADERS CACHE
يمسح ذاكرة التخزين المؤقت لرؤوس التشفير. تحتفظ هذه الذاكرة برؤوس التشفير المقروءة من بداية الملفات المشفّرة، ويستخدمها مسار القراءة التجريبيuse_reader_executor لتجنّب إعادة قراءتها؛ ويُضبط حجمها من خلال إعداد الخادم encryption_header_cache_size.
SYSTEM CLEAR|DROP QUERY CACHE
SYSTEM CLEAR|DROP FORMAT SCHEMA CACHE
يمسح ذاكرة التخزين المؤقت للمخططات المحمّلة منformat_schema_path.
الأهداف المدعومة:
- Protobuf: يزيل تعريفات رسائل Protobuf المستوردة من الذاكرة.
- Files: يحذف ملفات المخططات المخزّنة مؤقتًا والمحفوظة محليًا في
format_schema_path، والتي تُنشأ عند تعيينformat_schema_sourceإلىquery. ملاحظة: إذا لم يتم تحديد أي هدف، فستُمسح كلتا الذاكرتين المؤقتتين.
SYSTEM FLUSH LOGS
يُفرِّغ رسائل السجل المخزّنة مؤقتًا إلى جداول النظام، مثل system.query_log. ويكون مفيدًا أساسًا لأغراض استكشاف الأخطاء وإصلاحها، لأن معظم جداول النظام لها فاصل تفريغ افتراضي قدره 7.5 ثانية. وسيؤدي هذا أيضًا إلى إنشاء جداول النظام حتى إذا كانت قائمة انتظار الرسائل فارغة.SYSTEM RELOAD CONFIG
يعيد تحميل تهيئة ClickHouse. يُستخدم عندما تكون التهيئة مخزنة في ZooKeeper. لاحظ أنSYSTEM RELOAD CONFIG لا يعيد تحميل تهيئة USER المخزنة في ZooKeeper، وإنما يعيد تحميل تهيئة USER المخزنة في users.xml فقط. لإعادة تحميل جميع إعدادات USER، استخدم SYSTEM RELOAD USERS
SYSTEM RELOAD USERS
يعيد تحميل جميع مخازن الوصول، بما في ذلك: users.xml، ومخزن الوصول المحلي على القرص، ومخزن الوصول المُكرَّر (في ZooKeeper).SYSTEM SHUTDOWN
يُغلق ClickHouse عادةً (مثلservice clickhouse-server stop / kill {$pid_clickhouse-server})
SYSTEM KILL
ينهي عملية ClickHouse قسرًا (مثلkill -9 {$ pid_clickhouse-server})
SYSTEM INSTRUMENT
يدير نقاط التتبّع باستخدام ميزة XRay من LLVM، وهي متاحة عندما يُبنى ClickHouse باستخدامENABLE_XRAY=1.
ويتيح ذلك تصحيح الأعطال وتحليل الأداء في بيئة الإنتاج من دون تعديل الشيفرة المصدرية وبأقل تكلفة إضافية ممكنة.
وعند عدم إضافة أي نقطة تتبّع، تكون كلفة الأداء مهملة تقريبًا، لأنه لا يضيف سوى قفزة إضافية إلى عنوان قريب
في بداية تلك الدوال ونهايتها التي يزيد طولها على 200 تعليمة.
SYSTEM INSTRUMENT ADD
يضيف نقطة تتبّع جديدة. يمكن فحص الدوال التي أُضيفت إليها تتبّع في جدول النظامsystem.instrumentation. ويمكن إضافة أكثر من handler واحد إلى الدالة نفسها، وسيُنفَّذ بالترتيب نفسه الذي أُضيفت به تتبّع.
يمكن جلب الدوال المطلوب تتبّعها من جدول النظام system.symbols.
توجد ثلاثة أنواع مختلفة من handler يمكن إضافتها إلى الدوال:
Syntax
FUNCTION أي دالة أو جزءًا فرعيًا من دالة، مثل QueryMetricLog::startQuery، ويكون المعالج أحد العناصر التالية
LOG
يطبع النص المُمرَّر كوسيطة وأثر المكدس عندENTRY أو EXIT للدالة.
SLEEP
يتوقف لمدة ثابتة من الثواني، سواء عندENTRY أو EXIT:
PROFILE
يقيس الوقت المستغرَق بينENTRY وEXIT في الدالة.
تُخزَّن نتيجة التنميط في system.trace_log، ويمكن تحويلها
إلى تنسيق تتبّع أحداث Chrome.
SYSTEM INSTRUMENT REMOVE
يزيل نقطة تتبّع واحدة بإحدى الطريقتين التاليتين:ALL:
system.instrumentation.
إدارة الجداول الموزعة
يمكن لـ ClickHouse إدارة جداول Distributed. عند إدراج مستخدمٍ بياناتٍ في هذه الجداول، ينشئ ClickHouse أولًا قائمة انتظار للبيانات المطلوب إرسالها إلى عُقد عنقود، ثم يرسلها بشكل غير متزامن. يمكنك إدارة معالجة قائمة الانتظار باستخدام الاستعلاماتSTOP DISTRIBUTED SENDS وFLUSH DISTRIBUTED وSTART DISTRIBUTED SENDS. ويمكنك أيضًا إدراج البيانات الموزعة بشكل متزامن باستخدام الإعداد distributed_foreground_insert.
SYSTEM STOP DISTRIBUTED SENDS
يعطّل توزيع البيانات في الخلفية عند إدراج البيانات في الجداول الموزعة.إذا كان
prefer_localhost_replica مُمكّنًا (وهو الإعداد الافتراضي)، فستُدرَج البيانات في الشظية المحلية على أي حال.SYSTEM FLUSH DISTRIBUTED
يُجبر ClickHouse على إرسال البيانات إلى عُقد العنقود بشكل متزامن. وإذا كانت أي من العُقد غير متاحة، فإن ClickHouse يرفع استثناءً ويوقف تنفيذ الاستعلام. يمكنك إعادة محاولة الاستعلام حتى ينجح، وسيحدث ذلك عندما تعود جميع العُقد للعمل. يمكنك أيضًا تجاوز بعض الإعدادات عبر العبارةSETTINGS، وقد يكون ذلك مفيدًا لتجاوز بعض القيود المؤقتة، مثل max_concurrent_queries_for_all_users أو max_memory_usage.
تُخزَّن كل كتلة معلّقة على القرص وفقًا لإعدادات استعلام INSERT الأصلي، لذلك قد تحتاج أحيانًا إلى تجاوز هذه الإعدادات.
SYSTEM START DISTRIBUTED SENDS
يُفعِّل توزيع البيانات في الخلفية عند إدراج البيانات في الجداول الموزعة.SYSTEM STOP LISTEN
يُغلق المقبس وينهي الاتصالات الحالية مع الخادم على المنفذ المحدد وباستخدام البروتوكول المحدد، وذلك بشكلٍ منظم. ومع ذلك، إذا لم تكن إعدادات البروتوكول المقابلة محددة في إعداد clickhouse-server، فلن يكون لهذا الأمر أي تأثير.- إذا جرى تحديد المُعدِّل
CUSTOM 'protocol'، فسيتم إيقاف البروتوكول المخصّص الذي يحمل الاسم المحدد، والمُعرَّف في قسم البروتوكولات ضمن إعدادات الخادم. - إذا جرى تحديد المُعدِّل
QUERIES ALL [EXCEPT .. [,..]]، فسيتم إيقاف جميع البروتوكولات، ما لم يُنص على خلاف ذلك باستخدام العبارةEXCEPT. - إذا جرى تحديد المُعدِّل
QUERIES DEFAULT [EXCEPT .. [,..]]، فسيتم إيقاف جميع البروتوكولات الافتراضية، ما لم يُنص على خلاف ذلك باستخدام العبارةEXCEPT. - إذا جرى تحديد المُعدِّل
QUERIES CUSTOM [EXCEPT .. [,..]]، فسيتم إيقاف جميع البروتوكولات المخصّصة، ما لم يُنص على خلاف ذلك باستخدام العبارةEXCEPT.
SYSTEM START LISTEN
يسمح بإنشاء اتصالات جديدة عبر البروتوكولات المحددة. ومع ذلك، إذا لم يكن الخادم على المنفذ والبروتوكول المحددين قد أُوقِف باستخدام الأمر SYSTEM STOP LISTEN، فلن يكون لهذا الأمر أي تأثير.إدارة جداول MergeTree
يمكن لـ ClickHouse إدارة العمليات التي تُنفَّذ في الخلفية في جداول MergeTree.SYSTEM STOP MERGES
يتيح إيقاف عمليات الدمج في الخلفية للجداول من عائلة MergeTree:سيؤدي تنفيذ
DETACH / ATTACH على الجدول إلى بدء عمليات الدمج في الخلفية لهذا الجدول، حتى إذا كانت عمليات الدمج قد أُوقِفت سابقًا لجميع جداول MergeTree.SYSTEM START MERGES
يتيح بدء عمليات الدمج في الخلفية لجداول عائلة MergeTree:SYSTEM STOP TTL MERGES
يوفّر إمكانية إيقاف الحذف التلقائي للبيانات القديمة في الخلفية وفقًا لـ تعبير TTL للجداول ضمن عائلة MergeTree: يُرجعOk. حتى إذا لم يكن الجدول موجودًا أو لم يكن يستخدم محرك MergeTree. ويُرجع خطأ إذا كانت قاعدة البيانات غير موجودة:
SYSTEM START TTL MERGES
يوفّر إمكانية بدء عمليات الدمج في الخلفية لحذف البيانات القديمة وفقًا لـ تعبير TTL للجداول في عائلة MergeTree: يعيدOk. حتى إذا لم يكن الجدول موجودًا. ويعيد خطأً إذا لم تكن قاعدة البيانات موجودة:
SYSTEM STOP MOVES
يوفّر إمكانية إيقاف عمليات نقل البيانات في الخلفية وفقًا لـ تعبير TTL للجدول مع العبارة TO VOLUME أو TO DISK للجداول في عائلة MergeTree: يعيدOk. حتى إذا لم يكن الجدول موجودًا. ويعيد خطأً عندما لا تكون قاعدة البيانات موجودة:
SYSTEM START MOVES
يوفّر إمكانية بدء عمليات نقل البيانات في الخلفية وفقًا لـ تعبير TTL للجدول مع عبارتي TO VOLUME وTO DISK للجداول في عائلة MergeTree: يُرجعOk. حتى إذا لم يكن الجدول موجودًا. ويُرجع خطأً عندما لا تكون قاعدة البيانات موجودة:
SYSTEM UNFREEZE
يحذف نسخة احتياطية مجمّدة بالاسم المحدد من جميع الأقراص. لمعرفة المزيد عن إلغاء تجميد الأجزاء بشكل منفصل، راجع ALTER TABLE table_name UNFREEZE WITH NAMESYSTEM WAIT LOADING PARTS
انتظر حتى يكتمل تحميل جميع أجزاء بيانات الجدول التي تُحمَّل بشكل غير متزامن (أجزاء البيانات القديمة).إدارة جداول ReplicatedMergeTree
يمكن لـ ClickHouse إدارة عمليات النسخ المتماثل ذات الصلة التي تعمل في الخلفية في جداول ReplicatedMergeTree.SYSTEM STOP FETCHES
يوفّر إمكانية إيقاف عمليات الجلب في الخلفية للأجزاء المُدرجة للجداول ضمن عائلةReplicatedMergeTree:
يُرجِع دائمًا Ok. بغضّ النظر عن محرك الجدول، وحتى إذا لم يكن الجدول أو قاعدة البيانات موجودَين.
SYSTEM START FETCHES
يوفّر إمكانية بدء عمليات الجلب في الخلفية للأجزاء المُدخلة للجداول ضمن عائلةReplicatedMergeTree:
ويُرجع دائمًا Ok. بغضّ النظر عن محرك الجدول، وحتى إذا لم يكن الجدول أو قاعدة البيانات موجودًا.
SYSTEM STOP REPLICATED SENDS
يتيح إيقاف عمليات الإرسال في الخلفية إلى النسخ المتماثلة الأخرى في العنقود للأجزاء الجديدة المُدرجة في جداول عائلةReplicatedMergeTree:
SYSTEM START REPLICATED SENDS
يتيح بدء عمليات الإرسال الخلفية إلى النُسخ المتماثلة الأخرى في العنقود للأجزاء الجديدة المُدرجة في الجداول ضمن عائلةReplicatedMergeTree:
SYSTEM STOP REPLICATION QUEUES
يتيح إيقاف مهام الجلب الخلفية من قوائم انتظار النسخ المتماثل المخزّنة في ZooKeeper للجداول ضمن عائلةReplicatedMergeTree. أنواع مهام الخلفية الممكنة هي - عمليات الدمج، وعمليات الجلب، وعمليات mutation، وعبارات DDL التي تتضمن عبارة ON CLUSTER:
SYSTEM START REPLICATION QUEUES
يتيح بدء مهام الجلب الخلفية من قوائم انتظار النسخ المتماثل المخزّنة في ZooKeeper للجداول من عائلةReplicatedMergeTree. أنواع المهام الخلفية الممكنة: عمليات الدمج، وعمليات الجلب، وعمليات التعديل، وعبارات DDL مع البند ON CLUSTER:
SYSTEM STOP PULLING REPLICATION LOG
يوقف تحميل الإدخالات الجديدة من سجل النسخ المتماثل إلى قائمة انتظار النسخ المتماثل في جدولReplicatedMergeTree.
SYSTEM START PULLING REPLICATION LOG
يلغي الأمرSYSTEM STOP PULLING REPLICATION LOG.
SYSTEM SYNC REPLICA
انتظر حتى تتم مزامنة جدولReplicatedMergeTree مع النسخ المتماثلة الأخرى في العنقود، على ألا تتجاوز مدة الانتظار receive_timeout ثانية.
[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، لكنه لا ينتظر معالجة أي شيء.
SYNC DATABASE REPLICA
ينتظر إلى أن تطبّق قاعدة البيانات المكرّرة المحددة جميع تغييرات المخطط من قائمة انتظار DDL الخاصة بتلك القاعدة. الصياغةSYSTEM RESTART REPLICA
يوفّر هذا الأمر إمكانية إعادة تهيئة حالة جلسة ZooKeeper لجدولReplicatedMergeTree، إذ يقارن الحالة الحالية مع ZooKeeper باعتباره المصدر المرجعي المعتمد، ويضيف مهام إلى قائمة انتظار ZooKeeper عند الحاجة.
تتم تهيئة قائمة انتظار النسخ المتماثل استنادًا إلى بيانات ZooKeeper بالطريقة نفسها المتبعة في تعليمة ATTACH TABLE. وخلال فترة قصيرة، لن يكون الجدول متاحًا لإجراء أي عمليات.
SYSTEM RESTORE REPLICA
يستعيد نسخة متماثلة إذا كانت البيانات موجودة [على الأرجح] لكن بيانات ZooKeeper الوصفية مفقودة. يعمل فقط على جداولReplicatedMergeTree في وضع readonly.
يمكن تنفيذ الاستعلام بعد:
- فقدان جذر ZooKeeper
/. - فقدان مسار النسخ المتماثلة
/replicas. - فقدان مسار نسخة متماثلة فردية
/replicas/replica_name/.
تُنقل الأجزاء في جميع حالاتها إلى المجلد
detached/. وتُرفَق الأجزاء التي كانت نشطة قبل فقدان البيانات (committed).SYSTEM RESTORE DATABASE REPLICA
يستعيد نسخة متماثلة إذا كانت البيانات موجودة [من المحتمل] لكن البيانات الوصفية في ZooKeeper مفقودة. الصياغةSYSTEM RESTART REPLICAS
يوفّر إمكانية إعادة تهيئة حالة جلسات ZooKeeper لجميع جداولReplicatedMergeTree، ويقارن الحالة الحالية مع ZooKeeper بوصفه المصدر المرجعي الصحيح، ويضيف مهام إلى قائمة الانتظار في ZooKeeper إذا لزم الأمر
SYSTEM CLEAR|DROP FILESYSTEM CACHE
يسمح بمسح ذاكرة التخزين المؤقت لنظام الملفات.SYSTEM SYNC FILE CACHE
هذا الإجراء مكلف جدًا وقد يُساء استخدامه.
SYSTEM LOAD PRIMARY KEY
حمّل المفاتيح الأساسية للجدول المعني أو لجميع الجداول.SYSTEM UNLOAD PRIMARY KEY
يؤدي هذا الأمر إلى إلغاء تحميل المفاتيح الأساسية للجدول المحدد أو لجميع الجداول.إدارة Refreshable Materialized Views
أوامر للتحكم في المهام التي تُنفَّذ في الخلفية بواسطة Refreshable Materialized Views راقبsystem.view_refreshes عند استخدامها.
SYSTEM STOP [REPLICATED] VIEW, STOP VIEWS
عطّل التحديث الدوري للعرض المحدد أو لجميع العروض القابلة للتحديث. وإذا كان هناك تحديث جارٍ، فألغِه أيضًا. إذا كان العرض ضمن قاعدة بيانات Replicated أو Shared، فإنSTOP VIEW يؤثر فقط في النسخة المتماثلة الحالية، بينما يؤثر STOP REPLICATED VIEW في جميع النسخ المتماثلة.
لا تستمر حالة الإيقاف بعد إعادة تشغيل الخادم. بعد إعادة التشغيل، ستستأنف العروض جداول التحديث المُعدّة لها.
في قواعد بيانات Replicated أو Shared، يؤثر
SYSTEM STOP VIEW فقط في النسخة المتماثلة الحالية. استخدم SYSTEM STOP REPLICATED VIEW لإيقاف عمليات التحديث على جميع النسخ المتماثلة.SYSTEM START [REPLICATED] VIEW, START VIEWS
فعِّل التحديث الدوري للعرض المحدد أو لجميع العروض القابلة للتحديث. ولا يؤدي ذلك إلى تشغيل تحديث فوري. إذا كان العرض موجودًا في قاعدة بيانات Replicated أو Shared، فإنSTART VIEW يلغي أثر STOP VIEW، وSTART REPLICATED VIEW يلغي أثر STOP REPLICATED VIEW. كما يلغي START VIEW أثر PAUSE VIEW.
SYSTEM PAUSE VIEW, PAUSE VIEWS
عطّل التحديث الدوري للعرض المحدد أو لجميع العروض القابلة للتحديث. وعلى خلافSYSTEM STOP VIEW، فإن SYSTEM PAUSE VIEW لا يوقف تحديثًا قيد التنفيذ بالفعل: يُسمح للتحديث الجاري بأن يكتمل، ولا تُمنع إلا التحديثات اللاحقة.
يمكن التراجع عن ذلك باستخدام SYSTEM START VIEW أو SYSTEM START VIEWS.
لا تستمر حالة الإيقاف المؤقت بعد إعادة تشغيل الخادم. بعد إعادة التشغيل، ستستأنف العروض جداول التحديث المُهيأة لها.
في قواعد البيانات Replicated أو Shared، يؤثر
SYSTEM PAUSE VIEW في النسخة المتماثلة الحالية فقط.SYSTEM REFRESH VIEW
نفّذ تحديثًا فوريًا خارج الجدولة لعرضٍ معيّن.SYSTEM WAIT VIEW
ينتظر اكتمال عملية التحديث الجارية. وإذا لم تكن هناك أي عملية تحديث قيد التشغيل، فيعود فورًا. وإذا فشلت أحدث محاولة تحديث، فسيُبلّغ عن خطأ. يمكن استخدامه مباشرةً بعد إنشاء refreshable materialized view جديد (من دون الكلمة المفتاحية EMPTY) لانتظار اكتمال التحديث الأولي. إذا كان العرض موجودًا في قاعدة بيانات Replicated أو Shared database، وكانت عملية التحديث جارية على نسخة متماثلة أخرى، فإنه ينتظر اكتمال ذلك التحديث.SYSTEM CANCEL VIEW
إذا كانت هناك عملية تحديث جارية للعرض المحدد على النسخة المتماثلة الحالية، فقُم بمقاطعتها وإلغائها. وإلا فلا تفعل شيئًا.إدارة النشاط في الخلفية
أوامر مستقلة عن المحرك للتحكم في النشاط في الخلفية لجدول واحد، أو لجميع هذه الجداول على الخادم دفعةً واحدة. وتشمل:- العروض المادية القابلة للتحديث (التحديث الدوري)، و
- محركات الجداول المتدفقة التي تستهلك باستمرار من مصدر خارجي: 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 STOP
أوقف النشاطات التي تعمل في الخلفية وأبقِها متوقفة: أوقف ما يعمل حاليًا، ولا تشغّل أي شيء آخر حتىSYSTEM START. وهو مكافئ لـ PAUSE + CANCEL.
SYSTEM START
يستأنف النشاط بعدSYSTEM STOP أو SYSTEM PAUSE سابق. لا يؤدي ذلك إلى مقاطعة أي نشاط.
SYSTEM PAUSE
أوقف أي نشاط في الخلفية، مع السماح للعمليات الجارية حاليًا بالانتهاء أولًا.SYSTEM CANCEL
يوقف النشاط الجاري حاليًا فقط، دون منع الأنشطة المستقبلية — يواصل الجدول التحديث أو الاستهلاك وفق جدوله الزمني. لا يفعل شيئًا إذا لم يكن هناك نشاط قيد التنفيذ.SYSTEM REFRESH
شغّل دورة إضافية خارج الجدول الزمني المحدد. في جدول متدفق، تُنفَّذ فورًا ولمرة واحدة، حتى إذا كان الجدول متوقفًا أو في حالة إيقاف مؤقت. أما في العرض المادي القابل للتحديث، فيتصرف كما يتصرفSYSTEM REFRESH VIEW: إذا كان العرض متوقفًا، يُتذكَّر طلب التحديث ويُنفَّذ مرة واحدة عند استئنافه بواسطة SYSTEM START.
الامتيازات
يتطلب كل أمر امتياز المحرك المستهدف:SYSTEM VIEWS للعرض المادي القابل للتحديث، وSYSTEM STREAMING ENGINES للجدول المتدفق. وكلاهما يندرج ضمن SYSTEM BACKGROUND، لذا يتيح منح SYSTEM BACKGROUND التحكم في النشاط في الخلفية لجميع هذه الجداول. ولا تنطبق صيغ ALL BACKGROUND إلا على الجداول التي يملك المستخدم صلاحية التحكم فيها، وتتجاوز البقية بصمت.
SYSTEM FLUSH OBJECT STORAGE QUEUE
ينتظر إلى أن تتم معالجة الملف المحدد أو أن يفشل نهائيًا ضمن جدول S3Queue أو AzureQueue المحدد. ويعود فورًا إذا كان الملف قد تمت معالجته بالفعل. ويُصدر خطأ إذا كان الملف قد فشل نهائيًا (بعد استنفاد جميع إعادة المحاولة).SYSTEM ENABLE|DISABLE FAILPOINT
نقاط الفشل (failpoints) هي مواضع مُسمّاة في شيفرة الخادم يمكن عندها حقن عطل عند الطلب — خطأ، أو تأخير، أو إيقاف مؤقت لخيط التنفيذ الجاري — لأغراض الاختبار. وهي مُدرجة في جدولsystem.fail_points مع حالتها الحالية.
SYSTEM ENABLE FAILPOINT يُفعّل نقطة فشل واحدة؛ أما SYSTEM DISABLE FAILPOINT فيُعطّلها ويستأنف أي خيط تنفيذ محجوب عندها، ولا يكون له أي أثر إن لم تكن مفعّلة أصلًا.
SYSTEM DISABLE ALL FAILPOINTS يُعطّل جميع نقاط الفشل دفعةً واحدة ويستأنف كل خيط تنفيذ محجوب عند نقطة قابلة للإيقاف المؤقت. وهو لا يأخذ أي اسم وعديم التأثير عند التكرار، لذا يمكن لبيئة الاختبار استخدامه لإعادة الخادم إلى حالة لا يُحقن فيها أي شيء دون الحاجة إلى معرفة نقاط الفشل التي فعّلها الاختبار السابق. وفي بناء لا يدعم نقاط الفشل، تنجح العبارة دون أن تفعل شيئًا.
SYSTEM WAIT FAILPOINT ... PAUSE يحجب التنفيذ إلى أن يتوقف خيط تنفيذ مؤقتًا عند نقطة الفشل القابلة للإيقاف المحددة (أو إلى أن تُعطَّل نقطة الفشل)، و... RESUME يحجب التنفيذ إلى أن يُستأنف خيط التنفيذ المتوقف مؤقتًا، أما SYSTEM NOTIFY FAILPOINT فيستأنف خيوط التنفيذ المتوقفة مؤقتًا دون تعطيل نقطة الفشل.
نقاط الفشل حالة محلية على مستوى العقدة، لذا لا تقبل أي من هذه العبارات ON CLUSTER. وتتطلب جميعها امتياز SYSTEM FAILPOINT.