الانتقال إلى المحتوى الرئيسي
لا تسري هذه الصفحة على ClickHouse Cloud. ويُنفَّذ الإجراء الموضَّح هنا تلقائيًا في خدمات ClickHouse Cloud.
يوفّر ClickHouse Keeper نظام التنسيق اللازم للنسخ المتماثل للبيانات وتنفيذ استعلامات replication وdistributed DDL. كما أن ClickHouse Keeper متوافق مع ZooKeeper.

تفاصيل التنفيذ

يُعد ZooKeeper من أوائل أنظمة التنسيق المفتوحة المصدر المعروفة على نطاق واسع. وهو مكتوب بلغة Java ويعتمد نموذج بيانات بسيطًا وقويًا. ولا توفّر خوارزمية التنسيق في ZooKeeper، وهي ZooKeeper Atomic Broadcast ‏(ZAB)، ضمانات الاتساق الخطي لعمليات القراءة، لأن كل عقدة في ZooKeeper تخدم عمليات القراءة محليًا. وعلى عكس ZooKeeper، فإن ClickHouse Keeper مكتوب بلغة C++ ويستخدم تنفيذًا لخوارزمية RAFT. وتتيح هذه الخوارزمية الاتساق الخطي لعمليات القراءة والكتابة، كما تتوفر لها عدة تطبيقات مفتوحة المصدر بلغات مختلفة. يوفّر ClickHouse Keeper افتراضيًا الضمانات نفسها التي يوفّرها ZooKeeper: كتابات متسقة خطيًا وقراءات غير متسقة خطيًا. كما أنه يوفّر بروتوكول عميل-خادم متوافقًا، لذا يمكن استخدام أي عميل ZooKeeper قياسي للتفاعل مع ClickHouse Keeper. وتستخدم اللقطات والسجلات تنسيقًا غير متوافق مع ZooKeeper، لكن أداة clickhouse-keeper-converter تتيح تحويل بيانات ZooKeeper إلى لقطات ClickHouse Keeper. كذلك فإن بروتوكول الاتصال بين الخوادم في ClickHouse Keeper غير متوافق مع ZooKeeper، لذلك يستحيل وجود عنقود مختلط من ZooKeeper / ClickHouse Keeper. يدعم ClickHouse Keeper قوائم التحكم في الوصول (ACLs) بالطريقة نفسها التي يدعمها ZooKeeper. ويدعم ClickHouse Keeper المجموعة نفسها من الأذونات، كما يوفّر آليات built-in المطابقة نفسها: world وauth وdigest. وتستخدم آلية المصادقة digest الزوج username:password، وتُرمَّز كلمة المرور بترميز Base64.
عمليات التكامل الخارجية غير مدعومة.

التهيئة

يمكن استخدام ClickHouse Keeper كبديل مستقل لـ ZooKeeper أو كجزء داخلي من ClickHouse server. وفي كلتا الحالتين، تكون التهيئة في ملف .xml متطابقة تقريبًا.

إعدادات تهيئة Keeper

وسم التهيئة الرئيسي لـ ClickHouse Keeper هو <keeper_server>، ويتضمن المعلمات التالية: تُورَّث المعلمات الشائعة الأخرى من config الخاص بـ ClickHouse server (listen_host وlogger وما إلى ذلك).

إعدادات التنسيق الداخلية

توجد إعدادات التنسيق الداخلية في القسم <keeper_server>.<coordination_settings>، وتتضمن المعلمات التالية: يوجد إعداد النصاب في القسم <keeper_server>.<raft_configuration>، ويتضمن وصف الخوادم. المعلمة الوحيدة للنصاب بالكامل هي secure، وهي تُمكّن الاتصال المشفّر للتواصل بين المشاركين في النصاب. ويمكن ضبط هذه المعلمة على true إذا كان اتصال SSL مطلوبًا للتواصل الداخلي بين العُقد، أو تركها غير محددة بخلاف ذلك. المعلمات الرئيسية لكل <server> هي:
  • id — معرّف الخادم ضمن نصاب.
  • hostname — اسم المضيف الذي يوجد عليه هذا الخادم.
  • port — المنفذ الذي يستمع عليه هذا الخادم للاتصالات.
  • can_become_leader — اضبطه على false لتهيئة الخادم كـ learner. وإذا لم يُذكر، تكون القيمة true.
عند حدوث تغيير في طوبولوجيا عنقود ClickHouse Keeper لديك (مثل استبدال خادم)، احرص على إبقاء التعيين بين server_id وhostname متسقًا، وتجنّب تبديل server_id الحالي بين الخوادم أو إعادة استخدامه لخوادم مختلفة (على سبيل المثال، قد يحدث ذلك إذا كنت تعتمد على نصوص برمجية للأتمتة لنشر ClickHouse Keeper)إذا كان مضيف مثيل Keeper قد يتغير، فنوصي بتعريف اسم مضيف واستخدامه بدلًا من عناوين IP المباشرة. ويُعد تغيير اسم المضيف بمثابة إزالة الخادم ثم إضافته مرة أخرى، وهو ما قد يتعذر في بعض الحالات (مثل عدم توفر عدد كافٍ من مثيلات Keeper لتحقيق نصاب).
تكون async_replication معطلة افتراضيًا لتجنب كسر التوافق مع الإصدارات السابقة. إذا كانت جميع مثيلات Keeper في عنقودك تعمل بإصدار يدعم async_replication ‏(v23.9+)، فنوصي بتمكينها لأنها قد تحسن الأداء من دون أي سلبيات.
يمكن العثور على أمثلة لإعدادات نصاب بثلاث عقد في اختبارات التكامل التي تحمل البادئة test_keeper_. وفيما يلي مثال على إعداد الخادم رقم 1:

