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

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

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

يضبط 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، وتعرض SchemaInSync القيمة ReplicasInSync، وتعرض Ready القيمة AllShardsReady.

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

spec:
  replicas: 5   # was 3

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

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

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