Skip to main content
تغطي هذه الصفحة عمليات ما بعد النشر لـ ClickHouse Connector على كلا هدفي التثبيت. للتثبيت والإعداد الأولي، راجع الإعداد الأولي.

الترقيات

Kubernetes

تستخدم عمليات Kubernetes بعد النشر واجهة سطر الأوامر helm على محطة عملك. لا يتضمن عميل Helm مدمجًا سوى init، لذا ثبّت helm قبل أول ترقية.
رقِّ الإصدار من مستودع المخططات العام، مع إعادة استخدام تراكب القيم الذي أعدّه init:
إصدارات Chart هي وسوم الإصدار من دون بادئة v (يتوافق Chart بالإصدار 0.9.0 مع الوسم v0.9.0). يشير Chart المنشور مسبقاً إلى image الحاوية العامة، لذا لا تتطلب عمليات التثبيت والترقية العادية قيماً لـ image؛ وللاطلاع على القيم الافتراضية لـ Chart، شغّل helm show values clicklink-connector --repo https://releases.clicklink.clickhouse.com/charts. لا يتوفر لعملية التثبيت من مرجع Chart مباشر (oci:// أو URL أو أرشيف أو دليل محلي) repository يمكن الرجوع إليه لحل المرجع؛ لذا أعد تشغيل helm upgrade clicklink-connector <same-chart-reference> بالإصدار الجديد بدلاً من ذلك. كما أن إعادة تشغيل init باستخدام واجهة سطر الأوامر أحدث توصل إلى الحالة المطلوبة، لكن init يحتاج دائماً إلى إحدى نقاط الدخول الخاصة به: --handoff إذا احتفظت بـ bundle، أو رمز تسجيل جديد مع --force بعد التنظيف الموثّق؛ ويُعد helm upgrade المذكور أعلاه المسار المعتاد (راجع إعادة التشغيل والتعافي).

Linux VM

أعِد تشغيل برنامج التثبيت على المضيف؛ إذ سيُنزّل الإصدار الأحدث ويتحقق منه بالطريقة نفسها المتبعة أثناء الإعداد الأولي، وسيُنشئ نسخة احتياطية من الملف التنفيذي السابق، مع الاحتفاظ بأنماط الإخفاء وملف البيئة النشطين لديك. ثم أعد تشغيل الخدمات:
للترقية إلى إصدار محدد بدلًا من أحدث إصدار، أضف --version vX.Y.Z إلى أمر التثبيت.

الحالة الصحية

توفّر كل عملية خفية نقطة نهاية /livez على منفذ الحالة الصحية الخاص بها. يُعد حقل JSON ‏status في جسم الاستجابة مؤشر الحالة الصحية، وليس رمز حالة HTTP، لذا تحقّق من الجسم بدلًا من الاعتماد على رمز 200. تُوفَّر مقاييس Prometheus على منفذ المقاييس الخاص بكل مكوّن. المنافذ الافتراضية لكلا الهدفين: عند تمكين جلسات الدعم، تستمع البوابة أيضًا على المنفذ 8443: باستخدام TLS موقّع ذاتيًا على جهاز افتراضي، أو HTTP محلي ضمن الـpod خلف kubectl port-forward، أو Ingress ينهي TLS على Kubernetes. على جهاز افتراضي، يمكنك تشغيل مجموعة الفحوصات الكاملة في أي وقت:
يتحقق من الإعدادات والملفات وتعارضات المنافذ وإمكانية الوصول عبر الشبكة (نقطة نهاية واجهة برمجة التطبيقات وكل مثيل من ClickHouse) والاتصال بـ ClickHouse وحالة وحدة systemd ووصول كل مكوّن والقرص وأنماط الإخفاء، وينهي التنفيذ بالرمز 2 إذا فشل أي فحص.

الشهادات

يجدد الموصل شهادة العميل الخاصة به تلقائياً: يتحقق كل برنامج خفي من الشهادة الطرفية كل 12 ساعة ويجددها عند تبقي 10 أيام على انتهاء صلاحيتها، ويتلقى شهادة طرفية جديدة صالحة لمدة 30 يوماً عبر قناة mTLS الحالية الموثقة باستخدام HMAC. لا يلزم اتخاذ أي إجراء من قِبل المشغّل. في Kubernetes، تُكتب الشهادة الطرفية المجددة مجدداً في Secret clicklink-mtls؛ وعلى جهاز افتراضي، تُكتب ضمن /etc/clicklink/tls/. لفحص تاريخ انتهاء الصلاحية الحالي:

تدوير بيانات الاعتماد

بيانات اعتماد واجهة برمجة التطبيقات (HMAC)