كيفية التشغيل

يأتي ClickHouse Keeper مضمّنًا في حزمة ClickHouse server؛ ما عليك سوى إضافة إعدادات <keeper_server> إلى /etc/your_path_to_config/clickhouse-server/config.xml وتشغيل ClickHouse server كالمعتاد. وإذا أردت تشغيل standalone ClickHouse Keeper، فيمكنك تشغيله بطريقة مماثلة باستخدام:
إذا لم يكن لديك الرابط الرمزي (clickhouse-keeper)، يمكنك إنشاؤه أو تحديد keeper كوسيطة لـ clickhouse:

أوامر الكلمات ذات الأحرف الأربعة

يوفّر ClickHouse Keeper أيضًا أوامر 4lw، وهي تكاد تكون مماثلة للأوامر الموجودة في ZooKeeper. يتكوّن كل أمر من أربعة أحرف، مثل mntr وstat وما إلى ذلك. وهناك بعض الأوامر اللافتة الأخرى: يوفّر stat معلومات عامة عن الخادم والعملاء المتصلين، ويقدّم srvr تفاصيل موسّعة عن الخادم، ويقدّم cons تفاصيل موسّعة عن الاتصالات. تتضمن أوامر 4lw إعداد قائمة بيضاء باسم four_letter_word_white_list، وتكون قيمته الافتراضية conf,cons,crst,envi,ruok,srst,srvr,stat,wchs,dirs,mntr,isro,rcvr,apiv,csnp,lgif,rqld,ydld. يمكنك إرسال هذه الأوامر إلى ClickHouse Keeper عبر telnet أو nc، من خلال منفذ العميل.
فيما يلي أوامر 4lw بالتفصيل:
  • ruok: يختبر ما إذا كان الخادم قيد التشغيل وفي حالة سليمة. سيردّ الخادم بـ imok إذا كان قيد التشغيل. وإلا فلن يردّ إطلاقًا. ولا تعني استجابة imok بالضرورة أن الخادم قد انضم إلى النصاب، وإنما تعني فقط أن عملية الخادم نشطة ومرتبطة بمنفذ العميل المحدد. استخدم “stat” للحصول على تفاصيل عن الحالة فيما يتعلق بالنصاب ومعلومات اتصال العميل.
  • mntr: يعرض قائمة بالمتغيرات التي يمكن استخدامها لمراقبة حالة العنقود.
  • srvr: يعرض التفاصيل الكاملة للخادم.
  • stat: يعرض تفاصيل موجزة عن الخادم والعملاء المتصلين.
  • srst: إعادة تعيين إحصاءات الخادم. يؤثر هذا الأمر في نتيجة srvr وmntr وstat.
  • conf: اطبع تفاصيل إعدادات الخدمة.
  • cons: يعرض تفاصيل الاتصال/الجلسة الكاملة لجميع العملاء المتصلين بهذا الخادم. ويتضمن معلومات عن عدد الحزم المستلمة/المرسلة، ومعرّف الجلسة، وزمن استجابة العمليات، وآخر عملية نُفِّذت، إلخ…
  • crst: إعادة ضبط إحصاءات الاتصال/الجلسة لجميع الاتصالات.
  • envi: اطبع تفاصيل بيئة التشغيل
  • dirs: يعرض الحجم الإجمالي لملفات اللقطات وملفات السجل، بالبايت
  • isro: يختبر ما إذا كان الخادم يعمل بوضع القراءة فقط. يستجيب الخادم بـ ro إذا كان في وضع القراءة فقط، أو بـ rw إذا لم يكن كذلك.
  • wchs: يعرض معلومات موجزة عن المراقِبات على الخادم.
  • wchc: يسرد معلومات تفصيلية عن الـ watches على الخادم بحسب الجلسة. ويُخرج هذا قائمة بالجلسات (الاتصالات) مع الـ watches (المسارات) المرتبطة بها. لاحظ أنه، وفقًا لعدد الـ watches، قد تكون هذه العملية مكلفة (وقد تؤثر في أداء الخادم)، لذا استخدمها بحذر.
  • wchp: يسرد معلومات تفصيلية عن عمليات watch على الخادم بحسب المسار. ويعرض هذا الأمر قائمة بالمسارات (znodes) والجلسات المرتبطة بها. لاحظ أنه، وبحسب عدد عمليات watch، قد تكون هذه العملية مكلفة (أي قد تؤثر في أداء الخادم)، لذا استخدمها بحذر.
  • dump: يعرض الجلسات المعلّقة والعُقد المؤقتة. لا يعمل هذا إلا على العقدة القائدة.
  • csnp: جدولة مهمة لإنشاء لقطة. يُرجِع آخر فهرس سجل مُلتزَم للّقطة المُجدولة عند النجاح، أو Failed to schedule snapshot creation task. عند الفشل. ويمكن أن يساعدك الأمر lgif في تحديد ما إذا كانت اللقطة قد اكتملت.
  • lgif: معلومات سجل Keeper. first_log_idx : أول فهرس سجل لديّ في مخزن السجل؛ first_log_term : أول مُدة سجل لديّ؛ last_log_idx : آخر فهرس سجل لديّ في مخزن السجل؛ last_log_term : آخر مُدة سجل لديّ؛ last_committed_log_idx : آخر فهرس سجل مُعتمَد لديّ في آلة الحالات؛ leader_committed_log_idx : فهرس السجل المُعتمَد لدى القائد من وجهة نظري؛ target_committed_log_idx : فهرس السجل المستهدف الذي ينبغي اعتماده؛ last_snapshot_idx : أكبر فهرس سجل مُعتمَد في آخر لقطة.
  • rqld: طلب لتولي دور القائد الجديد. يعيد Sent leadership request to leader. إذا تم إرسال الطلب، أو Failed to send leadership request to leader. إذا تعذر إرسال الطلب. وإذا كانت العقدة هي القائد بالفعل، فستكون النتيجة مماثلة لحالة إرسال الطلب.
  • ftfl: يسرد جميع علامات الميزات وما إذا كانت مفعّلة في مثيل Keeper.
  • ydld: طلب للتنازل عن القيادة والتحول إلى تابع. إذا كان الخادم الذي يستقبل الطلب هو القائد، فسيُوقف عمليات الكتابة مؤقتًا أولًا، ثم ينتظر حتى يُكمل القائد البديل (لا يمكن أبدًا أن يكون القائد الحالي هو القائد البديل) اللحاق بآخر سجل، ثم يتنحى. سيُختار القائد البديل تلقائيًا. يُرجع Sent yield leadership request to leader. إذا تم إرسال الطلب أو Failed to send yield leadership request to leader. إذا تعذر إرسال الطلب. وإذا كانت العقدة تابعًا بالفعل، فستكون النتيجة مماثلة لما يحدث عند إرسال الطلب.
  • pfev: يعرض قيم جميع الأحداث المجمَّعة. ولكل حدث، يعرض اسم الحدث وقيمته ووصفه.

HTTP control

يوفّر ClickHouse Keeper واجهة HTTP للتحقق مما إذا كانت النسخة المتماثلة جاهزة لاستقبال حركة المرور. ويمكن استخدام ذلك في البيئات السحابية، مثل Kubernetes. مثال على تهيئة تفعّل نقطة النهاية /ready:

علامات الميزات

يتوافق Keeper توافقًا كاملًا مع ZooKeeper وعملائه، لكنه يقدّم أيضًا بعض الميزات وأنواع الطلبات الفريدة التي يمكن لعميل ClickHouse استخدامها. ولأن هذه الميزات قد تؤدي إلى تغييرات غير متوافقة مع الإصدارات السابقة، فإن معظمها يكون معطّلًا افتراضيًا، ويمكن تمكينها باستخدام إعداد keeper_server.feature_flags. كما يمكن تعطيل جميع الميزات صراحةً. إذا كنت تريد تمكين ميزة جديدة في عنقود Keeper لديك، فنوصيك أولًا بتحديث جميع مثيلات Keeper في العنقود إلى إصدار يدعم هذه الميزة، ثم تمكين الميزة نفسها. مثال على إعداد لعلامة ميزة يعطّل multi_read ويمكّن check_not_exists:
الميزات التالية متاحة:
بعض علامات الميزات تكون مفعّلة افتراضيًا بدءًا من الإصدار 25.7. والطريقة الموصى بها لترقية Keeper إلى 25.7+ هي الترقية أولًا إلى الإصدار 24.9+.

الترحيل من ZooKeeper

لا يمكن إجراء ترحيل سلس من ZooKeeper إلى ClickHouse Keeper. يجب عليك إيقاف عنقود ZooKeeper، وتحويل البيانات، ثم تشغيل ClickHouse Keeper. تحوّل أداة clickhouse-keeper-converter السجلات ولقطات الخاصة بـ ZooKeeper إلى لقطة لـ ClickHouse Keeper. وتتطلب ZooKeeper 3.4 أو إصدارًا أحدث.

التحضير قبل الترحيل

يتطلّب الترحيل إيقاف استيعاب البيانات. حدّد فترة صيانة قبل البدء. قبل إيقاف ZooKeeper، أوقِف مهام ClickHouse الخلفية التي تعدّل البيانات الوصفية الخاصة بالتنسيق. على سبيل المثال:
سجّل مقاييس المقارنة قبل الترحيل حتى تتمكن من التحقق من الاتساق لاحقًا.

