Beginnen wir mit einem kleinen Hintergrund. In unserem Unternehmen befindet sich ein Projekt in der Wartung, das sich bis vor kurzem in der Test- / Entwicklungsphase befand. Zu diesem Zeitpunkt wurde ClickHouse mit 3 Shards und jeweils 2 Replikaten verwendet. Da die Infrastruktur dieses Projekts getestet wurde und keine zusätzliche Autorisierung erforderlich war (ClickHouse befand sich in einem geschlossenen Segment), stellte niemand diese Frage.
Im Laufe der Zeit wuchs das Projekt, ClickHouse wurde zu einer Produktionsbasis und wir migrierten Daten von der alten Infrastruktur auf die neue mit 1 Shard, 3 Replikaten auf 3 verschiedenen Servern (ClickHouse wird in Kubernetes basierend auf StatefulSets gehostet) und natürlich mit Autorisierung.
Folgendes ist als nächstes passiert.
Fast unmittelbar nach dem Start des Projekts in der Produktion stellten wir fest, dass im Datadir ClickHouse der Benutzerdatenbank in Nicht-Shard-Tabellen (in unserem Fall diejenigen, die sich lokal auf jedem Knoten befinden, ohne das Sharded-Postfix vom Typ Distributed) eine große Anzahl von nicht verloren gegangen ist bin-logs. Das Datum der Protokolle lag vor dem Installationsdatum der ClickHouse-Autorisierung.
Das Folgende ist die Konsolenausgabe für eines der ClickHouse-Replikate der Tabelle table_1 der Testdatenbank:
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
Das heißt, Die Daten selbst wurden in der lokalen verteilten Tabelle eines bestimmten Replikats abgelegt, aber aus einem unbekannten Grund zu diesem Zeitpunkt nicht in eine Tabelle mit dem Sharded-Postfix (z. B. ReplicatedMergeTree) verschoben, auf die von allen Cluster-Replikaten aus zugegriffen werden kann, indem über die lokale Tabelle (ohne den Postfix) darauf zugegriffen wird geschert).
Wie sich nach der Analyse herausstellte, wurden die Daten, die in der ClickHouse-Datenbank auf der alten Infrastruktur aufgezeichnet wurden, d.h. Vor dem Aktivieren der Autorisierung konnten sie nicht mehr zwischen Replikaten auf der neuen Infrastruktur verteilt werden, da Auf neuen ClickHouse-Servern wurde die Autorisierung bereits aktiviert.
Warum so. Wenn Daten ohne Autorisierung in ClickHouse geschrieben werden, wird im clickHouse-Datenverzeichnis in den entsprechenden Datenbankverzeichnissen und in der Tabelle ein Link der folgenden Form generiert (der Link wird basierend auf einer an die Datenbank gestellten Anforderung generiert):
test_usr@clickhouse%2D0%2Eclickhouse%2Eclickhouse%2Dprod%2Esvc%2Ecluster%2Elocal\:9000
Schauen wir uns das genauer an. Auf den obigen Link greift der Benutzer test_usr zu, das Kennwort für die Autorisierung ist jedoch nicht angegeben. Und was passiert, wenn vor dem Aktivieren der Autorisierung in der Datenbank eine sehr große Datenmenge in ClickHouse aufgezeichnet wurde, die Bin-Protokolle bildete, und ClickHouse auf den alten Servern keine Zeit hatte, diese zu verlieren, dann nach dem Aktivieren der Autorisierung auf neuen ClickHouse-Servern und dem Migrieren alter nicht verloren gegangen Bin-Logs auf neuen Servern, diese Bin-Logs können nicht mehr abgespielt werden, weil Der Link wurde bereits ohne Berechtigung für den Benutzer test_usr generiert.
Alle neuen eingehenden Daten in ClickHouse generieren auch Bin-Protokolle in den entsprechenden Datenbankverzeichnissen und -tabellen, die dann abgespielt werden, jedoch mit einem anderen Link, bei dem die Autorisierung angegeben ist (da die Anwendung bereits auf ClickHouse in der neuen Infrastruktur zugreift wird mit dem Passwort für den Benutzer test_usr erstellt, andernfalls erreicht die Anfrage einfach nicht die Datenbank):
test_usr:password@clickhouse%2D0%2Eclickhouse%2Eclickhouse%2Dprod%2Esvc%2Ecluster%2Elocal\:9000
Weil Daten werden asynchron in die Datenbank geschrieben, dh sie werden zuerst auf einem lokalen ClickHouse-Replikat abgelegt, auf das zugegriffen wurde, und erst dann werden sie an andere Replikate des Clusters gesendet.
Folglich konnte auf die alten Daten, die auf einem der lokalen ClickHouse-Replikate aufgezeichnet, aber nicht auf die übrigen Cluster-Replikate verteilt wurden (da der generierte Link nicht das Kennwort für den Benutzer enthielt, aber bereits festgelegt war), nicht einmal zugegriffen werden zum Lesen des Replikats, auf dem sich die nicht angewendeten Bin-Protokolle direkt befanden.
Wie haben wir das Problem gelöst und nicht zugewiesene Daten nicht verloren?
Alles stellte sich als recht einfach heraus. Es reicht aus, die folgenden Manipulationen mit nicht zugewiesenen Daten in der Datenbank durchzuführen:
- Die generierten Links für jede der Tabellen der Problemdatenbank sollten in das erforderliche Formular umbenannt (umbenannt) werden:
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
- Starten Sie ClickHouse-Replikate neu, wodurch die Wiedergabe von Bin-Protokollen und deren Platzierung in unseren Sharded-Tabellen (ReplicatedMergeTree) eingeleitet wird.
PS : Ich empfehle jedem, den Betrieb seiner ClickHouse-Server auf die beschriebenen Probleme zu überprüfen. Wenn solche gefunden werden, hilft Ihnen dieser Hinweis, Zeit bei der Suche nach einer Lösung zu sparen und beim zukünftigen Festlegen / Ändern eines Kennworts in ClickHouse vorsichtiger zu sein.
Lesen Sie auch andere Artikel in unserem Blog: