IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
logo

FAQ CassandraConsultez toutes les FAQ

Nombre d'auteurs : 4, nombre de questions : 60, dernière mise à jour : 23 septembre 2014  Ajouter une question

 

Cette FAQ a été réalisée à partir des questions fréquemment posées sur les forums de http://www.developpez.com, de l'expérience personnelle des auteurs et de la traduction de la FAQ officielle Cassandra.

Nous tenons à souligner que cette FAQ ne garantit en aucun cas que les informations qu'elle propose sont correctes. Les auteurs font leur maximum, mais l'erreur est humaine. Cette FAQ ne prétend pas non plus être complète. Si vous trouvez une erreur, ou que vous souhaitez nous aider en devenant rédacteur, lisez ceci.

Un grand merci à tous ceux qui ont pris de leur temps pour la réalisation de cette FAQ.

  • Aux rédacteurs : remerciements tout d'abord à tous ceux qui ont rédigé les questions et les réponses (Mickael Baron).
  • Aux traducteurs : remerciements tout d'abord à XxArchangexX pour la traduction des questions et des réponses.
  • Aux relecteurs techniques : merci à Lolo78 et Mickael Baron.
  • Aux correcteurs : remerciements également aux personnes qui ont relu les textes pour supprimer un maximum de fautes de français. Merci à jacques_jean pour ses efforts.
  • Aux visiteurs : remerciements enfin à tous ceux qui ont consulté cette FAQ, et qui, par leurs remarques, nous ont aidé à la perfectionner.
  • Et pour finir, un merci tout spécial à zoom61 qui a créé notre logo.


Sur ce, nous vous souhaitons une bonne lecture.

L'équipe NoSQL

SommaireConfiguration et Installation (33)
précédent sommaire suivant
 

[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.

Mis à jour le 23 août 2014 XxArchangexX

[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.

Mis à jour le 22 août 2014 XxArchangexX

[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.

Mis à jour le 23 août 2014 XxArchangexX

[Traduction de la FAQ officielle]

Voir CassandraHardware.

Mis à jour le 23 août 2014 XxArchangexX

[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.

Code Java : Sélectionner tout
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()); 
}

Quand vous lisez des données venant de Cassandra, vous obtenez un byte[] qui a besoin d’être converti en un TimeUUID, mais comme java.util.UUID ne semble pas disposer d'un moyen simple de le faire, il faut le faire repasser par la méthode eaio uuid dealio.

Code Java : Sélectionner tout
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()); 
}

Quand vous voulez réellement mettre l'UUID dans une colonne, vous devez le convertir de la façon suivante (cette méthode est souvent utilisée conjointement avec la méthode getTimeUUID() mentionnée ci-dessus) :

Code Java : Sélectionner tout
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; 
}

En outre, il est souvent utile de créer un objet TimeUUID à une date autre que la date actuelle : par exemple, pour l’utiliser comme borne inférieure dans un SlicePredicate pour récupérer toutes les colonnes dont le TimeUUID est postérieur à une date donnée. La plupart des bibliothèques ne proposent pas cette fonctionnalité, probablement parce que cela contredit l’aspect "universel" des UUID: cela devrait vous faire réfléchir ! Ne supposez jamais qu’un UUID est unique : utilisez-les uniquement comme identifiant d’un instant donné.
Une fois ces mises en garde faites, si vous avez besoin de créer un TimeUUID basé sur une date précise, voici un code qui fonctionne :

Code Java : Sélectionner tout
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); 
}

Mis à jour le 24 août 2014 XxArchangexX