خطوات الترحيل

  1. أوقف استيعاب البيانات إلى جميع عقد ClickHouse.
  2. أوقف جميع المهام التي تعمل في الخلفية على جميع عقد ClickHouse (راجع أعلاه).
  3. أوقف جميع عقد ZooKeeper.
  4. اختياري، لكنه مُوصى به: حدِّد العقدة القائدة في ZooKeeper، ثم شغّلها وأوقفها مرة أخرى. يُجبر ذلك ZooKeeper على كتابة لقطة متسقة على القرص قبل التحويل.
  5. شغّل clickhouse-keeper-converter على العقدة القائدة. إذا كان لديك الملف التنفيذي الكامل لـ ClickHouse مثبّتًا، فاستخدم الأمر الفرعي keeper-converter بدلًا من ذلك (clickhouse keeper-converter). إذا لم يكن أيٌّ منهما متاحًا، نزّل الملف التنفيذي.
  1. انسخ اللقطة إلى جميع عُقد ClickHouse Keeper. يجب أن تكون اللقطة موجودة على كل عقدة قبل بدء أي عقدة — فإذا بدأت عقدة من دون لقطة، فقد تنتخب نفسها قائدًا بحالة فارغة.
  2. حدّث إعدادات ClickHouse لديك لتشير إلى عنقود Keeper الجديد.
  3. ابدأ ClickHouse Keeper على جميع العقد، ثم أعد تشغيل ClickHouse.
  4. قارِن المقاييس بخط الأساس قبل الترحيل للتحقق من الاتساق.
  5. استأنف المهام التي تعمل في الخلفية، وأعد تشغيل استيعاب البيانات.

دمج عدة عناقيد ZooKeeper

إذا كنت تشغّل عدة عناقيد ZooKeeper — على سبيل المثال، مجموعة واحدة لكل مجموعة shard — فيمكنك دمجها في عنقود ClickHouse Keeper واحد. لا تدعم أداة clickhouse-keeper-converter الرسمية سوى التحويلات من واحد إلى واحد (عنقود ZooKeeper واحد إلى لقطة Keeper واحدة)، لذلك يتطلب الدمج تعديل الشيفرة المصدرية للمحوّل لدمج عدة لقطات:
  1. شغّل clickhouse-keeper-converter بشكل منفصل على كل عنقود ZooKeeper، واكتب كل ناتج في دليل منفصل.
  2. ألغِ تسلسل ملفات اللقطات بالتتابع. وعند الدمج، أعد حساب قيم numChildren لتجنّب تعارض معرّفات العقد بين مساحات الأسماء القادمة من عناقيد المصدر المختلفة.
  3. اكتب الناتج المدمج في دليل لقطات ClickHouse Keeper الهدف.

التعامل مع التشفير وقوائم ACL

يدعم ClickHouse Keeper مخططات ACL نفسها التي يدعمها ZooKeeper (world, auth, digest). وتعتمد طريقة التعامل مع قوائم ACL أثناء التحويل على إعداد ZooKeeper لديك:
  • مشفَّر بالكامل أو غير مشفَّر بالكامل: حوِّل مباشرةً. يحافظ المحوِّل على معلومات ACL الحالية.
  • مشفَّر جزئيًا: قبل التحويل، امنح حساب مسؤول فائق الصلاحيات وامسح قوائم ACL باستخدام setAcl -R على المسارات المتأثرة. حوِّل، ثم أعد تمكين التشفير في ClickHouse Keeper إذا لزم الأمر.

التحقق من الترحيل

بعد تشغيل ClickHouse Keeper وإعادة تشغيل ClickHouse، قارن المقاييس الرئيسية لديك بخط الأساس السابق للترحيل للتأكد من نجاح الترحيل. عند دمج عدة عناقيد ZooKeeper، ميّز بين:
  • المسارات المشتركة: المسارات الموجودة في عدة عناقيد مصدر وتحمل البيانات نفسها — يجب إزالة التكرار منها في المخرجات المدمجة.
  • المسارات المتمايزة: المسارات التي لا توجد إلا ضمن عناقيد محددة (على سبيل المثال، تحت /clickhouse/tables لكل مجموعة shard) — يجب الحفاظ عليها من المصدر الصحيح.
تجنّب استعراض أشجار ZooKeeper الكبيرة مباشرةً لأغراض المقارنة. وبدلاً من ذلك، اطبع جميع المسارات المحوّلة إلى ملف أثناء التحويل.

الضبط بعد الترحيل

بعد الترحيل، فكّر في ضبط هذه الإعدادات للمجموعات العنقودية الأكبر أو لتحقيق إنتاجية أعلى: تُضبط هذه الإعدادات ضمن coordination_settings في تهيئة Keeper.

الاستعادة بعد فقدان النصاب

نظرًا لأن ClickHouse Keeper يستخدم Raft، فإنه يستطيع تحمّل عدد معيّن من تعطل العُقد بحسب حجم العنقود. فعلى سبيل المثال، في عنقود مكوّن من 3 عُقد، سيواصل العمل بشكل صحيح إذا تعطلت عقدة واحدة فقط. يمكن إعادة ضبط إعدادات العنقود ديناميكيًا، لكن هناك بعض القيود. تعتمد إعادة التهيئة أيضًا على Raft، لذا فإن إضافة عقدة إلى العنقود أو إزالتها منه تتطلب توفر نصاب. وإذا فقدت عددًا كبيرًا جدًا من العُقد في عنقودك في الوقت نفسه، من دون أي إمكانية لإعادة تشغيلها، فسيتوقف Raft عن العمل ولن يسمح لك بإعادة تهيئة عنقودك بالطريقة المعتادة. ومع ذلك، يوفّر ClickHouse Keeper وضع استعادة يتيح لك فرض إعادة تهيئة عنقودك باستخدام عقدة واحدة فقط. ولا ينبغي اللجوء إلى ذلك إلا كحل أخير إذا تعذّر عليك إعادة تشغيل العُقد، أو تشغيل مثيل جديد على نقطة النهاية نفسها. أمور مهمة يجب الانتباه إليها قبل المتابعة:
  • تأكد من أن العُقد المتعطلة لا يمكنها الاتصال بالعنقود مرة أخرى.
  • لا تبدأ تشغيل أي من العُقد الجديدة حتى يُذكر ذلك صراحةً في الخطوات.
