لنبدأ بخلفية صغيرة. في شركتنا ، هناك مشروع قيد الصيانة ، والذي كان حتى وقت قريب في مرحلة الاختبار / التطوير. في ذلك الوقت ، كان يستخدم ClickHouse مع 3 قطع ، 2 نسخ متماثلة لكل منهما. نظرًا لأن البنية التحتية لهذا المشروع كانت قيد الاختبار ولم تتطلب أي ترخيص إضافي (كان ClickHouse في مقطع مغلق) ، لم يطرح أحد هذا السؤال.
بمرور الوقت ، نما المشروع ، أصبح ClickHouse قاعدة إنتاج وقمنا بترحيل البيانات من البنية التحتية القديمة إلى الجديدة مع 1 شارد ، 3 نسخ متماثلة على 3 خوادم مختلفة (تتم استضافة ClickHouse في Kubernetes بناءً على StatefulSets) ، وبطبيعة الحال ، مع ترخيص.
إليك ما حدث بعد ذلك.
بعد بدء تشغيل المشروع في الإنتاج تقريبًا ، وجدنا أنه في قاعدة بيانات ClickHouse لقاعدة بيانات المستخدم ، في الجداول التي لا تحتوي على أجزاء متقاربة (في حالتنا ، تلك الموجودة محليًا على كل عقدة ، من دون postfix ، من النوع الموزع) ، كان هناك عدد كبير من العناصر المفقودة بن-السجل. يسبق تاريخ السجلات تاريخ التثبيت على ترخيص ClickHouse.
التالي هو إخراج وحدة التحكم لأحد النسخ المتماثلة ClickHouse من الجدول table_1 من قاعدة بيانات الاختبار:
ls -l /var/lib/clickhouse/data/test/table_1/test_usr@clickhouse%2D0%2Eclickhouse%2Eclickhouse%2Dprod%2Esvc%2Ecluster%2Elocal\:9000 | tail -n 10 -rw-r----- 1 clickhouse clickhouse 1472 Jul 8 08:26 9983.bin -rw-r----- 1 clickhouse clickhouse 1453 Jul 8 08:26 9985.bin -rw-r----- 1 clickhouse clickhouse 1383 Jul 8 08:26 9987.bin -rw-r----- 1 clickhouse clickhouse 1461 Jul 8 08:27 9989.bin -rw-r----- 1 clickhouse clickhouse 1458 Jul 8 08:28 9991.bin -rw-r----- 1 clickhouse clickhouse 1468 Jul 8 08:29 9993.bin -rw-r----- 1 clickhouse clickhouse 1413 Jul 8 08:29 9995.bin -rw-r----- 1 clickhouse clickhouse 1509 Jul 8 08:32 9997.bin -rw-r----- 1 clickhouse clickhouse 1504 Jul 8 08:32 9999.bin drwxr-x--- 2 clickhouse clickhouse 4096 Sep 16 12:59 tmp
أي تم وضع البيانات نفسها في الجدول الموزع المحلي لنسخة متماثلة محددة ، ولكن لسبب غير معروف في ذلك الوقت ، لم يتم نقلها إلى جدول باستخدام اللاحقة postfix (مثل ReplicatedMergeTree) ، والتي يمكن الوصول إليها من كافة النسخ المتماثلة للكتلة عن طريق الوصول إليها من خلال الجدول المحلي (بدون postfix sharded).
كما اتضح بعد التحليل ، فإن البيانات التي تم تسجيلها في قاعدة بيانات ClickHouse على البنية التحتية القديمة ، أي قبل تمكين التفويض ، لم يعد بالإمكان توزيعها بين النسخ المتماثلة على البنية الأساسية الجديدة ، لأن على خوادم ClickHouse الجديدة ، تم تمكين التفويض بالفعل.
لماذا هذا عندما تتم كتابة البيانات إلى ClickHouse دون إذن ، يتم إنشاء ارتباط من النموذج التالي في دليل clickHouse datadir في دلائل قاعدة البيانات المقابلة والجدول (يتم إنشاء الرابط بناءً على طلب مقدم إلى قاعدة البيانات):
test_usr@clickhouse%2D0%2Eclickhouse%2Eclickhouse%2Dprod%2Esvc%2Ecluster%2Elocal\:9000
دعونا ننظر في الأمر بمزيد من التفاصيل. يتم الوصول إلى الرابط أعلاه بواسطة المستخدم test_usr ، ولكن لم يتم تحديد كلمة المرور الخاصة بالتخويل. وما يحدث ، إذا قبل تمكين التفويض في قاعدة البيانات ، تم تسجيل كمية كبيرة جدًا من البيانات في ClickHouse ، التي شكلت سجلات بن ، ولم يكن لدى ClickHouse على الخوادم القديمة الوقت الكافي لفقدهم ، ثم بعد تمكين التفويض على خوادم ClickHouse الجديدة وترحيل القديم غير المفقود سجلات bin إلى خوادم جديدة ، لم يعد من الممكن تشغيل سجلات bin هذه ، لأن تم إنشاء الرابط بالفعل دون إذن للمستخدم test_usr.
ستقوم جميع البيانات الواردة الجديدة في ClickHouse أيضًا بإنشاء سجلات حاوية في أدلة وقواعد قاعدة البيانات المقابلة ، والتي سيتم تشغيلها بعد ذلك ، ولكن باستخدام رابط مختلف ، حيث تتم الإشارة إلى الترخيص (نظرًا لأن التطبيق يصل بالفعل إلى ClickHouse على البنية الأساسية الجديدة مصنوع بكلمة مرور المستخدم test_usr ، وإلا لن يصل الطلب ببساطة إلى قاعدة البيانات):
test_usr:password@clickhouse%2D0%2Eclickhouse%2Eclickhouse%2Dprod%2Esvc%2Ecluster%2Elocal\:9000
لأن تتم كتابة البيانات إلى قاعدة البيانات بشكل غير متزامن ، أي ، يتم وضعها أولاً على نسخة متماثلة ClickHouse محلية واحدة تم الوصول إليها ، وعندها فقط يتم إرسالها إلى النسخ المتماثلة الأخرى من الكتلة.
وبالتالي ، فإن البيانات القديمة التي تم تسجيلها على واحدة من النسخ المتماثلة ClickHouse المحلية ، ولكن لم يتم توزيعها بين بقية النسخ المتماثلة العنقودية (بما أن الرابط الذي تم إنشاؤه لا يحتوي على كلمة المرور للمستخدم ، ولكن تم تعيينها بالفعل) ، لا يمكن الوصول إليها حتى لقراءة النسخة المتماثلة التي توجد عليها سجلات حاوية غير مطبقة مباشرة.
كيف نجحنا في حل المشكلة ولم نفقد البيانات غير المخصصة؟
كل شيء اتضح أنه بسيط للغاية. يكفي إجراء المعالجات التالية مع البيانات غير المخصصة في قاعدة البيانات:
- يجب إعادة تسمية الروابط التي تم إنشاؤها لكل جدول من جداول قاعدة بيانات المشكلة (إعادة تسميتها) إلى النموذج المطلوب:
mv /var/lib/clickhouse/data/test/table_1/test_usr@clickhouse%2D0%2Eclickhouse%2Eclickhouse%2Dprod%2Esvc%2Ecluster%2Elocal\:9000 /var/lib/clickhouse/data/test/table_1/test_usr:password@clickhouse%2D0%2Eclickhouse%2Eclickhouse%2Dprod%2Esvc%2Ecluster%2Elocal\:9000
- أعد تشغيل النسخ المتماثلة ClickHouse ، والتي تبدأ عملية إعادة تشغيل سجلات حاوية ووضعها في الجداول المظللة لدينا (ReplicatedMergeTree).
ملاحظة : أوصي الجميع بالتحقق من تشغيل خوادم ClickHouse الخاصة بهم بحثًا عن المشكلات الموضحة. إذا تم العثور عليها ، فستساعدك هذه الملاحظة في توفير الوقت في البحث عن حل وتكون أكثر حذراً عند إعداد / تغيير كلمة مرور على ClickHouse في المستقبل.
اقرأ أيضًا مقالات أخرى على مدونتنا: