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

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

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

تحجيم النسخ المتماثلة

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

spec:
  replicas: 3   # was 1
  keeperClusterRef:
    name: my-keeper

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

تحجيم الشاردات

يحدّد spec.shards عدد الشاردات. ويضيف كل شارد جديد مجموعة كاملة من StatefulSets لكل نسخة متماثلة، كما ينشئ المشغّل مورد PodDisruptionBudget واحدًا لكل شارد بحيث لا يُحتسب أي انقطاع في شارد واحد على حساب شارد آخر.

spec:
  shards: 3   # was 1
  replicas: 2

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

المزامنة التلقائية للمخطط

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

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

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

الحالات التي ينبغي مراقبتها

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

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.

تحجيم Keeper

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

spec:
  replicas: 5   # was 3

عند التوسيع، يضيف المشغّل أدنى معرّف متاح لنسخة متماثلة إلى النصاب؛ وعند التقليص، يزيل أعلى معرّف. وتنتظر كل خطوة حتى يستقر النصاب قبل بدء الخطوة التالية. تكون القيمة الافتراضية لـ Keeper PodDisruptionBudget هي maxUnavailable: replicas/2 للحفاظ على النصاب أثناء عمليات التعطيل الطوعية. توضّح الحالة ScaleAllowed ما إذا كان يمكن تغيير عضوية النصاب في الوقت الحالي:

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

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

التثبيت

الأدلة

المرجع

تحجيم النسخ المتماثلة

تحجيم الشاردات

المزامنة التلقائية للمخطط

الحالات التي ينبغي مراقبتها

تحجيم Keeper

​تحجيم النسخ المتماثلة

​تحجيم الشاردات

​المزامنة التلقائية للمخطط

​الحالات التي ينبغي مراقبتها

​تحجيم Keeper

تحجيم النسخ المتماثلة

تحجيم الشاردات

المزامنة التلقائية للمخطط

الحالات التي ينبغي مراقبتها

تحجيم Keeper