بعد التأكد من صحة ما سبق، عليك القيام بما يلي:
  1. اختر عقدة Keeper واحدة لتكون القائد الجديد. انتبه إلى أن بيانات هذه العقدة ستُستخدم للعنقود بأكمله، لذلك نوصي باستخدام عقدة تحتوي على أحدث حالة ممكنة.
  2. قبل القيام بأي شيء آخر، أنشئ نسخة احتياطية من المجلدين log_storage_path وsnapshot_storage_path في العقدة التي اخترتها.
  3. أعد تهيئة العنقود على جميع العُقد التي تريد استخدامها.
  4. أرسل الأمر المكوّن من أربعة أحرف rcvr إلى العقدة التي اخترتها، مما سينقل العقدة إلى وضع الاستعادة، أو أوقف مثيل Keeper على العقدة المختارة ثم أعد تشغيله باستخدام الوسيط --force-recovery.
  5. شغّل مثيلات Keeper على العُقد الجديدة واحدًا تلو الآخر، مع التأكد من أن mntr يعيد follower في zk_server_state قبل تشغيل العقدة التالية.
  6. أثناء وضع الاستعادة، سترجع عقدة القائد رسالة خطأ للأمر mntr إلى أن تحقق النصاب مع العُقد الجديدة، كما سترفض أي طلبات من العميل ومن الـ التوابع.
  7. بعد تحقيق النصاب، ستعود عقدة القائد إلى وضع التشغيل العادي، وتبدأ في قبول جميع الطلبات باستخدام Raft — ويمكنك التحقق من ذلك عبر mntr، إذ ينبغي أن يعيد leader في zk_server_state.

استخدام الأقراص مع Keeper

يدعم Keeper مجموعة فرعية من الأقراص الخارجية لتخزين اللقطات وملفات السجل وملف الحالة. أنواع الأقراص المدعومة هي:
  • s3_plain
  • s3
  • local
فيما يلي مثال على تعريفات الأقراص الواردة داخل ملف إعداد.
لاستخدام قرص للسجلات، يجب ضبط الإعداد keeper_server.log_storage_disk على اسم القرص. لاستخدام قرص للقطات، يجب ضبط الإعداد keeper_server.snapshot_storage_disk على اسم القرص. بالإضافة إلى ذلك، يمكن استخدام keeper_server.latest_log_storage_disk لأحدث السجلات وkeeper_server.latest_snapshot_storage_disk لأحدث اللقطات. في هذه الحالة، سينقل Keeper الملفات تلقائيًا إلى الأقراص الصحيحة عند إنشاء سجلات أو لقطات جديدة. لاستخدام قرص لملف الحالة، يجب ضبط الإعداد keeper_server.state_storage_disk على اسم القرص. يُعد نقل الملفات بين الأقراص آمنًا، ولا توجد أي مخاطر لفقدان البيانات إذا توقف Keeper في منتصف عملية النقل. وإلى أن يُنقل الملف بالكامل إلى القرص الجديد، فلن يُحذف من القرص القديم. لا يمكن لـ Keeper عند ضبط keeper_server.coordination_settings.force_sync على true (والقيمة الافتراضية هي true) تلبية بعض الضمانات لجميع أنواع الأقراص. في الوقت الحالي، لا تدعم المزامنة الدائمة إلا الأقراص من النوع local. إذا استُخدم force_sync، فيجب أن يكون log_storage_disk قرصًا من النوع local إذا لم يُستخدم latest_log_storage_disk. أما إذا استُخدم latest_log_storage_disk، فيجب أن يكون دائمًا قرصًا من النوع local. إذا كان force_sync معطّلًا، فيمكن استخدام الأقراص من جميع الأنواع في أي إعداد. يمكن أن يبدو إعداد تخزين محتمل لمثيل Keeper كما يلي:
سيخزّن هذا المثيل جميع السجلات ما عدا أحدث السجلات على القرص log_s3_plain، بينما سيُحفَظ أحدث سجل على القرص log_local. وينطبق المنطق نفسه على اللقطات؛ إذ ستُخزَّن جميع اللقطات ما عدا أحدث اللقطات على snapshot_s3_plain، بينما سيُحفَظ أحدث لقطة على القرص snapshot_local.

تغيير إعداد الأقراص

قبل تطبيق إعداد أقراص جديد، خذ نسخة احتياطية يدويًا من جميع سجلات Keeper ولقطاته.
إذا كان قد جرى تعريف إعداد أقراص متدرّج (باستخدام أقراص منفصلة لأحدث الملفات)، فسيحاول Keeper نقل الملفات تلقائيًا إلى الأقراص الصحيحة عند بدء التشغيل. وينطبق الضمان نفسه كما في السابق؛ فإلى أن يُنقَل الملف بالكامل إلى القرص الجديد، لن يُحذَف من القرص القديم، لذا يمكن إجراء عمليات إعادة تشغيل متعددة بأمان. إذا كان من الضروري نقل الملفات إلى قرص جديد بالكامل (أو الانتقال من إعداد ذي قرصين إلى إعداد ذي قرص واحد)، فيمكن استخدام تعريفات متعددة لـ keeper_server.old_snapshot_storage_disk و keeper_server.old_log_storage_disk. يوضح التكوين التالي كيف يمكننا الانتقال من إعداد القرصين السابق إلى إعداد جديد بالكامل ذي قرص واحد:
عند بدء التشغيل، ستُنقل جميع ملفات السجل من log_local وlog_s3_plain إلى القرص log_local2. كما ستُنقل جميع ملفات اللقطات من snapshot_local وsnapshot_s3_plain إلى القرص snapshot_local2.