[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.

Mis à jour le 24 août 2014 XxArchangexX

[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.

Mis à jour le 24 août 2014 XxArchangexX

[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.


Si vous réduisez le ReplicationFactor :

  • 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.

Si vous augmentez le ReplicationFactor :

  • 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.


Mis à jour le 24 août 2014 XxArchangexX

[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.

Mis à jour le 24 août 2014 XxArchangexX

[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.

Mis à jour le 24 août 2014 XxArchangexX

[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.

Mis à jour le 24 août 2014 XxArchangexX

[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.

Mis à jour le 24 août 2014 XxArchangexX

[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.

Une fois que tous les nœuds ont subi cette opération et ont été redémarrés, le nodetool ring devrait afficher que tous les nœuds sont prêts.

Mis à jour le 24 août 2014 XxArchangexX

[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.

Mis à jour le 24 août 2014 XxArchangexX

[Traduction de la FAQ officielle]

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

Mis à jour le 24 août 2014 XxArchangexX

[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.

Mis à jour le 24 août 2014 XxArchangexX

[Traduction de la FAQ officielle]

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

Mis à jour le 24 août 2014 XxArchangexX

[Traduction de la FAQ officielle]

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

Mis à jour le 24 août 2014 XxArchangexX

[Traduction de la FAQ officielle]

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

Mis à jour le 24 août 2014 XxArchangexX

[Traduction de la FAQ officielle]

Voir BulkLoading

Mis à jour le 24 août 2014 XxArchangexX

[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.

Mis à jour le 25 août 2014 XxArchangexX

[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.

Mis à jour le 25 août 2014 XxArchangexX

[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).

Dans le cas d’une SimpleStrategy, les répliques sont placées sur des nœuds successifs de l’anneau. Le premier nœud est déterminé par le partitionneur en fonction de la clef de la ligne et la suite va sur le nœud suivant.
Dans le cas d’une NetworkTopologyStrategy, le placement est affecté par la connaissance topologique qu’a le cluster de ses data centers et châssis (racks), et le placement va dépendre de la façon dont les nœuds des différents châssis et data centers sont placés sur l’anneau.
Il est important de comprendre que Cassandra ne modifie pas le jeu de répliques en fonction de l'évolution des caractéristiques, comme la charge actuelle des divers nœuds, les nœuds actifs ou inactifs, ou le nœud particulier avec lequel votre client parle.

Mis à jour le 25 août 2014 XxArchangexX

[Traduction de la FAQ officielle]

C’est XX %.

Mis à jour le 25 août 2014 Lolo78

[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.

Mis à jour le 26 août 2014 XxArchangexX

[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.

Mis à jour le 26 août 2014 XxArchangexX

[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.

Mis à jour le 26 août 2014 XxArchangexX

[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).

Désinstaller libjna-java ou recompiler Cassandra avec l’appel à la fonction mlockall() de la bibliothèque CLibrary.tryMlockall()'s mis en commentaire semble faire disparaître le problème, mais c’est le genre de correctif dont on préférerait généralement se passer…
Si vous avez plus d’informations sur le problème et avez trouvé une meilleure façon d’y remédier, veuillez apporter votre contribution ici.

Mis à jour le 26 août 2014 XxArchangexX

[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 :

Code : Sélectionner tout
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]
Notez les schémas minoritaires et leurs adresses IP – dans l'exemple ci-dessus, 192.168.1.27. Connectez-vous à chacune de ces machines et arrêtez proprement le service et les processus Cassandra, généralement en lançant :

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

À la fin du processus, le répertoire commit log (/var/lib/cassandra/commitlog) devrait contenir seulement un seul petit fichier.
Supprimer les sstables du schéma* de migration* dans l’espace de clef du système (/var/lib/cassandra/data/system, si vous utilisez celui par défaut).
Après avoir relancé Cassandra, le ou les nœuds concernés vont remarquer les informations manquantes et récupéreront le schéma correct d’un autre nœud. Dans la version 1.0.X et les versions antérieures, les modifications sont appliquées une par une. Au cours de ces modifications, le nœud concerné peut loguer des messages, comme celui ci-dessous, indiquant qu’une colonne ne peut pas être trouvée. Ces messages peuvent être ignorés.
Code : Sélectionner tout
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
Pour confirmer que tous les nœuds ont &#8203;&#8203;le même schéma, vérifiez que la commande « describe cluster » renvoie une seule version du schéma.

Mis à jour le 27 août 2014 XxArchangexX

[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.

Mis à jour le 27 août 2014 XxArchangexX

[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.

Mis à jour le 28 août 2014 XxArchangexX

[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.

Mis à jour le 28 août 2014 XxArchangexX

Proposer une nouvelle réponse sur la FAQ

Ce n'est pas l'endroit pour poser des questions, allez plutôt sur le forum de la rubrique pour ça


Réponse à la question

Liens sous la question
précédent sommaire suivant
 

Les sources présentées sur cette page sont libres de droits et vous pouvez les utiliser à votre convenance. Par contre, la page de présentation constitue une œuvre intellectuelle protégée par les droits d'auteur. Copyright © 2022 Developpez Developpez LLC. Tous droits réservés Developpez LLC. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents et images sans l'autorisation expresse de Developpez LLC. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.