FAQ CassandraConsultez toutes les FAQ

[Traduction de la FAQ officielle]

Quand un nouveau nœud rejoint un cluster, il va contacter automatiquement les autres nœuds du cluster et copier les données voulues vers lui-même.

[Traduction de la FAQ officielle]

Cassandra est un système distribué NoSQL et open source (développé à l'origine par Facebook et devenu depuis un projet de la Fondation Apache) fondé sur un mécanisme de « propagation de rumeurs de proche en proche » (gossip architecture). La ListenAddress est aussi l’adresse « mon adresse de contact », c’est-à-dire l’adresse qu’un nœud donne aux autres nœuds pour le contacter. Dire aux autres nœuds « contactez-moi sur n'importe laquelle de mes adresses » est une mauvaise idée ; si différents nœuds du cluster choisissent différentes adresses pour vous contacter, toutes sortes de problèmes se produisent…
Si vous ne voulez pas configurer manuellement une adresse IP d’écoute pour chaque nœud dans votre cluster (ce que l’on peut comprendre !), laissez-la à blanc et Cassandra utilisera la fonction InetAddress.getLocalHost() pour choisir une adresse. Ensuite, c’est à vous ou à votre équipe d’admin/exploitants de faire en sorte que les adresses soient traduites correctement (/etc/hosts/, dns, etc.).
L’exception à cette règle est JMX qui écoute par défaut l’adresse 0.0.0.0 (bogue Java 6425769).
Voir CASSANDRA-256 et CASSANDRA-43 pour plus de détails.

[Traduction de la FAQ officielle]

Par défaut, Cassandra utilise le port 7000 pour la communication cluster (7001 si le SSL est activé), 9160 pour les clients et 7199 pour JMX. L’interconnexion de la communication et les Thrift ports sont configurables dans cassandra.yaml, et le port JMX est configurable dans cassandra-env.sh (options JVM). Tous ces ports sont TCP. Voir aussi Running Cassandra.

[Traduction de la FAQ officielle]

Voir CassandraHardware.

[Traduction de la FAQ officielle]

Il est difficile d’utiliser les TimeUUID avec les clients Java parce que java.util.UUID ne supporte pas les UUID de première génération (fondés sur des estampilles ou horodatages). Voici un moyen de s’en servir avec Cassandra : utilisez le générateur d’UUID (jar) téléchargeable à cette adresse : http://johannburkard.de/software/uuid/(voir Time based UUID Notes)
Les trois méthodes ci-dessous sont très utiles pour manipuler des UUID en entrée ou en sortie de Cassandra.
Générer un nouvel UUID pour l’utiliser dans un TimeUUIDType.

1
2
3
4
5
6
7
8
9
/** 
 * Gets a new time uuid. 
 * 
 * @return the time uuid 
 */ 
public static java.util.UUID getTimeUUID() 
{ 
    return java.util.UUID.fromString(new com.eaio.uuid.UUID().toString()); 
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
/** 
 * Returns an instance of uuid. 
 * 
 * @param uuid the uuid 
 * @return the java.util. uuid 
 */ 
public static java.util.UUID toUUID( byte[] uuid ) 
{ 
    long msb = 0; 
    long lsb = 0; 
    assert uuid.length == 16; 
    for (int i=0; i<8; i++) 
        msb = (msb << 8) | (uuid[i] & 0xff); 
    for (int i=8; i<16; i++) 
        lsb = (lsb << 8) | (uuid[i] & 0xff); 
    long mostSigBits = msb; 
    long leastSigBits = lsb; 
  
    com.eaio.uuid.UUID u = new com.eaio.uuid.UUID(msb,lsb); 
    return java.util.UUID.fromString(u.toString()); 
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
/** 
 * As byte array. 
 * 
 * @param uuid the uuid 
 * 
 * @return the byte[] 
 */ 
public static byte[] asByteArray(java.util.UUID uuid) 
{ 
    long msb = uuid.getMostSignificantBits(); 
    long lsb = uuid.getLeastSignificantBits(); 
    byte[] buffer = new byte[16]; 
  
    for (int i = 0; i < 8; i++) { 
        buffer[i] = (byte) (msb >>> 8 * (7 - i)); 
    } 
    for (int i = 8; i < 16; i++) { 
        buffer[i] = (byte) (lsb >>> 8 * (7 - i)); 
    } 
  
    return buffer; 
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
public static java.util.UUID uuidForDate(Date d) 
{ 
    /* 
      Magic number obtained from #cassandra's thobbs, who 
      claims to have stolen it from a Python library. 
    */ 
    final long NUM_100NS_INTERVALS_SINCE_UUID_EPOCH = 0x01b21dd213814000L; 
  
    long origTime = d.getTime(); 
    long time = origTime * 10000 + NUM_100NS_INTERVALS_SINCE_UUID_EPOCH; 
    long timeLow = time &       0xffffffffL; 
    long timeMid = time &   0xffff00000000L; 
    long timeHi = time & 0xfff000000000000L; 
    long upperLong = (timeLow << 32) | (timeMid >> 16) | (1 << 12) | (timeHi >> 48) ; 
    return new java.util.UUID(upperLong, 0xC000000000000000L); 
}

[Traduction de la FAQ officielle]

Les données que vous écrivez dans Cassandra sont persistantes dans les SSTables. Comme les SSTables sont persistantes, les données ne peuvent pas réellement être supprimées lorsque vous effectuez une suppression ; au lieu de cela, un marqueur (appelé tombstone, ou « pierre tombale ») est positionné pour indiquer le nouveau statut. N’ayez crainte, dès que le premier compactage aura lieu entre les données et la pierre tombale, les données ainsi marquées seront complètement purgées et l'espace disque correspondant récupéré. Voir DistributedDeletes pour plus de détails.

[Traduction de la FAQ officielle]

Cela arrive quand vous avez le même jeton (token) affecté à chaque nœud. Il ne faut pas faire cela.
Le plus souvent, ce problème arrive aux personnes qui installent Cassandra sur une VM (particulièrement quand on utilise un package Debian qui s’auto-exécute après l’installation, ce qui génère et sauvegarde un jeton). Ensuite, si on clone cette VM pour créer les autres nœuds, cela copie aussi le jeton.

La meilleure solution est d'effacer les répertoires de données et de « commitlog », ce qui assure que chaque nœud générera un jeton aléatoire au prochain redémarrage.

[Traduction de la FAQ officielle]

Oui, mais cela nécessite de faire tourner une réparation pour modifier le nombre de copies des données existantes.

• Modifier le ReplicationFactor à la valeur désirée à l’aide de cassandra-cli.
  

• exécutez "nodetool cleanup" pour supprimer les données répliquées de façon surnuméraire. Le nettoyage s'exécute sur une base nœud par nœud.
  

• exécutez "nodetool repair" pour lancer une réparation antientropie sur le cluster. La réparation fonctionne sur une base par réplique. Il s'agit d'un processus intensif qui peut entraîner une baisse des performances du cluster. Il est fortement recommandé de faire une réparation progressive, car une tentative de réparer tout le cluster d’un seul coup a toutes les chances de le saturer complètement.
  

[Traduction de la FAQ officielle]

Actuellement, Cassandra n’est pas optimisé pour stocker de gros fichiers ou des BLOB (Binary Large OBjects). Il est cependant possible de stocker des fichiers ayant une taille allant jusqu’à 64 Mo dans la base de données, sans avoir besoin de les découper en plus petits morceaux. C’est en grande partie dû au fait que l’API de Cassandra est basée sur Thrift, qui n'offre pas de capacités de streaming ; toute valeur écrite ou récupérée doit tenir dans la mémoire. Il se peut que d’autres interfaces n’utilisant pas Thrift puissent résoudre ce problème à l’avenir, mais il n’est pas prévu pour l’instant de modifier le comportement de Thrift. Si vous prévoyez des applications qui nécessitent le stockage de BLOB, vous devez également tenir compte des attributs suivants de Cassandra.

• La principale limitation sur la taille d’une colonne et d’une super colonne, c’est que toutes les données pour une seule clef et une seule colonne doivent résider (sur le disque) sur une seule machine (un nœud) dans le cluster. Comme seules les clefs sont utilisées pour déterminer les nœuds responsables de la réplication des données, la quantité de données associées avec une clef unique, à cette limite supérieure. Ceci est une limitation inhérente du modèle de distribution.
• Lorsque des colonnes de grande taille sont créées et récupérées, les données des colonnes sont chargées en mémoire vive (RAM), et cette utilisation intensive peut rapidement épuiser les ressources mémoire disponibles. Par exemple, charger 200 enregistrements avec des colonnes qui stockent des images de 10 Mo chacune dans la RAM consommerait environ 2 Go de RAM. Il est clair que plus il y a de grandes colonnes chargées, plus la RAM va se consommer rapidement. Il y a des solutions de contournement, mais il faut les prévoir à l’avance et faire des tests pour obtenir une solution viable pour la plupart des applications, Vous pouvez trouver plus d’informations à ce sujet dans l’article memtables et une solution possible dans la version 0,7 ici : CASSANDRA-16.
• Pour plus d’information, veuillez consulter les notes dans la section “limites de Cassandra” : Cassandra Limitations.
  

[Traduction de la FAQ officielle]

Nodetool s’appuie sur JMX, qui repose lui-même sur RMI (API Java de réseau), lequel à son tour met en place ses propres auditeurs (listeners) et les connecteurs selon les besoins à chaque extrémité de l’échange. Normalement, tout cela se passe de manière transparente, mais des erreurs de résolution de nom pour l’hôte demandant la connexion ou celui la recevant, peuvent entraîner des confusions et des exceptions incompréhensibles.
Si vous n’utilisez pas de DNS, assurez-vous que vos fichiers /etc/hosts sont corrects aux deux extrémités de la connexion. Si cela échoue, essayez de régler le l’option JVM –Djava.rmi.server.hostname = <nompublic> près du bas du cassandra-env.sh, à une interface que vous pouvez atteindre à partir de la machine distante.

[Traduction de la FAQ officielle]

Utilisez un client CQL ([ClientOptions]) et Cassandra 2.0. La version 2.0 supporte les curseurs, ce qui signifie que vous pouvez juste écrire SELECT * FROM toto et vous pourrez itérer de façon automatique sur le curseur résultat.
Sinon, vous pouvez utiliser HadoopSupport.

[Traduction de la FAQ officielle]

• DataStax Opscenter, un outil de gestion et de suivi pour Cassandra avec une interface utilisateur en mode Web.
• Cassandra Cluster Admin, une interface utilisateur en mode Web utilisant PHP.
• Toad for Cloud Databases, un client bureautique, avec un plugin Eclipse qui supporte Cassandra.
• DBeaver, un client bureautique supporté par Cassandra qui utilise le driver JDBC.

[Traduction de la FAQ officielle]

Pour prévenir des erreurs d’utilisateurs, Cassandra stocke le nom du cluster dans ses tables système. Si vous avez besoin de renommer un cluster pour une raison quelconque, vous pouvez effectuer les étapes suivantes pour chaque nœud :

1. Exécuter le cassandra-cli en se connectant localement au nœud ;
2. Exécuter ce qui suit :
   
   1. use system,
   2. set LocationInfo[utf8('L')][utf8('ClusterName')]=utf8(''),
   3. exit;
      
3. Exécuter nodetool flush sur ce nœud ;
4. Mettre à jour le champ cluster_name dans le fichier cassandra.yaml (le même nom qu’en 2b ci-dessus) ;
5. Redémarrer le nœud.
   

[Traduction de la FAQ officielle]

Depuis Cassandra 1.2, les CQL batches sont atomiques par défaut (http://www.datastax.com/dev/blog/atomic-batches-in-cassandra-1-2). Les utilisateurs de l’API Thrift doivent appeler l’opération atomic_batch_mutate, au lieu de batch_mutate, s’ils veulent le même comportement.

[Traduction de la FAQ officielle]

Pour avoir les dernières nouvelles sur l’intégration Hadoop-Cassandra, voir HadoopSupport.

[Traduction de la FAQ officielle]

Les utilisateurs de Cassandra utilisent pour la plupart un cluster pour chaque application ou chaque ensemble lié d'applications, cette architecture est plus simple à configurer et à maintenir. Des travaux ont été réalisés pour permettre de faire tourner plusieurs applications différentes, comme du scheduling et de l’authentification. Pour plus d'informations, voir MultiTenant. Toutefois, le meilleur choix est certainement une seule application (ou un seul groupe d’applications liées) par cluster.

[Traduction de la FAQ officielle]

Oui : http://www.datastax.com/dev/blog/usi...ache-cassandra.

[Traduction de la FAQ officielle]

Pour des informations sur les outils ou frameworks d’écriture de traces, voir LoggingToCassandra.

[Traduction de la FAQ officielle]

Vérifier si selinux est actif ; s’il l’est, désactivez-le (off).

[Traduction de la FAQ officielle]

Oui. Pour plus de détails, voir ExtensibleAuth.

[Traduction de la FAQ officielle]

Voir BulkLoading

[Traduction de la FAQ officielle]

Cassandra utilise mmap pour faire des lectures sans copie. Autrement dit, nous utilisons un système de mémoire virtuelle du système d’exploitation pour mapper les fichiers de données stable dans l’espace d’adressage de Cassandra. Cela va « utiliser » la mémoire virtuelle, c’est-à-dire l’espace d’adressage, et sera signalé par des outils comme top en conséquence. Mais sur des systèmes 64 bits, l’espace d’adressage virtuel est de facto virtuellement illimité, de sorte que vous n’avez aucune raison de vous soucier de cela.

Ce qui importe du point de vue de l’utilisation réelle de la mémoire, au sens courant, c’est la quantité de données allouées sur brk() ou mmap’d/dev/zero, qui représente la mémoire réelle utilisée. Le point essentiel est que pour un fichier mmap’d, il n’est jamais nécessaire de garder les données résidantes dans la mémoire physique. Ainsi, quelles que soient les données que vous gardiez résidantes dans la mémoire physique, il s’agit seulement d’une sorte de cache, de la même manière que des entrées/sorties amèneront le cache du noyau à garder les données que vous lisez ou écrivez.

La différence entre les entrées/sorties ordinaires et mmap(), c’est que la mémoire est réellement mappée sur le processus, ce qui affecte la taille virtuelle mesurée par des outils comme top. La principale raison de l’utilisation de mmap() au lieu des entrées/sorties standard est le fait que la lecture implique un simple accès en mémoire. Si la page réside en mémoire, il suffit de la lire, aucun besoin de faire une demande de page au noyau (donc pas besoin d’entrer dans le noyau et de faire un semi-changement de contexte). Cette question est abordée plus en détail ici.

[Traduction de la FAQ officielle]

Mettre à jour un espace de clefs nécessite de prendre d’abord une photo. Cela implique de créer les liens physiques vers les SSTables existantes, mais Java n’a aucun moyen natif de créer des liens physiques, de sorte qu’il doit faire un fork pour lancer une commande shell ln (la commande Unix pour créer un lien symbolique ou physique sur un fichier). Quand un processus fait un fork, il crée d’abord un fils contenant une copie de son image mémoire, et il faut que la mémoire libre soit au moins égale à la taille de l’empreinte mémoire du processus père, même si le fils ne va, en définitive, pas utiliser toute cette mémoire. Comme Java est un gros processus utilisant beaucoup de mémoire, ceci peut être problématique. La solution est d’installer Java Native Access afin qu’il puisse créer les liens physiques lui-même.

[Traduction de la FAQ officielle]

L’ensemble des nœuds (un nœud unique, le cas échéant, ou plusieurs) responsable(s) d’une donnée ou d’un groupe de données est déterminé par :

• la clef de l’enregistrement (les données sont partitionnées sur ces clefs) ;
• le facteur de réplication (décide du nombre de nœuds qui ont une réplique d’une ligne donnée) ;
• la stratégie de réplication (qui décide quels nœuds hébergent ladite réplique).

[Traduction de la FAQ officielle]

C’est XX %.

[Traduction de la FAQ officielle]

L’anneau peut fonctionner ou démarrer sans seed ; cependant, une défaillance d’un seed unique vous empêchera d’ajouter de nouveaux nœuds au cluster. Il est donc recommandé de configurer plusieurs seeds dans un système de production.

[Traduction de la FAQ officielle]

Certaines des opérations JMX ne peuvent pas être appelées avec jconsole parce que les boutons sont inactifs pour elles. Jconsole ne supporte pas les tableaux comme argument, donc les opérations qui ont un tableau en argument ne peuvent être invoquées sur jconsole. Vous devez écrire un client JMX spécifique pour appeler ces opérations, ou vous aurez besoin d’un outil de surveillance capable de traiter les tableaux.

[Traduction de la FAQ officielle]

La clé (et les noms de colonnes) ne doivent pas dépasser 64 ko.

Le routage est en O(N) de la taille de la clé, et l'interrogation et la mise à jour, sont en O(n log n). En pratique, ces facteurs sont généralement éclipsés par d'autres coûts généraux, mais certains utilisateurs ayant de très grandes clés "naturelles" utilisent de préférence des tables de hachage pour réduire la taille.

[Traduction de la FAQ officielle]

Nous avons rencontré plusieurs ensembles de symptômes différents, qui pourraient correspondre à ce que vous voyez. Ils pourraient tous avoir la même cause, mais ce n'est pas entièrement clair. Un point commun est un message de ce genre dans dmesg :
« INFO: task (some_taskname)some_pid) blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. ».
Il semble que personne n’ait pris le temps d’analyser cela pour en obtenir l’origine, mais il semble aussi que la mise à niveau de Linux et le redémarrage de vos instances corrige le problème. Il est probable qu’il s’agisse de certains bogues présents dans les versions du noyau Linux distribué par Ubuntu, Ils devraient être corrigés dans les versions plus récentes ou à venir. On sait que les versions de Linux suivantes n'ont pas le problème :

• linux-image-2.6.38-10-virtual (2.6.38-10.46) (Ubuntu 11.04/Natty Narwhal) ;
• linux-image-2.6.35-24-virtual (2.6.35-24.42) (Ubuntu 10.10/Maverick Meerkat).

[Traduction de la FAQ officielle]

Avant les versions 1.1 et 1.2, de Cassandra, les mises à jour des schémas se faisaient selon l’idée que les modifications étaient réalisées une par une. Si vous apportiez plusieurs modifications en même temps, vous pouviez aboutir à des nœuds avec des schémas différents. (Avant la 0.7.6, cela pouvait aussi provenir de décalages non négligeables entre les horloges système des différents nœuds du cluster.).
Pour résoudre les désaccords de schéma, vous devez forcer les nœuds en désaccord à reconstruire leur schéma. Voici comment faire :
Ouvrir le client Cassandra et exécuter : 'connect localhost/9160;', puis 'describe cluster;'. Vous devriez voir quelque chose comme ceci :

1
2
3
4
5
6
7
[default@unknown] describe cluster;
Cluster Information:
   Snitch: org.apache.cassandra.locator.SimpleSnitch
   Partitioner: org.apache.cassandra.dht.RandomPartitioner
   Schema versions:
75eece10-bf48-11e0-0000-4d205df954a7: [192.168.1.9, 192.168.1.25]
5a54ebd0-bd90-11e0-0000-9510c23fceff: [192.168.1.27]

• nodetool disablethrift ;
• nodetool disablegossip ;
• nodetool drain ;
• 'sudo service cassandra stop' or 'kill <pid>'.

1
2
ERROR [MutationStage:1] 2012-05-18 16:23:15,664 RowMutationVerbHandler.java (line 61) Error in row mutation
org.apache.cassandra.db.UnknownColumnFamilyException: Couldn't find cfId=1012

[Traduction de la FAQ officielle]

C'est un symptôme de délestage – Cassandra se défend contre les demandes excédentaires par rapport à ce qu’il peut gérer.
Les messages qui sont reçus par un nœud, mais qui ne sont pas traités dans le délai imparti (rpc_timeout) sont supprimés avant d’être traités, car de toutes façons, le nœud coordinateur ne sera plus en attente d’une réponse. Si le nœud coordinateur ne reçoit pas de réponse cohérente avant l’expiration de ce délai, il va retourner une TimedOutException au client. Si le nœud coordinateur reçoit une réponse cohérente, il retournera un succès au client.
Pour les messages de type MUTATION (modification), cela signifie que la mutation n'a pas été appliquée à toutes les répliques auxquelles elles avait été envoyées. L'incohérence sera réparée par Read Repair ou Anti Entropy Repair.
Pour les messages de type READ (lecture), cela signifie qu'une demande de lecture peut ne pas s’être terminée.
Le délestage fait partie de l'architecture Cassandra. Si le problème est régulier, c’est le signe d’une surcharge d’un nœud ou du cluster.

[Traduction de la FAQ officielle]

Si Cassandra tombe en erreur avec le message "Map failed", cela signifie que le système d’exploitation refuse d’allouer plus de mémoire à Java. Sous Linux, cela signifie généralement que memlock est limité. Consultez /proc/<pid de Xassandra>/limits pour vous en assurer et augmenter le quota disponible (par exemple, via la commande ulimit du shell bash). Il se peut que vous deviez aussi augmenter le vm.max_map_count. À noter que les distributions Debian et Redhat de Linux gèrent cela automatiquement pour vous.

[Traduction de la FAQ officielle]

Les mises à jour doivent être commutatives, car elles peuvent arriver dans un ordre différent sur différentes répliques. Tant que Cassandra a une façon déterministe de choisir le gagnant, celui qui est sélectionné est aussi valable qu’un autre, et les détails doivent être traités comme un détail d'implémentation. Cela dit, dans le cas d'une égalité des estampilles, Cassandra suit deux règles : d'abord les suppressions ont lieu avant les insertions et mises à jour, ensuite, s'il y a deux mises à jour, alors celle dont la valeur lexicale est la plus grande, prime.