تهيئة ذاكرة التخزين المؤقت للسجلات

لتقليل كمية البيانات المقروءة من القرص، يخزّن Keeper إدخالات السجل مؤقتًا في الذاكرة. إذا كانت الطلبات كبيرة، فستستهلك إدخالات السجل قدرًا كبيرًا جدًا من الذاكرة، لذلك يُوضَع حدّ لكمية السجلات المخزنة مؤقتًا. يُتحكَّم في هذا الحد باستخدام هذين الإعدادين:
  • latest_logs_cache_size_threshold - الحجم الإجمالي لأحدث السجلات المخزنة في ذاكرة التخزين المؤقت
  • commit_logs_cache_size_threshold - الحجم الإجمالي للسجلات اللاحقة التي يجب تنفيذ commit لها بعد ذلك
إذا كانت القيم الافتراضية كبيرة جدًا، فيمكنك تقليل استخدام الذاكرة عبر تقليل هذين الإعدادين.
يمكنك استخدام الأمر pfev للتحقق من كمية السجلات المقروءة من كل ذاكرة تخزين مؤقت ومن ملف. يمكنك أيضًا استخدام المقاييس من نقطة نهاية Prometheus لتتبّع الحجم الحالي لكِلَا المخزنين المؤقتين.

Prometheus

يمكن لـ Keeper كشف بيانات المقاييس ليتمكّن Prometheus من سحبها. الإعدادات:
  • endpoint – نقطة نهاية HTTP لسحب المقاييس بواسطة خادم Prometheus. ابدأ من ’/’.
  • port – المنفذ الخاص بـ endpoint.
  • metrics – خيار يحدد كشف المقاييس من جدول system.metrics.
  • events – خيار يحدد كشف المقاييس من جدول system.events.
  • asynchronous_metrics – خيار يحدد كشف قيم المقاييس الحالية من جدول system.asynchronous_metrics.
مثال
تحقّق (استبدل 127.0.0.1 بعنوان IP أو اسم المضيف لخادم ClickHouse لديك):
راجع أيضًا تكامل Prometheus في ClickHouse Cloud.

دليل المستخدم لـ ClickHouse Keeper

يوفّر هذا الدليل إعدادات بسيطة ومختصرة لتهيئة ClickHouse Keeper، مع مثال يوضّح كيفية اختبار العمليات الموزعة. يُنفَّذ هذا المثال باستخدام 3 عقد على Linux.

1. تهيئة العقد باستخدام إعدادات Keeper

  1. ثبّت 3 مثيلات ClickHouse على 3 مضيفات (chnode1, chnode2, chnode3). (راجع Quick Start للحصول على تفاصيل حول تثبيت ClickHouse.)
  2. على كل عقدة، أضِف السطر التالي للسماح بالاتصال الخارجي عبر واجهة الشبكة.
  3. أضف إعداد ClickHouse Keeper التالي إلى الخوادم الثلاثة، مع تحديث إعداد <server_id> لكل خادم؛ ففي chnode1 تكون القيمة 1، وفي chnode2 تكون 2، وهكذا.
    فيما يلي الإعدادات الأساسية المستخدمة أعلاه:
  4. فعِّل مكوّن Zookeeper. سيستخدم محرّك ClickHouse Keeper:
    فيما يلي الإعدادات الأساسية المستخدمة أعلاه:
  5. أعد تشغيل ClickHouse وتأكد من أن كل مثيل من Keeper يعمل. نفّذ الأمر التالي على كل خادم. يُرجع الأمر ruok القيمة imok إذا كان Keeper يعمل وبحالة سليمة:
  6. تحتوي قاعدة البيانات system على جدول باسم zookeeper يتضمن تفاصيل مثيلات ClickHouse Keeper لديك. لنعرض هذا الجدول:
    يظهر الجدول كما يلي:

2. تكوين عنقود في ClickHouse

  1. لنُعِدّ عنقود بسيطًا يتكوّن من shardين وبـ نسخة متماثلة واحدة فقط على عقدتين. ستُستخدم العقدة الثالثة لتحقيق quorum المطلوب في ClickHouse Keeper. حدِّث الإعدادات على chnode1 وchnode2. يعرّف الـ عنقود التالي shard واحدة على كل عقدة، ليصبح المجموع shardين من دون replication. في هذا المثال، سيكون بعض البيانات على إحدى العقد وبعضها على العقدة الأخرى:
  2. أعد تشغيل ClickHouse وتحقّق من إنشاء الـ عنقود:
    يجب أن ترى الـ عنقود الخاص بك:

