إعداد ClickHouseCluster
الإعداد الأساسي
النسخ المتماثلة والشظايا
- النسخ المتماثلة: عدد مثيلات ClickHouse لكل شظية (لتحقيق التوفّر العالي)
- الشظايا: عدد التقسيمات الأفقية (لأغراض التوسّع)
replicas: 3 وshards: 2 ما مجموعه 6 كبسولات لـ ClickHouse.
تكامل Keeper
يحتاج كل عنقود ClickHouse إلى مجموعة عُقد Keeper من أجل التنسيق. عيّن حقلًا واحدًا فقط من الحقلينkeeperClusterRef وexternalKeeper؛ إذ يُرفض العنقود الذي يعيّن كليهما أو لا يعيّن أيًّا منهما.
اجعل keeperClusterRef يشير إلى KeeperCluster يديره هذا المشغِّل:
keeperClusterRef.namespace، يجب على المشغِّل مراقبة مساحتي الاسم كلتيهما. وإذا كان WATCH_NAMESPACE مُعدًّا، فأدرِج مساحتي الاسم الخاصتين بـ ClickHouse وKeeper في تلك القائمة.
Keeper المُدار خارجيًا
استخدمexternalKeeper لتشغيل ClickHouse مع مجموعة Keeper لا يديرها المشغّل —
سواء كانت تابعة لمشغّل آخر، أو تعمل في عنقود Kubernetes مختلف، أو على أجهزة افتراضية أو
خوادم فعلية (bare metal)، أو مشتركة بين عدة أنظمة:
port هي 9181. أما host فهو اسم DNS أو عنوان IP، مع وضع عناوين IPv6 بين أقواس
مربعة. اضبط tls: Enabled للاتصال عبر TLS، واجعل قيمة port هي المنفذ الذي تستمع عليه مجموعة Keeper
للاتصالات الآمنة:
caBundle
تقوم بتهيئته. راجع الاتصال بين ClickHouse وKeeper عبر TLS.
عندما تتشارك عدة عناقيد ClickHouse مجموعة Keeper واحدة، خصّص لكلٍّ منها znode جذرية مستقلة عبر
settings.extraConfig، كي لا تتداخل البيانات الوصفية الخاصة بالـ replication والمستخدمون المعرّفون بلغة SQL والمجموعات المسمّاة (named collections)
فيما بينها. أنشئ الـ znode قبل بدء تشغيل ClickHouse، ولا تغيّرها بعد ذلك:
zookeeper.root في settings.extraReloadableConfig، إذ إن إعادة التحميل ستُبدّل جذر عنقود قيد التشغيل
وتترك جداوله المتماثلة في وضع القراءة فقط. وإذا كانت لعقدة znode الجذرية قوائم تحكم في الوصول (ACLs)، فيجب أن تسمح
لـ keeper-identity الخاصة بالعنقود بإنشاء عقد znode فرعية.
لا يُجري المشغّل أي تغييرات على هذه الخوادم، ولا ينتظر جاهزيتها قبل إجراء التسوية لـ ClickHouse.
وتقع مسؤولية الحفاظ على إتاحة مجموعة Keeper على عاتق المستخدم.
تعمل المصادقة بالطريقة نفسها المتّبعة مع Keeper الذي يديره المشغّل؛ إذ يقرأ المشغّل
المفتاح keeper-identity من Secret الخاص بالعنقود ويمرّره إلى ClickHouse. راجع
External Secret للاطلاع على بنية Secret.
إعداد KeeperCluster
تسليم القيادة عند الإنهاء
تتضمن حاوية Keeper خطافpreStop افتراضيًا يطلب من النسخة المتماثلة التخلي عن قيادة Raft
قبل توقفها، وينتظر اكتمال التسليم قبل السماح
بإنهاء الحاوية. يُنفَّذ هذا الخطاف عند كل إيقاف سلس للحاوية، لا عند
عمليات الطرح التي يبدؤها المشغّل فحسب: فإخلاء الحاوية بواسطة descheduler، أو تفريغ العقدة، أو أي إجراء
يتخذه مُوسّع تلقائي، كلها تُطلق الخطاف نفسه، لأنه معالج preStop على مستوى kubelet وليس
منطقًا ضمن حلقة التسوية (reconcile loop).
ومن دون هذا الخطاف، تؤدي إعادة تشغيل القائد الحالي إلى بقاء مجموعة Keeper بلا قائد إلى أن
يكتمل انتخاب قائد جديد، وقد يستغرق ذلك عدة ثوانٍ تحت الحمل، فيظهر لـ
ClickHouse في صورة فقدان للاتصال بـ Keeper وارتفاع في زمن استجابة الاستعلامات. يطلب الخطاف من
النسخة المتماثلة التنازل عن القيادة (عبر أمر Keeper رباعي الأحرف ydld، المُرسَل من خلال
منفذ http_control)، ثم يستطلع حالة النسخة المتماثلة إلى أن تكفّ عن كونها
القائد، بدلًا من إرسال الطلب والسماح للحاوية بالتوقف فورًا؛ ذلك أن
الطلب المُرسَل دون انتظار تأكيد (fire-and-forget) قد يخسر السباق مع SIGTERM تحت حمل الكتابة، ومن ثَمّ فإن
الانتظار هو ما يضمن بقاء الفترة الخالية من القائد محدودة.
لا يحتاج الخطاف إلى أي تهيئة، ولا يتسبب في أي خلل عند عدم دعمه: ففي إصدارات Keeper الأقدم من
26.3، التي لا تدعم بعدُ أوامر القيادة المستخدمة هنا، لا يكون للطلب أي أثر،
وتتوقف الحاوية كما لو لم يكن الخطاف موجودًا. ولأن الخطاف يُشغّل برنامجًا نصيًا لـ shell، فإنه يتطلب وجود
bash في الصورة؛ فإذا كنت تستخدم صورة Keeper من نوع distroless أو scratch، فتجاوزه أو أزِله
عبر containerTemplate.lifecycle — راجع
مرجع واجهة برمجة التطبيقات.
تهيئة التخزين
dataVolumeClaimSpec، وهو
PersistentVolumeClaimSpec قياسي في Kubernetes. يحوّله المُشغِّل إلى PersistentVolumeClaim لكل نسخة متماثلة
يتم ربطه على مسار البيانات /var/lib/clickhouse:
لا يمكن للمُشغِّل تعديل PVC موجود إلا إذا كانت StorageClass الأساسية تدعم توسيع وحدة التخزين.
نطاق العنقود
spec.clusterDomain لاحقة DNS في Kubernetes التي يستخدمها المشغِّل عند إنشاء
أسماء المضيفين المؤهلة بالكامل للكبسولات التي يكتبها في
إعدادات خادم ClickHouse. وتكون القيمة الافتراضية هي cluster.local، وهو موجود في كلٍّ من
ClickHouseCluster وKeeperCluster.
<cluster-name>-clickhouse-headless لتخدم حركة مرور العملاء.
كما ينشئ خدمات لكل نسخة متماثلة باسم <cluster-name>-clickhouse-internal-<shard>-<index> تنشر الكبسولات غير الجاهزة لحركة المرور الداخلية
وطلبات الإدارة من المشغِّل. يمكن استخدامها لاستعادة النسخة المتماثلة إذا لم تتمكن من أن تصبح جاهزة بنفسها.
تستخدم عقد Keeper أسماء الكبسولات عبر خدمتها عديمة الرأس: <pod>.<headless-service>.<namespace>.svc.<clusterDomain>.
لا تُجرِ override لهذا إلا إذا كان
kubelet في عنقودك يعمل باستخدام --cluster-domain
مختلف عن cluster.local. إذا لم تتطابق القيمة مع نطاق العنقود الفعلي،
فلن يتمكن ClickHouse من حل أسماء مضيفات Keeper والنسخ المتماثلة، مما يؤدي إلى فشل التنسيق
واستعلامات Distributed مع ظهور أخطاء في حل أسماء DNS. اضبط القيمة نفسها على
ClickHouseCluster وKeeperCluster الذي يشير إليه.إعدادات الكبسولة
التوزيع الطوبولوجي والتقارب التلقائيان
وزّع pod عبر مناطق التوافر:تأكد من أن عنقود Kubernetes لديك يضم عددًا كافيًا من العقد عبر مناطق مختلفة لاستيفاء قيود التوزيع.
topologyMinDomains على عدد مناطق التوافر لفرض التوزيع:
يتطلب
topologyMinDomains وجود topologyZoneKey. تبقى pod في حالة Pending ما دام عدد المناطق المتاحة أقل من المطلوب، لذا أبقِ القيمة ضمن المناطق التي يستطيع عنقودك توفيرها.الإعداد اليدوي
راجع مرجع واجهة برمجة التطبيقات للاطلاع على جميع الخيارات المدعومة لقوالب الـ Pod.
ميزانيات تعطيل الكبسولات
القيم الافتراضية
apply الجديدة بالفعل حماية من فقدان النصاب بالخطأ.
بالنسبة إلى ClickHouseCluster مكوّن من 3 شظايا مع
replicas: 3، ينشئ المشغّل ثلاثة PDBs، واحداً لكل شظية، بحيث يكون لكل منها minAvailable: 1.
تجاوز القيم الافتراضية
spec.podDisruptionBudget لتجاوز minAvailable أو maxUnavailable (واحد منهما فقط):
maxUnavailable، مع نسبة مئوية:
unhealthyPodEvictionPolicy إلى PDB الذي يتم إنشاؤه — ويكون ذلك مفيدًا عندما تحتاج إلى السماح بإخلاء الكبسولات التي لا تزال في حالة NotReady:
السياسات
spec.podDisruptionBudget.policy اختيار مدى صرامة إدارة المشغّل لـ PDBs:
مثال — عطّل إدارة PDB بالكامل على عنقود تطوير:
التعطيل على مستوى العنقود بالكامل
ENABLE_PDB الخاص بالمشغّل. عند ضبط ENABLE_PDB=false، يتجاوز المشغّل خطوة التسوية الخاصة بـ PDB لكل ClickHouseCluster وKeeperCluster، بغض النظر عن spec.podDisruptionBudget.policy الخاصة بهما، ولا يراقب موارد PodDisruptionBudget مطلقًا. لذلك، لا يحتاج ServiceAccount الخاص بالمشغّل إلى أذونات RBAC على poddisruptionbudgets.policy/v1، وهو ما يفيد عند تشغيل المشغّل باستخدام ServiceAccount مقيّد يستبعد تلك الأذونات عمدًا.
تكوين الحاوية
صورة حاوية مخصّصة
موارد الحاويات
متغيرات البيئة
ربط وحدات التخزين
يُسمح بتحديد عدة عمليات ربط لوحدات التخزين إلى
mountPath نفسه.
سينشئ المشغّل وحدة تخزين من نوع projected تضم جميع عمليات الربط المحددة.مجسّات الصحة
يهيّئ المشغّل مجسّات الحيوية (liveness) والجاهزية (readiness) على كل حاوية من حاويات ClickHouse وKeeper. لا يُضبط أي مجسّ بدء تشغيل (startup) افتراضيًا.
يستخدم ClickHouse وKeeper إعدادات التوقيت الافتراضية نفسها:
يفتح ClickHouse مستمع الاتصال بين الخوادم قبل تحميل الجداول، ثم يفتح مستمعات العملاء بعد ذلك؛ ولهذا يتحمّل مجسّ الحيوية بطء تحميل الجداول، في حين يدلّ نجاح مجسّ الجاهزية على أن النسخة المتماثلة أصبحت جاهزة لخدمة الاستعلامات.
يمكنك تجاوز إعدادات أي مجسّ عبر
spec.containerTemplate في أيٍّ من الموردين. على سبيل المثال، لتخصيص مجسّ الحيوية في ClickHouse:
مجسّ بدء التشغيل
استخدمstartupProbe عندما تحتاج الحاوية إلى وقت للبدء أطول مما يسمح به مجسّ الحيوية، وهو بالإعدادات الافتراضية نحو 60 ثانية من التأخير الأولي، تليها 10 فحوصات فاشلة يفصل بين كل منها 5 ثوانٍ.
يؤجّل Kubernetes تشغيل مجسّي الحيوية والجاهزية إلى أن ينجح مجسّ بدء التشغيل، فلا يؤدي البدء البطيء إلى الدخول في حلقة متكررة من إعادة التشغيل.
على سبيل المثال، امنح نسخة متماثلة من Keeper تعيد تطبيق لقطة كبيرة مهلةً تصل إلى 10 دقائق لتبدأ في قبول الاتصالات:
راجع مرجع واجهة برمجة التطبيقات للاطلاع على جميع خيارات قوالب الحاويات المدعومة.
إعدادات TLS/SSL
تهيئة نقاط نهاية آمنة
تنسيق Secret الخاص بشهادة SSL
tls.crt- شهادة الخادم بترميز PEMtls.key- المفتاح الخاص بترميز PEM
يتوافق هذا التنسيق مع الشهادات التي يُنشئها cert-manager.
اتصال ClickHouse-Keeper عبر TLS
إذا كان TLS مفعّلًا في KeeperCluster المُشار إليه عبرkeeperClusterRef، فسيستخدم ClickHouseCluster اتصالًا آمنًا بعُقد Keeper تلقائيًا.
أما عند استخدام externalKeeper، فاضبط tls: Enabled بدلًا من ذلك، واضبط port لكل عقدة على منفذ العميل الآمن لمجموعة Keeper (على سبيل المثال 9281).
يتحقق ClickHouseCluster من شهادات عُقد Keeper باستخدام مخزن الثقة في النظام، بالإضافة إلى أي caBundle تقوم بتهيئته.
للثقة في CA خاصة (على سبيل المثال، CA موقعة ذاتيًا أو داخلية)، قدّم مرجعًا إلى حزمة CA مخصصة:
External Secret
spec.externalSecret:
يجب أن يكون كائن Secret المشار إليه موجودًا في مساحة الاسم نفسها الخاصة بـ ClickHouseCluster. ولا يحذف المُشغِّل مطلقًا أي كائن Secret لم يُنشئه.
المفاتيح المطلوبة
يكون Secret الكامل كما يلي:
السياسة: المراقبة مقابل الإدارة
spec.externalSecret.policy في كيفية تعامل المشغّل مع المفاتيح المطلوبة الناقصة:
حتى مع
policy: Manage يجب أن يكون كائن Secret موجودًا بالفعل في مساحة الاسم — فالمشغّل لا ينشئ كائن Secret نفسه مطلقًا، بل يكتب فقط المفاتيح المُولَّدة إلى كائن موجود. وإذا كان كائن Secret المُشار إليه غير موجود، فتُعلَّق التسوية بسبب ExternalSecretNotFound بغض النظر عن السياسة.Observe عندما يكون النظام الخارجي (Vault أو ESO أو sealed-secrets أو GitOps) هو مصدر الحقيقة وتريد أن يُخفق المشغّل بوضوح عند وجود خطأ في الإعداد. واختر Manage عندما تريد تهيئة أولية مكتفية ذاتيًا، مع الاحتفاظ بملكية كائن Secret نفسه (على سبيل المثال، لأخذ نسخة احتياطية منه).
شرط الحالة واستكشاف الأخطاء وإصلاحها
ExternalSecretValid ضمن ClickHouseCluster.status.conditions. افحصه عندما يبدو أن عملية التسوية عالقة:
يعيد المشغّل إدراج عملية التسوية في قائمة الانتظار ما دام كائن Secret غير صالح، لذا بمجرد إضافة المفاتيح المفقودة ستلتقطها عملية التسوية التالية تلقائيًا — ولا حاجة إلى إعادة تشغيل الـ pods.
تعتمد مجموعة المفاتيح المطلوبة على إصدار ClickHouse المستخدم حاليًا. لا يتم التحقق من
named-collections-key إلا بعد أن يكتشف فحص الإصدار الخاص بالمشغّل ClickHouse 25.12 أو أحدث. في الإصدارات الأقدم، قد لا يكون هذا المفتاح موجودًا في كائن Secret. ويكون disk-encryption-key مطلوبًا فقط عند تعيين spec.settings.encryption.منافذ إضافية
8123 لـ HTTP، و9000 لـ أصلي، و9009 للاتصال بين الخوادم، و9001/9002 للإدارة، و9363 لمقاييس Prometheus، بالإضافة إلى منافذ TLS البديلة 8443/9440 عند تمكين TLS. كما تُكشف منافذ interserver والإدارة عبر الخدمات الداخلية لكل نسخة متماثلة، بحيث تتمكن النسخ المتماثلة والمشغّل من التواصل قبل أن تصبح النسخة المتماثلة جاهزة. لجعل ClickHouse يستمع إلى بروتوكولات إضافية — مثل MySQL أو PostgreSQL أو gRPC أو أي منفذ مخصّص — عرِّفها في spec.additionalPorts:
containerPorts الخاصة بالـ Pod وإلى الخدمة عديمة الرأس العامة.
ويمكن العثور على المثال الكامل في examples/custom_protocols.yaml.
مثال متكامل: MySQL wire protocol
9004:
قيود الحقول
المنافذ والأسماء المحجوزة
additionalPorts التي قد تتعارض مع المنافذ التي يستخدمها المشغّل نفسه. جميع المنافذ المرتبطة بـ TLS محجوزة دون قيد أو شرط حتى لا يؤدي تبديل spec.settings.tls.enabled لاحقًا إلى تعطيل عنقود كان صالحًا سابقًا.
تُرفض أيضًا الأسماء التالية — فهي معرّفات المشغّل الداخلية لأنواع البروتوكولات (وليست الأسماء المستعارة المفهومة للبشر):
ينتج عن الطلب المرفوض خطأ مثل:
فحص الإصدار وقناة الترقية
- الإبلاغ عن الإصدار — بالنسبة إلى
ClickHouseCluster، يشغّل مورد KubernetesJobصورة الحاوية مرة واحدة لاكتشاف إصدار ClickHouse قيد التشغيل؛ وبالنسبة إلىKeeperCluster، يقرأ المشغّل الإصدار الذي يبلّغ به الخادم من النسخ المتماثلة قيد التشغيل. ويُسجَّل الإصدار المكتشف في.status.versionوتستخدمه خطوات التسوية الأخرى (على سبيل المثال، لا يكون مفتاح named-collections الخاص بـExternal Secretمطلوبًا إلا بدءًا من ClickHouse25.12). - قناة الترقية — تحقّق دوري من موجز إصدارات ClickHouse العام (
https://clickhouse.com/data/version_date.tsv). ويبلّغ المشغغّل عمّا إذا كان إصدار أحدث متاحًا عبر شرط الحالةVersionUpgraded. وهو لا يرقّي العنقود من تلقاء نفسه مطلقًا — فالمستخدم هو من يتحكّم في وسم الصورة.
اختيار قناة الترقية
spec.upgradeChannel مجموعة الإصدارات الصادرة من المشروع الأصلي التي يقارن بها المشغّل. ويوجد الحقل نفسه في كلٍّ من ClickHouseCluster وKeeperCluster.
^(lts|stable|\d+\.\d+)?$):
في بيئات الإنتاج، يُفضَّل عمومًا تثبيت القناة على قيمة
<major>.<minor> صريحة (مثل 25.8). فهذا يقيّد العنقود بخط الإصدار الرئيسي المقصود، ويتيح للمُشغِّل إظهار تحذير WrongReleaseChannel إذا انجرفت أي نسخة متماثلة، لسبب ما، إلى إصدار رئيسي مختلف — وهو أمر يكتسب أهمية خاصة عندما يُشار إلى الصورة بواسطة digest (@sha256:...) بدلًا من tag مقروء بشريًا. أما القيمة الافتراضية الفارغة فهي مناسبة لعناقيد التطوير حيث لا تكون القفزات بين الإصدارات الرئيسية مصدر قلق.
شروط الحالة
افحصها باستخدام:
تجاوز Job فحص الإصدار
ClickHouseCluster فقط. لم يعد KeeperCluster يشغّل Job لفحص الإصدار — إذ تُقرأ نسخته مباشرةً من نسخ Keeper المتماثلة العاملة — لذلك فإن spec.versionProbeTemplate مهمل ولا يكون له أي تأثير هناك.
يُنَفَّذ الفحص باعتباره Job عاديًا في Kubernetes. إذا كانت في عنقودك سياسات قبول تتطلب قيم Tolerations محددة، أو محددات عُقد، أو سياقات أمان، أو إذا كنت تريد تقييد مدة بقاء مهام الفحص المكتملة، فتجاوز القالب عبر spec.versionProbeTemplate:
version-probe هو الاسم الافتراضي للمشغّل — إذ إن الإدخال ضمن containers: يطابقه بالاسم، لذا يُجري المشغّل دمجًا عميقًا للحقول التي يوفّرها المستخدم فوق القيم الافتراضية.
عناصر تحكم على مستوى المشغّل
اضبط
--disable-version-update-checks=true في البيئات المعزولة عن الشبكة أو عندما لا يكون مسموحًا بخروج الحركة إلى clickhouse.com.
إعدادات ClickHouse
كلمة مرور المستخدم default
spec.settings.defaultUserPassword كلمة مرور المستخدم المضمّن default.
وفّر القيمة من مفتاح في Secret (مستحسن) أو في ConfigMap
تنشئه، بدلًا من تضمينها مباشرةً داخل CR:
secret أو configMap، على أن يشتمل أيٌّ منهما على كلٍّ من name (الكائن)
وkey (الإدخال الذي يحتوي على كلمة المرور).
أنواع كلمات المرور
passwordType كيفية تفسير ClickHouse للقيمة. وتكون قيمته الافتراضية
password (نص صريح)؛ أما البدائل فهي صيغ مُجزَّأة مثل
password_sha256_hex و password_double_sha1_hex. ويُفضَّل استخدام نوع مُجزَّأ حتى لا
يُخزَّن النص الصريح مطلقًا. راجع
إعدادات مستخدمي ClickHouse
للاطلاع على القائمة الكاملة.
مثال كامل باستخدام Secret
عند استخدام
passwordType: password، يُضبط clickhouse-client داخل الكبسولة
باستخدام كلمة المرور هذه، مما يكون مفيدًا عند تصحيح الأخطاء.استخدام ConfigMap
password_sha256_hex:
لا تضع كلمة مرور غير مشفّرة في ConfigMap. استخدم Secret لأي قيمة غير مشفّرة
(
passwordType: password).مستخدمون مخصّصون في التهيئة
قم بتهيئة مستخدمين إضافيين في ملفات التهيئة. أنشئ ConfigMap وSecret للمستخدم:مزامنة قاعدة البيانات
clickhouse.com/ReplicaInitialized، لذلك لا تُنشر النسخة المتماثلة الجديدة عبر الخدمة عديمة الرأس العامة إلا بعد أن يُكمل المُشغِّل تهيئتها: إذ تُحوَّل قاعدة البيانات default إلى محرك Replicated ويُزامَن المخطط. وحتى ذلك الحين، يصل إليها المُشغِّل والنسخ المتماثلة الأخرى عبر خدمتها الداخلية. عند استخدام enableDatabaseSync: false، يضع المُشغِّل علامة التهيئة على النسخ المتماثلة فورًا، لذا تعتمد الجاهزية على فحوصات الحاوية وحدها.
لا يحذف المُشغِّل مطلقًا قاعدة بيانات default غير Replicated والمملوءة بالبيانات. تبدأ هذه النسخة المتماثلة مع ذلك في خدمة حركة مرور العملاء بعد إعداد المخطط، لكن العنقود يبلّغ عن SchemaInSync=False بالسبب DefaultDatabaseNotReplicated إلى أن تعالج قاعدة البيانات تلك بنفسك.
قبل إزالة نسخة متماثلة عند التخفيض التدريجي، يُفرِّغ المُشغِّل أولًا حركة مرور العملاء منها، وينتظر حتى تتوقف عن النشر، ويُكرِّر بياناتها المتبقية إلى النسخ المتماثلة الباقية، ثم يحذفها فقط بعد ذلك.
تسجيل الخادم
اضبط سجل خادم ClickHouse عبرspec.settings.logger. كل حقل اختياري وله قيمة افتراضية آمنة، لذا فإن أي عنقود لا تُجري عليه أي تعديل يسجّل بالفعل عند مستوى information في كلٍّ من وحدة تحكم الحاوية وملف سجل خاضع للتدوير على القرص.
يُبقي المشغّل التسجيل إلى وحدة التحكم مفعّلًا دائمًا لكي يعمل
kubectl logs، ويضيف التسجيل إلى الملف فوق ذلك عندما تكون logToFile بقيمة true. وينتج عن عنقود بالإعدادات الافتراضية كتلة logger التالية:
spec.settings.logger نفسه على KeeperCluster؛ لكن المشغّل يكتب ملفاته في هذه الحالة ضمن /var/log/clickhouse-keeper/، ويضبط مستوى مسجّل Raft (raft_logs_level) على قيمة level نفسها.
يظل التسجيل إلى الطرفية مفعّلًا بغضّ النظر عن
logToFile، لذا يواصل kubectl logs العمل حتى عند تعطيل التسجيل إلى ملف. اضبط jsonLogs: true عند إرسال السجلات إلى مخزن سجلات منظَّم يحلّل JSON.جداول سجلات النظام
يُفعّل المشغّل جداول النظامquery_log وpart_log وtext_log وmetric_log وasynchronous_metric_log. وبما أنها تشترك مع بياناتك في وحدة التخزين نفسها، يفرض عليها spec.settings.systemLogsTTLDays مدة احتفاظ باستخدام TTL على مستوى الجدول. يضبط خطاف الويب المخصّص لتعيين القيم الافتراضية هذا الإعداد على 30 إذا أنشأت عنقودًا دون تحديد الحقل. اضبطه على 0 لتعطيل TTL صراحةً.
ينطبق الإعداد الافتراضي على العناقيد الجديدة فقط. أما العنقود الذي أُنشئ قبل استحداث
systemLogsTTLDays، فتبقى جداول سجلات النظام فيه بلا حدّ زمني للاحتفاظ بها حتى تضبط الحقل بنفسك.@remove — وكل ذلك من خلال extraConfig:
لا يعني تعطيل الجدول حذفه: تبقى البيانات الموجودة على القرص حتى تحذف الجدول بنفسك.
يعيد ClickHouse إنشاء جدول النظام إذا تغيّرت قيمة TTL الخاصة به، ويحتفظ بالبيانات القديمة في جدول أُعيدت تسميته، مثل
system.text_log_0. احذف هذه الجداول عندما لا تعود بحاجة إلى سجلّها.إعداد مخصص
تهيئة إضافية مضمنة
extraConfig:
روابط مفيدة:
تهيئة إضافية قابلة لإعادة التحميل
يؤدي أي تغيير فيextraConfig إلى إعادة تشغيل وحدات pod الخاصة بـ ClickHouse، لأن المشغّل لا يستطيع تحديد الإعدادات التي تُطبَّق وقت التشغيل. وللإعدادات التي يستطيع ClickHouse إعادة تحميلها دون إيقاف التشغيل — وأشيعها named_collections — استخدم extraReloadableConfig بدلًا من ذلك. يطبّق المشغّل التغييرات بإعادة تحميل التهيئة، دون إعادة تشغيل وحدات pod:
extraConfig أو extraReloadableConfig فقط؛ ويُصدر المشغّل تحذيرًا إذا تضمّن الحقلان القسم نفسه.
عند استخدام
extraReloadableConfig، فإنك تؤكد أن إعداداته قابلة لإعادة التحميل بأمان. أما الإعداد الذي يتطلب إعادة التشغيل، فلن يسري مفعوله إذا وُضع هنا إلا عند إعادة التشغيل التالية، دون ظهور أي خطأ.إعدادات المستخدمين الإضافيين المضمّنة
extraUsersConfig. ويُفيد ذلك في تعريف المستخدمين وملفات التعريف والحصص والامتيازات مباشرةً ضمن مواصفات العنقود.
يتم تخزين
extraUsersConfig في كائن ConfigMap ضمن k8s. تجنّب وضع الأسرار هناك بصيغة نصية مكشوفة.مثال على التهيئة
المزامنة الدورية
إلى جانب الاستجابة لأحداث Kubernetes، يعيد الـ مشغّل مطابقة (reconcile) كل عنقود على فترات زمنية ثابتة. ويبقي ذلك شروط الحالة محدَّثة بالنسبة للحالات التي لا يمكن لأي watch رصدها — مثل صحة الـ نسخة متماثلة في ClickHouse، و quorum الخاص بـ Keeper — كما يعيد محاولة إجراءات المعالجة مثل تنظيف الـ pod العالق. ويُتحكَّم في هذه الفترة عبر متغير البيئةRESYNC_PERIOD الخاص بالـ مشغّل (القيمة الافتراضية 30s). وهو ينطبق على موارد KeeperCluster، حيث تُعطِّل القيمة 0 المزامنة الدورية. أما موارد ClickHouseCluster فتستطلع system.warnings في ClickHouse كل 30 ثانية، وهو ما يعيد تشغيل عملية التسوية أصلاً، لذا لا تأثير لـ RESYNC_PERIOD عليها حالياً.
MAX_CONCURRENT_RECONCILES (القيمة الافتراضية 4).
إيقاف التسوية مؤقتًا
أضف التعليق التوضيحيclickhouse.com/pause-reconciliation: "true" إلى ClickHouseCluster أو KeeperCluster لإيقاف تسويته بواسطة المشغّل. عندئذٍ، يُبلّغ المشغّل عن ReconcileSucceeded=False مع السبب ReconciliationPaused للمورد، ويتركه دون تغيير — وهو ما يفيد عند الحاجة إلى التدخل اليدوي إذا كان المشغّل سيُلغي تغييراتك. خلال فترة الإيقاف، يُبلّغ المشغّل عن جميع شروط الحالة (بما فيها Ready وHealthy) بالقيمة Unknown مع السبب ReconciliationPaused، لأنه لا يراقب العنقود. أزل التعليق التوضيحي لاستئناف التسوية؛ وستُطبَّق التغييرات المعلّقة في المواصفة عند إجراء التسوية التالية.