اطلب رمز تسجيل جديدًا من فريق حساب ClickHouse، ثم أعد تشغيل أمر init الأصلي مع --enroll و--force. احتفظ بجميع الرايات الخاصة بالهدف المستخدمة في التثبيت الأول (--target-namespace و--values وأي رايات mirror مثل --chart أو --chart-repo أو --chart-version)، لأن --force يعيد إعداد التكوين المحفوظ. في تثبيت default:
لإجراء التدوير دون تدخل يدوي، عندما يتطلب إعداد SQL كلمة مرور، يمرّر stdin كلا السريْن بالترتيب: رمز التسجيل في السطر الأول وكلمة المرور في السطر الثاني. وتستهلك قراءة رمز التسجيل سطرًا واحدًا فقط.

مستخدمو ClickHouse

أعِد توفير مستخدمي الموصل ذوي صلاحية القراءة فقط لكل مثيل. في Kubernetes، نفِّذ الأمر من محطة عملك؛ إذ يعيد --apply-ch-grants تطبيق الامتيازات المُنشأة مجددًا داخل الـ pod، بحيث تصل بيانات الاعتماد الجديدة إلى ClickHouse (إذا كانت كلمة مرور المستخدم الإداري معيّنة، فأضف --ch-admin-password-stdin ومرّرها عبر pipe):
على جهاز افتراضي، على المضيف:
بالنسبة إلى المثيلات التي يديرها المشغّل، أضف --ch-user-via cr وخيارات اختيار الـpod إلى أيٍّ من الصيغتين؛ راجع مرجع CLI.

شهادة العميل

يُجدَّد تلقائيًا (راجع الشهادات). لاستبدال شهادة سارية فورًا، أعد تشغيل init باستخدام الخيار --force.

إعادة التشغيل والاسترداد

تتقارب عمليات إعادة تشغيل init، لذا تكون إعادة تنفيذ الأمر نفسه دائمًا هي الخطوة الأولى. من دون --force، يُحتفَظ بملف /etc/clicklink/config.yaml الموجود (VM) أو تراكب clicklink-values.yaml (Kubernetes)، ويُعاد استخدام مفتاح العميل الموجود، بينما تُستبدل بيانات الاعتماد وسلسلة CA بصورة ذرية. ويمكن تكرار أوامر الاسترداد التي تطبعها CLI بعد فشل جزئي بأمان. يستبدل --force الإعداد أو التراكب المحتفَظ به، ويُعيد إنشاء مفتاح العميل، ويحل محل شهادة عميل غير منتهية الصلاحية. ولا ينشئ مطلقًا معرّف UUID جديدًا للمجموعة: إذ تُحفظ هوية الموصل حتى عند استخدام --force. إذا فشل توقيع الشهادة بعد التدريج، أو أعادت نقطة نهاية التوقيع الرمز 409 لأن شهادة غير منتهية الصلاحية موجودة بالفعل، فلن تحتاج إلى رمز تسجيل جديد أو إصدار ثانٍ. أكمل التثبيت باستخدام المواد الموقَّعة الموجودة بالفعل على القرص:
هذا هو الشكل الخاص بالآلة الافتراضية (يعيد المستخدم الجذر كتابة /etc/clicklink ويدير الخدمات). في Kubernetes، تطبع واجهة سطر الأوامر الصيغة الكاملة، بما في ذلك --target helm و--target-namespace و--values؛ استخدم الأمر المطبوع كما هو.

إلغاء التثبيت

Linux VM

يتوفر uninstall.sh ضمن أرشيف tar الخاص بالإصدار. إذا لم يتبقَّ على المضيف أي أرشيف tar مستخرج، فاجلب أرشيفًا واستخرجه كما هو موضح في التنزيل والتحقق اليدويين، ثم شغّله من الدليل المستخرج:
يؤدي ذلك إلى إيقاف الخدمات وتعطيلها وإزالة وحدات systemd والملف التنفيذي، مع الإبقاء على /etc/clicklink و/var/lib/clicklink و/var/log/clicklink ومستخدم clicklink، بحيث تستخدم إعادة التثبيت لاحقًا التكوين الحالي. ولإزالة هذه أيضًا:

Kubernetes

إن موارد Secrets التي أنشأها init ليست مملوكة للمخطط ولا تُحذف عند إلغاء التثبيت. احذفها صراحةً، بما في ذلك Secrets الوصول الخاصة بكل مثيل قمت بتهيئته:

مستخدمو ClickHouse

لا تؤدي إزالة التثبيت من أيٍّ من الهدفين إلى حذف مستخدمي القراءة فقط الذين تم توفيرهم. احذفهم بصفتك Admin على كل مثيل (وأضف --ch-user-suffix إلى الأسماء إذا كنت قد عيّنت لاحقةً):
آخر تعديل في ٢٦ أغسطس ٢٠٢٦