3. إنشاء جدول Distributed واختباره

  1. أنشئ قاعدة بيانات جديدة على الـ عنقود الجديد باستخدام عميل ClickHouse على chnode1. تؤدي عبارة ON CLUSTER إلى إنشاء قاعدة البيانات تلقائيًا على كلتا العقدتين.
  2. أنشئ جدولًا جديدًا في قاعدة البيانات db1. ومرة أخرى، ينشئ ON CLUSTER الجدول على كلتا العقدتين.
  3. على العقدة chnode1، أضف صفّين:
  4. أضف صفّين على العقدة chnode2:
  5. لاحظ أن تشغيل تعليمة SELECT على كل عقدة لا يعرض إلا البيانات الموجودة على تلك العقدة. على سبيل المثال، على chnode1:
    على chnode2:
  6. يمكنك إنشاء جدول Distributed لتمثيل البيانات على الشاردين. الجداول التي تستخدم محرك الجداول Distributed لا تخزّن أي بيانات خاصة بها، لكنها تتيح معالجة الاستعلامات الموزعة عبر عدة خوادم. تصل عمليات القراءة إلى جميع الشاردات، ويمكن توزيع عمليات الكتابة عبرها. شغّل الاستعلام التالي على chnode1:
  7. لاحظ أن الاستعلام عن dist_table يعرض الصفوف الأربعة كلها من الشاردين:

الملخص

يشرح هذا الدليل كيفية إعداد عنقود باستخدام ClickHouse Keeper. وباستخدام ClickHouse Keeper، يمكنك تهيئة العناقيد وتعريف الجداول الموزعة التي يمكن نسخها متماثلًا عبر الشوارد.

تهيئة ClickHouse Keeper بمسارات فريدة

لا تسري هذه الصفحة على ClickHouse Cloud. ويُنفَّذ الإجراء الموضَّح هنا تلقائيًا في خدمات ClickHouse Cloud.

الوصف

تشرح هذه المقالة كيفية استخدام إعداد الماكرو المضمّن {uuid} لإنشاء إدخالات فريدة في ClickHouse Keeper أو ZooKeeper. وتفيد المسارات الفريدة عند إنشاء الجداول وحذفها بشكل متكرر، لأن ذلك يجنّبك الاضطرار إلى الانتظار عدة دقائق حتى يزيل جمع المهملات في Keeper إدخالات المسارات، إذ يُستخدم uuid جديد في ذلك المسار في كل مرة يُنشأ فيها مسار؛ ولا يُعاد استخدام المسارات مطلقًا.

بيئة مثال

عنقود مكوّن من ثلاث عقد سيُهيَّأ بحيث يعمل ClickHouse Keeper على العقد الثلاث جميعها، ويعمل ClickHouse على عقدتين منها. يوفّر هذا لـ ClickHouse Keeper ثلاث عقد (بما في ذلك عقدة فكّ التعادل)، و شارد واحدًا لـ ClickHouse مكوّنًا من نسختين متماثلتين. مثال على إعداد العنقود:

إجراءات إعداد الجداول لاستخدام {uuid}

  1. اضبط وحدات الماكرو على كل خادم مثال على الخادم 1:
لاحظ أننا نعرّف ماكرو لكلٍّ من shard وreplica، لكن {uuid} غير معرّف هنا — فهو مدمج مسبقًا، ولا حاجة إلى تعريفه.
  1. أنشئ قاعدة بيانات
  1. أنشئ جدولًا في العنقود باستخدام وحدات الماكرو و{uuid}
  1. أنشئ جدولًا موزعًا

الاختبار

  1. أدرِج البيانات في العقدة الأولى (مثل chnode1)
  1. أدرِج البيانات في العقدة الثانية (على سبيل المثال، chnode2)
  1. اعرض السجلات باستخدام جدول موزّع

بدائل

يمكن تحديد مسار النسخ المتماثل الافتراضي مسبقًا باستخدام وحدات الماكرو و{uuid} أيضًا
  1. عيّن الإعداد الافتراضي للجداول على كل عقدة
يمكنك أيضًا تعريف الماكرو {database} على كل عقدة إذا كانت العُقد تُستخدم لقواعد بيانات محددة.
  1. أنشئ جدولًا بدون معلمات صريحة:
  1. تحقّق من أنه استخدم الإعدادات نفسها المستخدمة في التهيئة الافتراضية

استكشاف الأخطاء وإصلاحها

مثال لأمر يعرض معلومات الجدول ومعرّف UUID الخاص به:
مثال على أمر للحصول على معلومات عن الجدول في ZooKeeper باستخدام معرّف UUID الخاص بالجدول أعلاه
يجب أن تكون قاعدة البيانات من نوع Atomic، وإذا كنت تُجري الترقية من إصدار سابق، فمن المرجّح أن تكون قاعدة البيانات default من نوع Ordinary.
للتحقّق: على سبيل المثال،

إعادة التهيئة الديناميكية لـ ClickHouse Keeper

لا تسري هذه الصفحة على ClickHouse Cloud. ويُنفَّذ الإجراء الموضَّح هنا تلقائيًا في خدمات ClickHouse Cloud.

الوصف

