😴 💑 👂🏻 Quel a été le résultat de la migration de ClickHouse sans autorisation vers ClickHouse avec autorisation 📋 📦 🏳️‍🌈

Commençons par un petit historique. Dans notre entreprise, un projet est en cours de maintenance, qui était jusqu'à récemment en phase de test / développement. À cette époque, il utilisait ClickHouse avec 3 fragments, 2 répliques chacun. Étant donné que l'infrastructure de ce projet était testée et ne nécessitait aucune autorisation supplémentaire (ClickHouse était dans un segment fermé), personne n'a posé cette question.

Au fil du temps, le projet a grandi, ClickHouse est devenu une base de production et nous avons migré les données de l'ancienne infrastructure vers la nouvelle avec 1 fragment, 3 répliques sur 3 serveurs différents (ClickHouse est hébergé à Kubernetes basé sur StatefulSets) et, bien sûr, avec autorisation.

Voici ce qui s'est passé ensuite.

Presque immédiatement après le démarrage du projet en production, nous avons constaté que dans le ClickHouse datadir de la base de données utilisateur, dans les tables non-shard (dans notre cas, celles qui sont situées localement sur chaque nœud, sans le postfixe sharded, de type Distributed), il y avait un grand nombre de non perdus bin-logs. La date des journaux a précédé la date d'installation sur l'autorisation ClickHouse.

Voici la sortie de la console pour l'une des répliques ClickHouse de la table table_1 de la base de données de test:

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

C'est-à-dire les données elles-mêmes ont été placées dans la table distribuée locale d'une réplique spécifique, mais pour une raison inconnue à ce moment-là, elles n'ont pas été déplacées vers une table avec un postfix découpé (tel que ReplicatedMergeTree), qui est accessible à partir de toutes les répliques de cluster en y accédant via une table locale (sans postfix) éclaté).

Comme il s'est avéré après l'analyse, les données enregistrées dans la base de données ClickHouse sur l'ancienne infrastructure, à savoir avant d'activer l'autorisation, elles ne pouvaient plus être réparties entre répliques sur la nouvelle infrastructure, car Sur les nouveaux serveurs ClickHouse, l'autorisation a déjà été activée.

Pourquoi Lorsque les données sont écrites dans ClickHouse sans autorisation, un lien du formulaire suivant est généré dans le répertoire datadir de clickHouse dans les répertoires de base de données correspondants et dans la table (le lien est généré sur la base d'une demande faite à la base de données):

 test_usr@clickhouse%2D0%2Eclickhouse%2Eclickhouse%2Dprod%2Esvc%2Ecluster%2Elocal\:9000

Examinons-le plus en détail. Le lien ci-dessus est accessible par l'utilisateur test_usr, mais le mot de passe pour l'autorisation n'est pas spécifié. Et que se passe-t-il si, avant d'activer l'autorisation dans la base de données, une très grande quantité de données était enregistrée dans ClickHouse, qui formait des journaux de casiers, et ClickHouse sur les anciens serveurs n'avait pas le temps de les perdre, puis après avoir activé l'autorisation sur les nouveaux serveurs ClickHouse et migré les anciens non perdus bin-logs vers de nouveaux serveurs, ces bin-logs ne peuvent plus être lus, car le lien a déjà été généré sans autorisation pour l'utilisateur test_usr.

Toutes les nouvelles données entrantes dans ClickHouse généreront également des journaux de casiers dans les répertoires et tables de base de données correspondants, qui seront ensuite lus, mais avec un lien différent, où l'autorisation est indiquée (puisque l'application accède déjà à ClickHouse sur la nouvelle infrastructure se fait avec le mot de passe de l'utilisateur test_usr, sinon la requête n'atteindra tout simplement pas la base de données):

 test_usr:password@clickhouse%2D0%2Eclickhouse%2Eclickhouse%2Dprod%2Esvc%2Ecluster%2Elocal\:9000

Parce que les données sont écrites dans la base de données de manière asynchrone, c'est-à-dire qu'elles sont d'abord placées sur une réplique ClickHouse locale à laquelle on a accédé, puis elles sont envoyées à d'autres répliques du cluster.

Par conséquent, les anciennes données enregistrées sur l'une des répliques ClickHouse locales, mais qui n'étaient pas réparties entre les autres répliques de cluster (car le lien généré ne contenait pas le mot de passe de l'utilisateur, mais il était déjà défini), elles n'étaient même pas accessibles. pour lire la réplique sur laquelle se trouvaient directement les journaux de bin non appliqués.

Comment avons-nous résolu le problème et n'avons-nous pas perdu les données non allouées?

Tout s'est avéré assez simple. Il suffit d'effectuer les manipulations suivantes avec des données non allouées dans la base de données:

Les liens générés pour chacune des tables de la base de données de problèmes doivent être renommés (renommés) au format requis:

 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

Redémarrez les réplicas ClickHouse, ce qui lance le processus de lecture des journaux de bacs et de les placer dans nos tables fragmentées (ReplicatedMergeTree).

PS : Je recommande à tout le monde de vérifier le fonctionnement de leurs serveurs ClickHouse pour les problèmes décrits. Si tel est le cas, cette note vous aidera à gagner du temps dans la recherche d'une solution et à être plus prudent lors de la définition / modification d'un mot de passe sur ClickHouse à l'avenir.

Quel a été le résultat de la migration de ClickHouse sans autorisation vers ClickHouse avec autorisation

Lisez également d'autres articles sur notre blog:

More articles: