> ## Documentation Index
> Fetch the complete documentation index at: https://clickhouse.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# تحجيم العناقيد

> كيفية تحجيم النسخ المتماثلة والشاردات في ClickHouse وأعضاء النصاب في Keeper، وما الذي ينفّذه المشغّل تلقائيًا.

يمكنك تحجيم عنقود من خلال تعديل عدد النسخ المتماثلة والشاردات في المورد المخصص. ويُجري المشغّل مواءمة للعنقود العامل مع البنية الجديدة: فينشئ أو يزيل StatefulSets لكل نسخة متماثلة، ويحافظ على تزامن المخطط، ويُظهر التقدّم عبر شروط الحالة.

يوضح هذا الدليل كيفية تحجيم النسخ المتماثلة والشاردات في `ClickHouseCluster`، وكيفية تحجيم نصاب `KeeperCluster` بأمان، وما هي شروط الحالة التي ينبغي مراقبتها أثناء تنفيذ عملية التوسيع.

<Note>
  يحتاج `ClickHouseCluster` دائمًا إلى Keeper، ويُشار إليه عبر الحقل الإلزامي `spec.keeperClusterRef` — ويُنسّق المشغّل العنقود من خلاله بغضّ النظر عن حجمه. ولتشغيل أكثر من نسخة متماثلة واحدة لكل شارد، يجب أيضًا أن تكون البيانات مخزّنة في جداول `ReplicatedMergeTree`، لأن replication هي ما يتيح لنسخة متماثلة ثانية تقديم الصفوف نفسها.
</Note>

<div id="scaling-replicas">
  ## تحجيم النسخ المتماثلة
</div>

يضبط `spec.replicas` عدد النسخ المتماثلة في كل shard. تعمل كل نسخة متماثلة ضمن StatefulSet مستقل باسم `<cluster>-clickhouse-<shard>-<replica>`، لذا فإن أي عنقود يتضمن `shards: 2` و`replicas: 3` يشغّل ستة StatefulSets.

ارفع العدد أو اخفضه مباشرةً:

```yaml theme={null}
spec:
  replicas: 3   # was 1
  keeperClusterRef:
    name: my-keeper
```

عند التوسيع، ينشئ المشغّل موارد StatefulSet جديدة لكل نسخة متماثلة، وينتظر حتى يصبح كل جراب جاهزًا، ثم يزامن المخطط مع النسخ المتماثلة الجديدة (انظر [المزامنة التلقائية للمخطط](#automatic-schema-sync)). وعند التقليص، يزيل موارد StatefulSet الزائدة وينظّف تسجيلات النسخ المتماثلة القديمة لقاعدة البيانات المُكرَّرة التي خلّفتها النسخ المتماثلة التي أُزيلت.

<div id="scaling-shards">
  ## تحجيم الشاردات
</div>

يحدّد `spec.shards` عدد الشاردات. ويضيف كل شارد جديد مجموعة كاملة من StatefulSets لكل نسخة متماثلة، كما ينشئ المشغّل [مورد PodDisruptionBudget واحدًا لكل شارد](/docs/ar/products/kubernetes-operator/guides/configuration#pod-disruption-budgets) بحيث لا يُحتسب أي انقطاع في شارد واحد على حساب شارد آخر.

```yaml theme={null}
spec:
  shards: 3   # was 1
  replicas: 2
```

تحتفظ كل شارد بجزء منفصل من البيانات، ولا يقوم المشغّل بنسخ الصفوف أو نقلها بين الشاردات. ويحدّد جدول `Distributed` أو آلية توجيه صريحة الشارد الذي يستقر فيه الصف، لذا فإن إضافة شارد توفّر وجهةً لعمليات الكتابة الجديدة من دون المساس بالصفوف المخزّنة بالفعل في الشاردات الحالية.

<div id="automatic-schema-sync">
  ## المزامنة التلقائية للمخطط
</div>

عندما تكون `spec.settings.enableDatabaseSync` مساوية لـ `true` (وهو الإعداد الافتراضي)، يُبقي المُشغِّل المخطط متوافقًا مع تغيّر الطوبولوجيا:

* **عند التوسّع** — بمجرد أن تصبح هناك نسختان متماثلتان جاهزتان على الأقل، ينسخ المُشغِّل تعريفات قواعد البيانات إلى النسخ المتماثلة المُنشأة حديثًا، بحيث تنضم النسخة المتماثلة الجديدة وهي تحمل قواعد بيانات `Replicated` وقواعد بيانات التكامل نفسها الموجودة في بقية العقد في العنقود.
* **عند التقليص** — قبل اختفاء نسخة متماثلة، يحذف المُشغِّل تسجيل تلك النسخة من كل قاعدة بيانات `Replicated` باستخدام `SYSTEM DROP DATABASE REPLICA`، حتى لا ينتظر العنقود بعد تقليصه نسخةً متماثلة لقاعدة بيانات `Replicated` لم تعد موجودة.

يشمل ذلك قواعد بيانات `Replicated` ومحركات قواعد بيانات التكامل. ولا ينقل هذا بيانات الجداول — إذ تبقى بيانات الصفوف في جداول `ReplicatedMergeTree` ويجري نسخها المتماثل عبر Keeper بشكل مستقل عن مزامنة المخطط هذه. وعند وجود نسخة متماثلة جاهزة واحدة فقط، لا توجد جهة هدف للنسخ إليها، لذلك يتجاوز المُشغِّل هذه الخطوة ويسجّل أنه لا يملك هدفًا.

اضبط `enableDatabaseSync: false` لتعطيل هذا السلوك، على سبيل المثال عندما تتولى أداة خارجية نشر المخطط. وعندها يبلّغ المُشغِّل عن السبب `SchemaSyncDisabled` في الحالة `SchemaInSync`.

<div id="scaling-conditions">
  ## الحالات التي ينبغي مراقبتها
</div>

تفقد التقدّم في المورد المخصص أثناء تنفيذ عملية التحجيم:

```bash theme={null}
kubectl get clickhousecluster sample -o yaml | sed -n '/conditions:/,/^[^ ]/p'
```

| الحالة               | السبب                  | المعنى                                                                              |
| -------------------- | ---------------------- | ----------------------------------------------------------------------------------- |
| `ClusterSizeAligned` | `UpToDate`             | يتطابق عدد النسخ المتماثلة العاملة مع البنية المطلوبة                               |
| `ClusterSizeAligned` | `ScalingUp`            | يضيف المشغّل نسخًا متماثلة                                                          |
| `ClusterSizeAligned` | `ScalingDown`          | يزيل المشغّل نسخًا متماثلة                                                          |
| `SchemaInSync`       | `ReplicasInSync`       | قواعد البيانات موجودة على جميع النسخ المتماثلة، وتمت إزالة البيانات الوصفية القديمة |
| `SchemaInSync`       | `DatabasesNotCreated`  | لم ينتهِ المشغّل بعد من إنشاء قواعد البيانات على النسخ المتماثلة الجديدة            |
| `SchemaInSync`       | `ReplicasNotCleanedUp` | لم تُزل بعد البيانات الوصفية القديمة للنسخ المتماثلة بعد عملية التقليص              |
| `SchemaInSync`       | `SchemaSyncDisabled`   | `enableDatabaseSync` مضبوط على `false`                                              |
| `Ready`              | `AllShardsReady`       | يحتوي كل شارد على نسخة متماثلة جاهزة                                                |
| `Ready`              | `SomeShardsNotReady`   | يوجد شارد واحد على الأقل لا يحتوي على نسخة متماثلة جاهزة                            |

تكتمل عملية تغيير الحجم عندما تعرض `ClusterSizeAligned` القيمة `UpToDate`، وتعرض `SchemaInSync` القيمة `ReplicasInSync`، وتعرض `Ready` القيمة `AllShardsReady`.

<div id="scaling-keeper">
  ## تحجيم Keeper
</div>

يشغّل `KeeperCluster` نصاب RAFT، لذلك لا يغيّر المشغّل أعضاءه إلا **بواقع نسخة متماثلة واحدة في كل مرة**، وفقط عندما يكون الـ عنقود في حالة مستقرة. وهذا يحمي النصاب: إذ يمكن لعنقود من نوع `2F+1` تحمّل تعطل `F` من الأعضاء، لذا يواصل عنقود مكوّن من 3 عُقد العمل مع غياب عضو واحد، وعنقود مكوّن من 5 عُقد مع غياب عضوين.

```yaml theme={null}
spec:
  replicas: 5   # was 3
```

عند التوسيع، يضيف المشغّل أدنى معرّف متاح لنسخة متماثلة إلى النصاب؛ وعند التقليص، يزيل أعلى معرّف. وتنتظر كل خطوة حتى يستقر النصاب قبل بدء الخطوة التالية. تكون القيمة الافتراضية لـ [Keeper PodDisruptionBudget](/docs/ar/products/kubernetes-operator/guides/configuration#pod-disruption-budgets) هي `maxUnavailable: replicas/2` للحفاظ على النصاب أثناء عمليات التعطيل الطوعية.

توضّح الحالة `ScaleAllowed` ما إذا كان يمكن تغيير عضوية النصاب في الوقت الحالي:

| Reason                     | Meaning                                               |
| -------------------------- | ----------------------------------------------------- |
| `ReadyToScale`             | النصاب مستقر ويمكن للمشغّل إضافة عضو أو إزالته        |
| `ReplicaHasPendingChanges` | لا تزال لدى نسخة متماثلة تغييرات تهيئة معلّقة         |
| `ReplicaNotReady`          | نسخة متماثلة غير جاهزة، لذا تنتظر تغييرات العضوية     |
| `NoQuorum`                 | لا يوجد نصاب في العنقود، ولا يمكن تغيير العضوية بأمان |
| `WaitingFollowers`         | ينتظر المشغّل حتى تلحق العُقد التابعة بالركب          |

وسّع Keeper أو قلّصه على مراحل فردية، ودَع `ScaleAllowed` يعود إلى `ReadyToScale` بين كل تغيير وآخر. فالانتقال بعدة أعضاء دفعة واحدة لا يتجاوز عملية `reconcile` التي تتم عضوًا واحدًا في كل مرة — إذ يظل المشغّل يمرّ عبر النصاب عضوًا واحدًا في كل خطوة.