Le DJ qui voulait être cohérent

Jojo Beat et Jojo EnMousse, les deux DJs qui souhaitent mettre en place une plate-forme de partage de musique entre les différents DJs du monde n'arrivent pas à se mettre d'accord sur comment configurer leur cluster.

  • Jojo Beat est persuadé qu'il va y avoir énormément de monde qui va utiliser cette plate-forme, et pense qu'il serait bon d'avoir un système robuste face aux pannes, et qui puisse être le plus cohérent possible, quitte à perdre un peu de performance.

  • Jojo EnMousse lui par contre pense que l'équipement qu'ils achètent est le plus haut de gamme, qu'il ne tombera jamais en panne, et que ça ne sert à rien de perdre de la performance. Pour lui, autant ne pas répliquer les données, cela ne sert à rien.

Ainsi, n'arrivant pas à se mettre d'accord, les deux essaient de mettre en place les solutions, afin de montrer à l'autre qu'il a tort.

Commençons dans un premier temps à nous pencher sur la solution que Jojo Beat souhaite mettre en place, à savoir avoir un système cohérent et robuste face aux pannes.

Question

Il faut commencer par vérifier que nos nœuds dans le cluster de CCM fonctionnent toujours. Pour cela, utiliser la commande "ccm status".

Question

Se connecter au nœud 1 avec CQLSH afin de pouvoir commencer à faire des requêtes.

Solution

Question

D'après vous, quel est le Replication Factor à mettre en place pour avoir une assez bonne gestion des pannes dans notre KEYSPACE ? Mettez en place le KEYSPACE ksJojoB avec le Replication Factor choisi.

Indice

Indice

Indice

Solution

Question

Entrer dans le KEYSPACE, et créer une table remix avec les attributs ID, nom, dj. L'ID est la Primary Key. Insérez une première ligne avec les valeurs suivantes :

id = 1 ; nom = 'monRemix', dj='Jojo Beat'.

Vérifiez que l'insertion s'est bien déroulée.

Indice

Indice

Solution

Question

Récupérez le token référençant la ligne de l'insertion précédente. Récupérez les autres colonnes également.

Indice

Solution

Question

Quitter CQLSH avec la commande "quit". Puis afficher la table des tokens dans le cluster.

Solution

Question

Nous pouvons savoir exactement dans quel nœud va être répliquée une insertion avec la commande suivante.

num. | Ligne | texte | copie |
CTRL+C pour copier, CTRL+V pour coller
1
ccm [nom_du_noeud] nodetool getendpoints [nom_keyspace] [nom_table] [valeur_primary_key]
ccm [nom_du_noeud] nodetool getendpoints [nom_keyspace] [nom_table] [valeur_primary_key]

Testez la commande suivante. Qu'en déduisez vous ?

num. | Ligne | texte | copie |
CTRL+C pour copier, CTRL+V pour coller
1
ccm node1 nodetool getendpoints ksjojob remix 1
ccm node1 nodetool getendpoints ksjojob remix 1

Solution

Question

(Optionnel) Vérifiez la copie de la donnée sur les nœuds 4 et 5.

Indice

Solution

Question

Maintenant que nous savons que notre dernier insert se trouve dans les nœuds 3 / 4 / 5, imaginons que le nœud 3 tombe en panne. Pourrons nous toujours avoir accès aux valeurs de la table remix sachant que le Consistency Level est à ONE ?

Solution

Question

Vérifiez le Consistency Level.

Solution

Question

Que se passe-t-il si on update la ligne contenant l'id=1 alors que le nœud 3 est en panne ?

Indice

Solution

Question

Faites plusieurs updates, et regarder les modifications faites dans la table system.hints.

Solution

Question

Modifiez le Consistency Level à ALL. Essayez de faire un UPDATE. Cela ne fonctionne pas. A votre avis pourquoi ?

Indice

Indice

Solution

Question

Quittez CQLSH. Remettez le nœud 3 en route, et reconnectez vous au nœud 1 en CQLSH. Regardez le contenu de la table system.hints. Que déduisez-vous ?

Solution