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

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

يمكنك تحجيم عنقود من خلال تعديل عدد النسخ المتماثلة والشاردات في المورد المخصص. ويُجري المشغّل مواءمة للعنقود العامل مع البنية الجديدة: فينشئ أو يزيل 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 التي تتم عضوًا واحدًا في كل مرة — إذ يظل المشغّل يمرّ عبر النصاب عضوًا واحدًا في كل خطوة.