(insérer ici votre dénomination habituelle)
Du pain au chocolat (1) à l’auto-entrepreneuse faisant les cent pas en bas de chez vous, tout à un prix.
Cassandra, grâce à son architecture distribuée, ouvre des perspectives inimaginables avec les bases relationnelles (Résumé express pour ceux ayant ratés les épisodes précédents : scalabilité horizontale, redistribution automatique des partitions, performances remarquables en lecture / écriture) mais au prix de sacrifices que personnes n’aurait envisagé une décennie plus tôt.
Si les développeurs ont fini pas comprendre – souvent douloureusement – que le langage CQL était très pauvre comparé à ceux auxquels ils étaient habitués (PL/SQL, T-SQL, voire au standard SQL pur… ) et que c’étaient de nouveau à eux d’implémenter la richesse fonctionnelle de l’application (bye bye foreign Keys, agrégat, conversions et jointures… toutes ces facilités utilisées sans une pensée et qui coûtaientt si cher dans les performances du moteur), d’autres coûts cachés sont moins bien compris.
Ceux d’entre vous ayant déjà eu affaire aux versions distribuées d’Oracle (RAC, Streams…) savent déjà que le point le plus consommateur, le vrai fardeau d’une base en cluster est la synchronisation des caches mémoires. Assurer qu’une donnée modifiée en un point A ne l’est pas également au point B. Cette sécurité, considérée comme incontouranble pour répondre aux règles de l’ACID, était le défi , l’Everest et le Tartare des ingénieurs. Assurer le « C » (la consistance) des données lorsqu’elles sont ventilées entre plusieurs machines semblaient si déraisonnablement cher qu’il valait mieux chercher d’autres solutions en attendant une puissance CPU et réseau suffisante.
Mais voilà qu’arrive dans le paysage de nouvelles sociétés, ayant de nouveaux besoins et avec une nouvelle approche. Ils n’avaient pas le temps d’attendre : leur application grossissait à toute allure. Ils devaient assurer un service mondial, ininterrompu et avec une clientèle aussi patiente qu’un automobiliste parisien lorsque le feu rouge passe au vert. C’est dire la contrainte.
Quelques travaux précurseurs plus tard (notamment Dynamo, d’Amazon et Big Table de Google), un nouveau paradigme apparaît : CAP. Permanence et Disponibilité sont garanties mais la consistance est laissée à l’appréciation de l’application. Cela répond parfaitement au besoin des réseaux sociaux (Facebook, Twitter) ou à l’exploitation massive de données (suggestion Netflix, datamining sur des senseurs…). On pouvait tolérer une certaine imprécision dans les lectures, un certain délais dans les écritures… Tout cela serait réglé plus tard, progressivement… Et par quelqu’un d’autre.
Message à caractère informatif
Ce quelqu’un d’autre ayant toutes les chances d’être vous, puisque vous êtes l’administrateur.
Cette (trop) longue introduction ayant plantée le décor, rappelons maintenant le principe général des ‘repairs‘ (nous conserverons le terme anglais parce que 1- c’est plus chic et 2- c’est le terme utilisé dans la commande et les messages).
Dans Cassandra, une écriture est acceptée par un nombre de nœuds variant entre un et la valeur du Quorum demandé par le client. Elle est inscrite dans le commitlog du coordinateur et propagée vers les replicats. Cela se fait de manière asynchrone. Si un client lit le même intervalle mais sur un autre nœud, il se peut qu’il ne soit pas au courant de la nouvelle valeur.
C’est ce genre de mécanisme qui a fait transpirer l’angoisse les DBA relationnels, qui sont connus pour détester l’à-peu-près.
Si un nœud a un moment d’absence, il se peut qu’il rate une écriture qui lui était destiné. Dans le cas d’une suppression de ligne, il est même possible qu’elle soit ignorée par un nœud et qu’il soit la source de sa ré-apparition.
Normalement, ce risque est modéré par les hinted handoffs (données conservées par les voisins jusqu’au retour en ligne ou expiration) mais il est obligatoire de réconcilier les informations au sein du cluster.
C’est pour tenter d’éclaircir le déroulement des réparations Cassandra que nous allons suivre pas à pas un exemple en nous concentrant sur une seule table de faible volume (moins d’un méga-octet, 8000 lignes; dérisoire à l’échelle du Big Data).
La plate-forme de test est un cluster CCM (cf Article pour son installation) de trois nœuds, en version 2.1.16. Il contient un keyspace « test1 » et une table très pertinemment nommée « table1 ».
Nous allons voir, dans la seconde partie, comment se déroule une commande de repair, en la suivant pas-à-pas sur la table test1.table1.
(1) Vous pouvez remplacer ce nom par l’expression locale de votre choix.