```
### SYSTEM WAIT LOADING PARTS
انتظر حتى يكتمل تحميل جميع أجزاء بيانات الجدول التي تُحمَّل بشكل غير متزامن (أجزاء البيانات القديمة).
```sql theme={null}
SYSTEM WAIT LOADING PARTS [ON CLUSTER cluster_name] [db.]merge_tree_family_table_name
```
## إدارة جداول ReplicatedMergeTree
يمكن لـ ClickHouse إدارة عمليات النسخ المتماثل ذات الصلة التي تعمل في الخلفية في جداول [ReplicatedMergeTree](/ar/reference/engines/table-engines/mergetree-family/replication).
### SYSTEM STOP FETCHES
يوفّر إمكانية إيقاف عمليات الجلب في الخلفية للأجزاء المُدرجة للجداول ضمن عائلة `ReplicatedMergeTree`:
يُرجِع دائمًا `Ok.` بغضّ النظر عن محرك الجدول، وحتى إذا لم يكن الجدول أو قاعدة البيانات موجودَين.
```sql theme={null}
SYSTEM STOP FETCHES [ON CLUSTER cluster_name] [[db.]replicated_merge_tree_family_table_name]
```
### SYSTEM START FETCHES
يوفّر إمكانية بدء عمليات الجلب في الخلفية للأجزاء المُدخلة للجداول ضمن عائلة `ReplicatedMergeTree`:
ويُرجع دائمًا `Ok.` بغضّ النظر عن محرك الجدول، وحتى إذا لم يكن الجدول أو قاعدة البيانات موجودًا.
```sql theme={null}
SYSTEM START FETCHES [ON CLUSTER cluster_name] [[db.]replicated_merge_tree_family_table_name]
```
### SYSTEM STOP REPLICATED SENDS
يتيح إيقاف عمليات الإرسال في الخلفية إلى النسخ المتماثلة الأخرى في العنقود للأجزاء الجديدة المُدرجة في جداول عائلة `ReplicatedMergeTree`:
```sql theme={null}
SYSTEM STOP REPLICATED SENDS [ON CLUSTER cluster_name] [[db.]replicated_merge_tree_family_table_name]
```
### SYSTEM START REPLICATED SENDS
يتيح بدء عمليات الإرسال الخلفية إلى النُسخ المتماثلة الأخرى في العنقود للأجزاء الجديدة المُدرجة في الجداول ضمن عائلة `ReplicatedMergeTree`:
```sql theme={null}
SYSTEM START REPLICATED SENDS [ON CLUSTER cluster_name] [[db.]replicated_merge_tree_family_table_name]
```
### SYSTEM STOP REPLICATION QUEUES
يتيح إيقاف مهام الجلب الخلفية من قوائم انتظار النسخ المتماثل المخزّنة في ZooKeeper للجداول ضمن عائلة `ReplicatedMergeTree`. أنواع مهام الخلفية الممكنة هي - عمليات الدمج، وعمليات الجلب، وعمليات mutation، وعبارات DDL التي تتضمن عبارة ON CLUSTER:
```sql theme={null}
SYSTEM STOP REPLICATION QUEUES [ON CLUSTER cluster_name] [[db.]replicated_merge_tree_family_table_name]
```
### SYSTEM START REPLICATION QUEUES
يتيح بدء مهام الجلب الخلفية من قوائم انتظار النسخ المتماثل المخزّنة في ZooKeeper للجداول من عائلة `ReplicatedMergeTree`. أنواع المهام الخلفية الممكنة: عمليات الدمج، وعمليات الجلب، وعمليات التعديل، وعبارات DDL مع البند ON CLUSTER:
```sql theme={null}
SYSTEM START REPLICATION QUEUES [ON CLUSTER cluster_name] [[db.]replicated_merge_tree_family_table_name]
```
### SYSTEM STOP PULLING REPLICATION LOG
يوقف تحميل الإدخالات الجديدة من سجل النسخ المتماثل إلى قائمة انتظار النسخ المتماثل في جدول `ReplicatedMergeTree`.
```sql theme={null}
SYSTEM STOP PULLING REPLICATION LOG [ON CLUSTER cluster_name] [[db.]replicated_merge_tree_family_table_name]
```
### SYSTEM START PULLING REPLICATION LOG
يلغي الأمر `SYSTEM STOP PULLING REPLICATION LOG`.
```sql theme={null}
SYSTEM START PULLING REPLICATION LOG [ON CLUSTER cluster_name] [[db.]replicated_merge_tree_family_table_name]
```
### SYSTEM SYNC REPLICA
انتظر حتى تتم مزامنة جدول `ReplicatedMergeTree` مع النسخ المتماثلة الأخرى في العنقود، على ألا تتجاوز مدة الانتظار `receive_timeout` ثانية.
```sql theme={null}
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، لكنه لا ينتظر معالجة أي شيء.
### SYNC DATABASE REPLICA
ينتظر إلى أن تطبّق [قاعدة البيانات المكرّرة](/ar/reference/engines/database-engines/replicated) المحددة جميع تغييرات المخطط من قائمة انتظار DDL الخاصة بتلك القاعدة.
**الصياغة**
```sql theme={null}
SYSTEM SYNC DATABASE REPLICA replicated_database_name;
```
### SYSTEM RESTART REPLICA
يوفّر هذا الأمر إمكانية إعادة تهيئة حالة جلسة ZooKeeper لجدول `ReplicatedMergeTree`، إذ يقارن الحالة الحالية مع ZooKeeper باعتباره المصدر المرجعي المعتمد، ويضيف مهام إلى قائمة انتظار ZooKeeper عند الحاجة.
تتم تهيئة قائمة انتظار النسخ المتماثل استنادًا إلى بيانات ZooKeeper بالطريقة نفسها المتبعة في تعليمة `ATTACH TABLE`. وخلال فترة قصيرة، لن يكون الجدول متاحًا لإجراء أي عمليات.
```sql theme={null}
SYSTEM RESTART REPLICA [ON CLUSTER cluster_name] [db.]replicated_merge_tree_family_table_name
```
### SYSTEM RESTORE REPLICA
يستعيد نسخة متماثلة إذا كانت البيانات موجودة \[على الأرجح] لكن بيانات ZooKeeper الوصفية مفقودة.
يعمل فقط على جداول `ReplicatedMergeTree` في وضع readonly.
يمكن تنفيذ الاستعلام بعد:
* فقدان جذر ZooKeeper `/`.
* فقدان مسار النسخ المتماثلة `/replicas`.
* فقدان مسار نسخة متماثلة فردية `/replicas/replica_name/`.
تُرفِق النسخة المتماثلة الأجزاء التي عُثر عليها محليًا وترسل معلومات عنها إلى ZooKeeper.
ولا تُجلَب الأجزاء الموجودة على النسخة المتماثلة قبل فقدان البيانات الوصفية مجددًا من النسخ الأخرى ما لم تكن قديمة (لذا فإن استعادة النسخة المتماثلة لا تعني إعادة تنزيل جميع البيانات عبر الشبكة).
تُنقل الأجزاء في جميع حالاتها إلى المجلد `detached/`. وتُرفَق الأجزاء التي كانت نشطة قبل فقدان البيانات (committed).
### SYSTEM RESTORE DATABASE REPLICA
يستعيد نسخة متماثلة إذا كانت البيانات موجودة \[من المحتمل] لكن البيانات الوصفية في ZooKeeper مفقودة.
**الصياغة**
```sql theme={null}
SYSTEM RESTORE DATABASE REPLICA repl_db [ON CLUSTER cluster]
```
**مثال**
```sql theme={null}
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;
```
**الصياغة**
```sql theme={null}
SYSTEM RESTORE REPLICA [db.]replicated_merge_tree_family_table_name [ON CLUSTER cluster_name]
```
الصيغة البديلة:
```sql theme={null}
SYSTEM RESTORE REPLICA [ON CLUSTER cluster_name] [db.]replicated_merge_tree_family_table_name
```
**مثال**
إنشاء جدول على عدة خوادم. بعد فقدان البيانات الوصفية الخاصة بالنسخة المتماثلة في ZooKeeper، سيتم إرفاق الجدول في وضع القراءة فقط بسبب فقدان البيانات الوصفية. يجب تنفيذ الاستعلام الأخير على كل نسخة متماثلة.
```sql theme={null}
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;
```
طريقة أخرى:
```sql theme={null}
SYSTEM RESTORE REPLICA test ON CLUSTER cluster;
```
### SYSTEM RESTART REPLICAS
يوفّر إمكانية إعادة تهيئة حالة جلسات ZooKeeper لجميع جداول `ReplicatedMergeTree`، ويقارن الحالة الحالية مع ZooKeeper بوصفه المصدر المرجعي الصحيح، ويضيف مهام إلى قائمة الانتظار في ZooKeeper إذا لزم الأمر
### SYSTEM CLEAR|DROP FILESYSTEM CACHE
يسمح بمسح ذاكرة التخزين المؤقت لنظام الملفات.
```sql theme={null}
SYSTEM CLEAR FILESYSTEM CACHE [ON CLUSTER cluster_name]
```
### SYSTEM SYNC FILE CACHE
هذا الإجراء مكلف جدًا وقد يُساء استخدامه.
سينفّذ نداء النظام sync.
```sql theme={null}
SYSTEM SYNC FILE CACHE [ON CLUSTER cluster_name]
```
### SYSTEM LOAD PRIMARY KEY
حمّل المفاتيح الأساسية للجدول المعني أو لجميع الجداول.
```sql theme={null}
SYSTEM LOAD PRIMARY KEY [db.]name
```
```sql theme={null}
SYSTEM LOAD PRIMARY KEY
```
### SYSTEM UNLOAD PRIMARY KEY
يؤدي هذا الأمر إلى إلغاء تحميل المفاتيح الأساسية للجدول المحدد أو لجميع الجداول.
```sql theme={null}
SYSTEM UNLOAD PRIMARY KEY [db.]name
```
```sql theme={null}
SYSTEM UNLOAD PRIMARY KEY
```
## إدارة Refreshable Materialized Views
أوامر للتحكم في المهام التي تُنفَّذ في الخلفية بواسطة [Refreshable Materialized Views](/ar/reference/statements/create/view#refreshable-materialized-view)
راقب [`system.view_refreshes`](/ar/reference/system-tables/view_refreshes) عند استخدامها.
### SYSTEM STOP \[REPLICATED] VIEW, STOP VIEWS
عطّل التحديث الدوري للعرض المحدد أو لجميع العروض القابلة للتحديث. وإذا كان هناك تحديث جارٍ، فألغِه أيضًا.
إذا كان العرض ضمن قاعدة بيانات Replicated أو Shared، فإن `STOP VIEW` يؤثر فقط في النسخة المتماثلة الحالية، بينما يؤثر `STOP REPLICATED VIEW` في جميع النسخ المتماثلة.
لا تستمر حالة الإيقاف بعد إعادة تشغيل الخادم. بعد إعادة التشغيل، ستستأنف العروض جداول التحديث المُعدّة لها.
في قواعد بيانات Replicated أو Shared، يؤثر `SYSTEM STOP VIEW` فقط في النسخة المتماثلة الحالية. استخدم `SYSTEM STOP REPLICATED VIEW` لإيقاف عمليات التحديث على جميع النسخ المتماثلة.
```sql theme={null}
SYSTEM STOP VIEW [db.]name
```
```sql theme={null}
SYSTEM STOP VIEWS
```
### SYSTEM START \[REPLICATED] VIEW, START VIEWS
فعِّل التحديث الدوري للعرض المحدد أو لجميع العروض القابلة للتحديث. ولا يؤدي ذلك إلى تشغيل تحديث فوري.
إذا كان العرض موجودًا في قاعدة بيانات Replicated أو Shared، فإن `START VIEW` يلغي أثر `STOP VIEW`، و`START REPLICATED VIEW` يلغي أثر `STOP REPLICATED VIEW`. كما يلغي `START VIEW` أثر `PAUSE VIEW`.
```sql theme={null}
SYSTEM START VIEW [db.]name
```
```sql theme={null}
SYSTEM START VIEWS
```
### SYSTEM PAUSE VIEW, PAUSE VIEWS
عطّل التحديث الدوري للعرض المحدد أو لجميع العروض القابلة للتحديث.
وعلى خلاف `SYSTEM STOP VIEW`، فإن `SYSTEM PAUSE VIEW` لا يوقف تحديثًا قيد التنفيذ بالفعل: يُسمح للتحديث الجاري بأن يكتمل، ولا تُمنع إلا التحديثات اللاحقة.
يمكن التراجع عن ذلك باستخدام `SYSTEM START VIEW` أو `SYSTEM START VIEWS`.
لا تستمر حالة الإيقاف المؤقت بعد إعادة تشغيل الخادم. بعد إعادة التشغيل، ستستأنف العروض جداول التحديث المُهيأة لها.
في قواعد البيانات Replicated أو Shared، يؤثر `SYSTEM PAUSE VIEW` في النسخة المتماثلة الحالية فقط.
```sql theme={null}
SYSTEM PAUSE VIEW [db.]name
```
```sql theme={null}
SYSTEM PAUSE VIEWS
```
### SYSTEM REFRESH VIEW
نفّذ تحديثًا فوريًا خارج الجدولة لعرضٍ معيّن.
```sql theme={null}
SYSTEM REFRESH VIEW [db.]name
```
### SYSTEM WAIT VIEW
ينتظر اكتمال عملية التحديث الجارية. وإذا لم تكن هناك أي عملية تحديث قيد التشغيل، فيعود فورًا. وإذا فشلت أحدث محاولة تحديث، فسيُبلّغ عن خطأ.
يمكن استخدامه مباشرةً بعد إنشاء refreshable materialized view جديد (من دون الكلمة المفتاحية EMPTY) لانتظار اكتمال التحديث الأولي.
إذا كان العرض موجودًا في قاعدة بيانات Replicated أو Shared database، وكانت عملية التحديث جارية على نسخة متماثلة أخرى، فإنه ينتظر اكتمال ذلك التحديث.
```sql theme={null}
SYSTEM WAIT VIEW [db.]name
```
### SYSTEM CANCEL VIEW
إذا كانت هناك عملية تحديث جارية للعرض المحدد على النسخة المتماثلة الحالية، فقُم بمقاطعتها وإلغائها. وإلا فلا تفعل شيئًا.
```sql theme={null}
SYSTEM CANCEL VIEW [db.]name
```
## SYSTEM FLUSH OBJECT STORAGE QUEUE
ينتظر إلى أن تتم معالجة الملف المحدد أو أن يفشل نهائيًا ضمن جدول [S3Queue](/ar/reference/engines/table-engines/integrations/s3queue) أو [AzureQueue](/ar/reference/engines/table-engines/integrations/azure-queue) المحدد. ويعود فورًا إذا كان الملف قد تمت معالجته بالفعل. ويُصدر خطأ إذا كان الملف قد فشل نهائيًا (بعد استنفاد جميع إعادة المحاولة).
```sql theme={null}
SYSTEM FLUSH OBJECT STORAGE QUEUE [db.]table_name PATH 'path'
```