لا تسري هذه الصفحة على ClickHouse Cloud. ويُنفَّذ الإجراء الموضَّح هنا تلقائيًا في خدمات ClickHouse Cloud.
تفاصيل التنفيذ
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.
عمليات التكامل الخارجية غير مدعومة.
التهيئة
.xml متطابقة تقريبًا.
إعدادات تهيئة 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:
كيفية التشغيل
<keeper_server> إلى /etc/your_path_to_config/clickhouse-server/config.xml وتشغيل ClickHouse server كالمعتاد. وإذا أردت تشغيل standalone ClickHouse Keeper، فيمكنك تشغيله بطريقة مماثلة باستخدام:
clickhouse-keeper)، يمكنك إنشاؤه أو تحديد keeper كوسيطة لـ clickhouse:
أوامر الكلمات ذات الأحرف الأربعة
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، من خلال منفذ العميل.
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
/ready:
علامات الميزات
keeper_server.feature_flags.
كما يمكن تعطيل جميع الميزات صراحةً.
إذا كنت تريد تمكين ميزة جديدة في عنقود Keeper لديك، فنوصيك أولًا بتحديث جميع مثيلات Keeper في العنقود إلى إصدار يدعم هذه الميزة، ثم تمكين الميزة نفسها.
مثال على إعداد لعلامة ميزة يعطّل multi_read ويمكّن check_not_exists:
بعض علامات الميزات تكون مفعّلة افتراضيًا بدءًا من الإصدار 25.7.
والطريقة الموصى بها لترقية Keeper إلى 25.7+ هي الترقية أولًا إلى الإصدار 24.9+.
الترحيل من ZooKeeper
clickhouse-keeper-converter السجلات ولقطات الخاصة بـ ZooKeeper إلى لقطة لـ ClickHouse Keeper. وتتطلب ZooKeeper 3.4 أو إصدارًا أحدث.
التحضير قبل الترحيل
خطوات الترحيل
- أوقف استيعاب البيانات إلى جميع عقد ClickHouse.
- أوقف جميع المهام التي تعمل في الخلفية على جميع عقد ClickHouse (راجع أعلاه).
- أوقف جميع عقد ZooKeeper.
- اختياري، لكنه مُوصى به: حدِّد العقدة القائدة في ZooKeeper، ثم شغّلها وأوقفها مرة أخرى. يُجبر ذلك ZooKeeper على كتابة لقطة متسقة على القرص قبل التحويل.
-
شغّل
clickhouse-keeper-converterعلى العقدة القائدة. إذا كان لديك الملف التنفيذي الكامل لـ ClickHouse مثبّتًا، فاستخدم الأمر الفرعيkeeper-converterبدلًا من ذلك (clickhouse keeper-converter). إذا لم يكن أيٌّ منهما متاحًا، نزّل الملف التنفيذي.
- انسخ اللقطة إلى جميع عُقد ClickHouse Keeper. يجب أن تكون اللقطة موجودة على كل عقدة قبل بدء أي عقدة — فإذا بدأت عقدة من دون لقطة، فقد تنتخب نفسها قائدًا بحالة فارغة.
- حدّث إعدادات ClickHouse لديك لتشير إلى عنقود Keeper الجديد.
- ابدأ ClickHouse Keeper على جميع العقد، ثم أعد تشغيل ClickHouse.
- قارِن المقاييس بخط الأساس قبل الترحيل للتحقق من الاتساق.
- استأنف المهام التي تعمل في الخلفية، وأعد تشغيل استيعاب البيانات.
دمج عدة عناقيد ZooKeeper
clickhouse-keeper-converter الرسمية سوى التحويلات من واحد إلى واحد (عنقود ZooKeeper واحد إلى لقطة Keeper واحدة)، لذلك يتطلب الدمج تعديل الشيفرة المصدرية للمحوّل لدمج عدة لقطات:
- شغّل
clickhouse-keeper-converterبشكل منفصل على كل عنقود ZooKeeper، واكتب كل ناتج في دليل منفصل. - ألغِ تسلسل ملفات اللقطات بالتتابع. وعند الدمج، أعد حساب قيم
numChildrenلتجنّب تعارض معرّفات العقد بين مساحات الأسماء القادمة من عناقيد المصدر المختلفة. - اكتب الناتج المدمج في دليل لقطات ClickHouse Keeper الهدف.
التعامل مع التشفير وقوائم ACL
world, auth, digest). وتعتمد طريقة التعامل مع قوائم ACL أثناء التحويل على إعداد ZooKeeper لديك:
- مشفَّر بالكامل أو غير مشفَّر بالكامل: حوِّل مباشرةً. يحافظ المحوِّل على معلومات ACL الحالية.
- مشفَّر جزئيًا: قبل التحويل، امنح حساب مسؤول فائق الصلاحيات وامسح قوائم ACL باستخدام
setAcl -Rعلى المسارات المتأثرة. حوِّل، ثم أعد تمكين التشفير في ClickHouse Keeper إذا لزم الأمر.
التحقق من الترحيل
- المسارات المشتركة: المسارات الموجودة في عدة عناقيد مصدر وتحمل البيانات نفسها — يجب إزالة التكرار منها في المخرجات المدمجة.
- المسارات المتمايزة: المسارات التي لا توجد إلا ضمن عناقيد محددة (على سبيل المثال، تحت
/clickhouse/tablesلكل مجموعة shard) — يجب الحفاظ عليها من المصدر الصحيح.
الضبط بعد الترحيل
تُضبط هذه الإعدادات ضمن
coordination_settings في تهيئة Keeper.
الاستعادة بعد فقدان النصاب
- تأكد من أن العُقد المتعطلة لا يمكنها الاتصال بالعنقود مرة أخرى.
- لا تبدأ تشغيل أي من العُقد الجديدة حتى يُذكر ذلك صراحةً في الخطوات.
- اختر عقدة Keeper واحدة لتكون القائد الجديد. انتبه إلى أن بيانات هذه العقدة ستُستخدم للعنقود بأكمله، لذلك نوصي باستخدام عقدة تحتوي على أحدث حالة ممكنة.
- قبل القيام بأي شيء آخر، أنشئ نسخة احتياطية من المجلدين
log_storage_pathوsnapshot_storage_pathفي العقدة التي اخترتها. - أعد تهيئة العنقود على جميع العُقد التي تريد استخدامها.
- أرسل الأمر المكوّن من أربعة أحرف
rcvrإلى العقدة التي اخترتها، مما سينقل العقدة إلى وضع الاستعادة، أو أوقف مثيل Keeper على العقدة المختارة ثم أعد تشغيله باستخدام الوسيط--force-recovery. - شغّل مثيلات Keeper على العُقد الجديدة واحدًا تلو الآخر، مع التأكد من أن
mntrيعيدfollowerفيzk_server_stateقبل تشغيل العقدة التالية. - أثناء وضع الاستعادة، سترجع عقدة القائد رسالة خطأ للأمر
mntrإلى أن تحقق النصاب مع العُقد الجديدة، كما سترفض أي طلبات من العميل ومن الـ التوابع. - بعد تحقيق النصاب، ستعود عقدة القائد إلى وضع التشغيل العادي، وتبدأ في قبول جميع الطلبات باستخدام Raft — ويمكنك التحقق من ذلك عبر
mntr، إذ ينبغي أن يعيدleaderفيzk_server_state.
استخدام الأقراص مع 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_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.
تهيئة ذاكرة التخزين المؤقت للسجلات
latest_logs_cache_size_threshold- الحجم الإجمالي لأحدث السجلات المخزنة في ذاكرة التخزين المؤقتcommit_logs_cache_size_threshold- الحجم الإجمالي للسجلات اللاحقة التي يجب تنفيذ commit لها بعد ذلك
يمكنك استخدام الأمر
pfev للتحقق من كمية السجلات المقروءة من كل ذاكرة تخزين مؤقت ومن ملف.
يمكنك أيضًا استخدام المقاييس من نقطة نهاية Prometheus لتتبّع الحجم الحالي لكِلَا المخزنين المؤقتين.Prometheus
endpoint– نقطة نهاية HTTP لسحب المقاييس بواسطة خادم Prometheus. ابدأ من ’/’.port– المنفذ الخاص بـendpoint.metrics– خيار يحدد كشف المقاييس من جدول system.metrics.events– خيار يحدد كشف المقاييس من جدول system.events.asynchronous_metrics– خيار يحدد كشف قيم المقاييس الحالية من جدول system.asynchronous_metrics.
127.0.0.1 بعنوان IP أو اسم المضيف لخادم ClickHouse لديك):
دليل المستخدم لـ ClickHouse Keeper
1. تهيئة العقد باستخدام إعدادات Keeper
-
ثبّت 3 مثيلات ClickHouse على 3 مضيفات (
chnode1,chnode2,chnode3). (راجع Quick Start للحصول على تفاصيل حول تثبيت ClickHouse.) -
على كل عقدة، أضِف السطر التالي للسماح بالاتصال الخارجي عبر واجهة الشبكة.
-
أضف إعداد ClickHouse Keeper التالي إلى الخوادم الثلاثة، مع تحديث إعداد
<server_id>لكل خادم؛ ففيchnode1تكون القيمة1، وفيchnode2تكون2، وهكذا.فيما يلي الإعدادات الأساسية المستخدمة أعلاه: -
فعِّل مكوّن Zookeeper. سيستخدم محرّك ClickHouse Keeper:
فيما يلي الإعدادات الأساسية المستخدمة أعلاه:
-
أعد تشغيل ClickHouse وتأكد من أن كل مثيل من Keeper يعمل. نفّذ الأمر التالي على كل خادم. يُرجع الأمر
ruokالقيمةimokإذا كان Keeper يعمل وبحالة سليمة: -
تحتوي قاعدة البيانات
systemعلى جدول باسمzookeeperيتضمن تفاصيل مثيلات ClickHouse Keeper لديك. لنعرض هذا الجدول:يظهر الجدول كما يلي:
2. تكوين عنقود في ClickHouse
-
لنُعِدّ عنقود بسيطًا يتكوّن من shardين وبـ نسخة متماثلة واحدة فقط على عقدتين. ستُستخدم العقدة الثالثة لتحقيق quorum المطلوب في ClickHouse Keeper. حدِّث الإعدادات على
chnode1وchnode2. يعرّف الـ عنقود التالي shard واحدة على كل عقدة، ليصبح المجموع shardين من دون replication. في هذا المثال، سيكون بعض البيانات على إحدى العقد وبعضها على العقدة الأخرى: -
أعد تشغيل ClickHouse وتحقّق من إنشاء الـ عنقود:
يجب أن ترى الـ عنقود الخاص بك:
3. إنشاء جدول Distributed واختباره
-
أنشئ قاعدة بيانات جديدة على الـ عنقود الجديد باستخدام عميل ClickHouse على
chnode1. تؤدي عبارةON CLUSTERإلى إنشاء قاعدة البيانات تلقائيًا على كلتا العقدتين. -
أنشئ جدولًا جديدًا في قاعدة البيانات
db1. ومرة أخرى، ينشئON CLUSTERالجدول على كلتا العقدتين. -
على العقدة
chnode1، أضف صفّين: -
أضف صفّين على العقدة
chnode2: -
لاحظ أن تشغيل تعليمة
SELECTعلى كل عقدة لا يعرض إلا البيانات الموجودة على تلك العقدة. على سبيل المثال، علىchnode1:علىchnode2: -
-
يمكنك إنشاء جدول
Distributedلتمثيل البيانات على الشاردين. الجداول التي تستخدم محرك الجداولDistributedلا تخزّن أي بيانات خاصة بها، لكنها تتيح معالجة الاستعلامات الموزعة عبر عدة خوادم. تصل عمليات القراءة إلى جميع الشاردات، ويمكن توزيع عمليات الكتابة عبرها. شغّل الاستعلام التالي علىchnode1: -
لاحظ أن الاستعلام عن
dist_tableيعرض الصفوف الأربعة كلها من الشاردين:
الملخص
تهيئة ClickHouse Keeper بمسارات فريدة
لا تسري هذه الصفحة على ClickHouse Cloud. ويُنفَّذ الإجراء الموضَّح هنا تلقائيًا في خدمات ClickHouse Cloud.
الوصف
{uuid}
لإنشاء إدخالات فريدة في ClickHouse Keeper أو ZooKeeper. وتفيد
المسارات الفريدة عند إنشاء الجداول وحذفها بشكل متكرر، لأن
ذلك يجنّبك الاضطرار إلى الانتظار عدة دقائق حتى يزيل جمع المهملات في Keeper
إدخالات المسارات، إذ يُستخدم uuid جديد في ذلك المسار
في كل مرة يُنشأ فيها مسار؛ ولا يُعاد استخدام المسارات مطلقًا.
بيئة مثال
مثال على إعداد العنقود:
إجراءات إعداد الجداول لاستخدام {uuid}
- اضبط وحدات الماكرو على كل خادم مثال على الخادم 1:
لاحظ أننا نعرّف ماكرو لكلٍّ من
shard وreplica، لكن {uuid} غير معرّف هنا — فهو مدمج مسبقًا، ولا حاجة إلى تعريفه.- أنشئ قاعدة بيانات
- أنشئ جدولًا في العنقود باستخدام وحدات الماكرو و
{uuid}
- أنشئ جدولًا موزعًا
الاختبار
- أدرِج البيانات في العقدة الأولى (مثل
chnode1)
- أدرِج البيانات في العقدة الثانية (على سبيل المثال،
chnode2)
- اعرض السجلات باستخدام جدول موزّع
بدائل
{uuid} أيضًا
- عيّن الإعداد الافتراضي للجداول على كل عقدة
- أنشئ جدولًا بدون معلمات صريحة:
- تحقّق من أنه استخدم الإعدادات نفسها المستخدمة في التهيئة الافتراضية
استكشاف الأخطاء وإصلاحها
يجب أن تكون قاعدة البيانات من نوع
Atomic، وإذا كنت تُجري الترقية من إصدار سابق، فمن
المرجّح أن تكون قاعدة البيانات default من نوع Ordinary.إعادة التهيئة الديناميكية لـ ClickHouse Keeper
لا تسري هذه الصفحة على ClickHouse Cloud. ويُنفَّذ الإجراء الموضَّح هنا تلقائيًا في خدمات ClickHouse Cloud.
الوصف
reconfig
لإعادة تهيئة العنقود ديناميكيًا إذا كان keeper_server.enable_reconfiguration مفعّلًا.
إذا كان هذا الإعداد معطّلًا، يمكنك إعادة تهيئة العنقود عبر تعديل قسم
raft_configuration
الخاص بالنسخة المتماثلة يدويًا. احرص على تعديل الملفات على جميع النسخ المتماثلة، لأن القائد وحده هو الذي سيطبّق التغييرات.
وكبديل لذلك، يمكنك إرسال استعلام reconfig عبر أي عميل متوافق مع ZooKeeper./keeper/config على آخر تهيئة معتمدة للعنقود بالتنسيق التالي:
- يُفصل كل إدخال خادم بسطر جديد.
- تكون قيمة
server_typeإماparticipantأوlearner(learner لا يشارك في انتخابات القائد). server_priorityهو عدد صحيح غير سالب يحدد العُقد التي ينبغي إعطاؤها أولوية في انتخابات القائد. وتعني الأولوية 0 أن الخادم لن يكون القائد مطلقًا.
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 أحادي العقدة إلى عنقود
- مهم: يجب إضافة العقد الجديدة على دفعات أصغر من النصاب الحالي، وإلا فستنتخب قائدًا من بينها. في هذا المثال، تُضاف العقد واحدة تلو الأخرى.
- يجب أن تكون قيمة parameter الإعداد
keeper_server.enable_reconfigurationمفعّلة على عقدة Keeper الحالية. - ابدأ عقدة ثانية باستخدام الإعداد الكامل الجديد لعنقود Keeper.
- بعد تشغيلها، أضِفها إلى العقدة 1 باستخدام
reconfig. - الآن، ابدأ عقدة ثالثة وأضِفها باستخدام
reconfig. - حدِّث إعداد
clickhouse-serverبإضافة عقدة Keeper الجديدة إليه، ثم أعد تشغيله لتطبيق التغييرات. - حدِّث إعداد raft للعقدة 1، وأعد تشغيلها اختياريًا.
الميزات غير المدعومة
createلا يدعم إرجاع الكائنStatcreateلا يدعم TTLaddWatchلا يعمل مع watches من النوعPERSISTENTremoveWatchوremoveAllWatchesغير مدعومينsetWatchesغير مدعوم- لا يدعم إنشاء znodes من النوع
CONTAINER SASL authenticationغير مدعوم