يدعم ClickHouse Keeper جزئيًا أمر ZooKeeper reconfig لإعادة تهيئة العنقود ديناميكيًا إذا كان keeper_server.enable_reconfiguration مفعّلًا.
إذا كان هذا الإعداد معطّلًا، يمكنك إعادة تهيئة العنقود عبر تعديل قسم raft_configuration الخاص بالنسخة المتماثلة يدويًا. احرص على تعديل الملفات على جميع النسخ المتماثلة، لأن القائد وحده هو الذي سيطبّق التغييرات. وكبديل لذلك، يمكنك إرسال استعلام reconfig عبر أي عميل متوافق مع ZooKeeper.
تحتوي العقدة الافتراضية /keeper/config على آخر تهيئة معتمدة للعنقود بالتنسيق التالي:
مثال:
يمكنك استخدام الأمر reconfig لإضافة خوادم جديدة، وإزالة الخوادم الموجودة، وتغيير أولويات الخوادم الحالية، وفيما يلي أمثلة (باستخدام clickhouse-keeper-client):
وفيما يلي أمثلة على kazoo:
يجب أن تكون الخوادم في joining بتنسيق الخادم الموضّح أعلاه. ويجب فصل مُدخلات الخوادم بفواصل. عند إضافة خوادم جديدة، يمكنك إغفال server_priority (القيمة الافتراضية هي 1) وserver_type (القيمة الافتراضية هي participant). إذا كنت تريد تغيير أولوية خادم موجود، فأضِفه إلى joining مع الأولوية المستهدفة. يجب أن يتطابق مضيف الخادم والمنفذ والنوع مع تهيئة الخادم الحالية. تُضاف الخوادم وتُزال وفقًا لترتيب ظهورها في joining وleaving. تُعالَج جميع التحديثات الواردة من joining قبل التحديثات الواردة من leaving. هناك بعض الملاحظات المهمة المتعلقة بتنفيذ إعادة تهيئة Keeper:
  • لا تُدعَم إلا إعادة التهيئة التدريجية. وتُرفض الطلبات التي تحتوي على new_members غير فارغ. يعتمد تنفيذ ClickHouse Keeper على واجهة برمجة تطبيقات NuRaft لتغيير العضوية ديناميكيًا. ويوفّر NuRaft طريقة لإضافة خادم واحد أو إزالة خادم واحد في كل مرة. وهذا يعني أن كل تغيير في التهيئة (كل جزء من joining، وكل جزء من leaving) يجب البتّ فيه على حدة. لذلك لا تتوفر إعادة تهيئة مجمّعة، لأن ذلك قد يكون مضللًا للمستخدمين النهائيين. كما أن تغيير نوع الخادم (participant/learner) غير ممكن لأنه غير مدعوم من NuRaft، والطريقة الوحيدة لذلك هي إزالة الخادم ثم إضافته من جديد، وهو ما سيكون مضللًا أيضًا.
  • لا يمكنك استخدام القيمة المُعادة znodestat.
  • لا يُستخدم الحقل from_version. وتُرفض جميع الطلبات التي تم تعيين from_version فيها. ويرجع ذلك إلى أن /keeper/config عقدة افتراضية، ما يعني أنها لا تُخزَّن في التخزين الدائم، بل تُولَّد آنيًا باستخدام تهيئة العقدة المحددة لكل طلب. وقد اتُّخذ هذا القرار لتجنّب تكرار البيانات لأن NuRaft يخزّن هذه التهيئة بالفعل.
  • بخلاف ZooKeeper، لا توجد طريقة لانتظار إعادة تهيئة العنقود عبر إرسال أمر sync. سيُطبَّق الضبط الجديد في نهاية المطاف ولكن من دون أي ضمانات زمنية.
  • قد يفشل الأمر reconfig لأسباب مختلفة. يمكنك التحقق من حالة العنقود ومعرفة ما إذا كان التحديث قد طُبِّق.

تحويل Keeper أحادي العقدة إلى عنقود

أحيانًا تكون هناك حاجة إلى توسيع عقدة Keeper تجريبية لتصبح عنقودًا. فيما يلي مخطط يوضح كيفية القيام بذلك خطوة بخطوة لعنقود من 3 عقد:
  • مهم: يجب إضافة العقد الجديدة على دفعات أصغر من النصاب الحالي، وإلا فستنتخب قائدًا من بينها. في هذا المثال، تُضاف العقد واحدة تلو الأخرى.
  • يجب أن تكون قيمة parameter الإعداد keeper_server.enable_reconfiguration مفعّلة على عقدة Keeper الحالية.
  • ابدأ عقدة ثانية باستخدام الإعداد الكامل الجديد لعنقود Keeper.
  • بعد تشغيلها، أضِفها إلى العقدة 1 باستخدام reconfig.
  • الآن، ابدأ عقدة ثالثة وأضِفها باستخدام reconfig.
  • حدِّث إعداد clickhouse-server بإضافة عقدة Keeper الجديدة إليه، ثم أعد تشغيله لتطبيق التغييرات.
  • حدِّث إعداد raft للعقدة 1، وأعد تشغيلها اختياريًا.
ولفهم العملية عمليًا بشكل أفضل، إليك sandbox repository.

الميزات غير المدعومة

مع أن ClickHouse Keeper يهدف إلى تحقيق توافق كامل مع ZooKeeper، فلا تزال هناك بعض الميزات غير المُنفَّذة حتى الآن (مع استمرار العمل على تطويرها):
آخر تعديل في ٢٥ يونيو ٢٠٢٦