Les données dans Cassandra ne sont pas cohérentes même avec la configuration du Quorum

Question

J'ai rencontré un problème de cohérence en utilisant Hector et Cassandra lorsque nous avons Quorum pour lire et écrire.

J'utilise MultigetSubSliceQuery pour interroger des lignes à partir de la taille limite de super-colonne 100, puis le lire, puis le supprimer. Et commencez un autre autour.

J'ai trouvé que la ligne qui devrait être supprimée par ma requête précédente est toujours affichée à partir de la requête suivante. Et aussi à partir d'une famille de colonnes normale, j'ai mis à jour la valeur d'une colonne de status = 'FALSE' à status = 'TRUE', et la prochaine fois que je l'ai interrogée, le statut était toujours 'FALSE'.

Plus de détails:

1. Il n'a pas passé pas à chaque fois (1/10.000)
2. Le temps entre les deux requêtes est d'environ 500 ms (mais nous avons trouvé une paire de requêtes dans lesquelles 2 secondes s'est écoulé entre eux, indiquant toujours un problème de cohérence)
3. Nous utilisons ntp comme solution de synchronisation de temps de cluster.
4. Nous avons 6 nœuds, et le facteur de réplication est 3

Je comprends que Cassandra est censé être « finalement cohérente », et que lecture ne peut pas se produire avant écrire l'intérieur Cassandra. Mais pour deux secondes ?! Et si c'est le cas, n'est-il pas inutile d'avoir Quorum ou d'autres configurations de niveau de cohérence? Donc, tout d'abord, est-ce le bon comportement de Cassandra, et si non, quelles sont les données que nous devons analyser pour un investissement ultérieur?

Answer 1

Après avoir vérifié le code source avec le journal système, j'ai trouvé la cause première de l'incohérence. Trois facteurs causent le problème:

• Créer et mettre à jour même enregistrement de noeuds différents
• système local temps n'est pas synchronisé avec suffisamment de précision (bien que nous utilisons NTP)
• niveau de cohérence est QUORUM

Voici le problème, prendre comme suite la séquence d'événements

seqID NodeA   NodeB   NodeC 
1.  New(.050)  New(.050)  New(.050) 
2.  Delete(.030) Delete(.030) 

Première Créer demande proviennent de noeud C avec horodatage locale 00: 00: 00,050, on suppose requêtes premier enregistrement nœud A et noeud B, puis plus tard synchronisé avec Noeud C.

Puis Supprimer demande de venir nœud A avec horodatage locale 00: 00: 00,030, et enregistrer dans le nœud Un nœud et B.

Lorsque lu viennent demande, Cassandra fera fusion des conflits de version, mais la fusion ne dépendent que de l'horodatage, donc bien que Supprimer est arrivé après Créer, mais la fusion résultat final est "New "qui a le dernier horodatage en raison de la question de la synchronisation de l'heure locale.

Answer 2

Les lignes supprimées peuvent être montrant comme des « fantômes de gamme » en raison de la façon dont distribué supprime le travail: voir http://wiki.apache.org/cassandra/FAQ#range_ghosts

Si vous lisez et écrire des colonnes individuelles tant au CL_QUORUM, alors vous devriez toujours obtenir consistance totale, quel que soit l'intervalle de temps (à condition que l'ordre strict soit toujours observé, c'est-à-dire que vous êtes certain que la lecture est toujours après l'écriture). Si vous ne voyez pas cela, alors quelque chose, quelque part, est faux. Pour commencer, je suggérerais a) de vérifier que les clients sont correctement synchronisés avec NTP et/ou de reproduire le problème avec des vérifications croisées entre les clients d'une façon ou d'une autre, et b) d'essayer de reproduire le problème avec CL_ALL .

Une autre idée - vos clients sont-ils synchronisés avec NTP, ou seulement avec les nœuds du serveur Cassandra? Rappelez-vous que Cassandra utilise les horodateurs client pour déterminer quelle valeur est la plus récente.

Answer 3

Je rencontre ce problème avec l'un de mes clients/noeud. Les 2 autres clients avec lesquels je suis en train de tester (et 2 autres nœuds) fonctionnent correctement. J'ai un test qui utilise QUORUM dans toutes les lectures et toutes les écritures et il échoue très rapidement. En fait certains processus ne voient rien des autres et d'autres peuvent toujours voir des données même après que je l'ai enlevé.

Dans mon cas, je tourné sur les journaux et destiné à tester l'exploit avec la commande -F queue:

tail -F /var/lib/cassandra/log/system.log 

pour voir si je recevais des erreurs telles que présentées ici. À ma grande surprise le processus de queue lui-même a renvoyé une erreur:

tail: inotify cannot be used, reverting to polling: Too many open files 

et d'un autre fil, cela signifie que certains processus échouera ouverture de fichiers. En d'autres termes, le noeud Cassandra ne répond probablement pas comme prévu car il ne peut pas accéder correctement aux données sur le disque.

Je ne sais pas si c'est lié au problème que l'utilisateur a posté la question, mais tail -F est certainement un bon moyen de déterminer si la limite des fichiers a été atteinte.

(J'ai 5 serveurs relativement lourds fonctionnant sur la même machine donc je ne suis pas trop surpris par le fait que je vais devoir augmenter l'ulimit, je rapporterai ici si je l'ai ainsi fixé)

en savoir plus sur la limite de fichier et l'option de ligne de commande ulimit. https://askubuntu.com/questions/181215/too-many-open-files-how-to-find-the-culprit

Mise à jour 1 ---------

Juste au cas où, j'ai testé en utilisant Java 1.7.0-11 d'Oracle (comme mentionné ci-dessous, j'ai d'abord utilisé une limite de 3000 sans succès!) La même erreur apparaîtrait à peu près au même moment quand runnin g mon test Cassandra (plus même avec le ulimit de 3000 l'erreur -F de la queue semble encore ...)

--------- Mise à jour 2

Ok! Ça a marché. J'ai changé l'ulimit à 32 768 et les problèmes ont disparu. Notez que j'ai dû augmenter la limite par utilisateur en /etc/security/limits.conf et exécuter sudo sysctl -p avant de pouvoir atteindre le maximum d'un nombre aussi élevé. D'une certaine manière la limite supérieure par défaut de 3000 n'était pas suffisante même si l'ancienne limite était seulement 1024.

Answer 4

J'ai également fait face à un problème similaire. Le problème est survenu car le pilote cassandra utilise par défaut l'horodatage du serveur pour vérifier quelle requête est la plus récente. Cependant, dans la dernière version du pilote cassandra, ils l'ont modifié et maintenant, par défaut, ils utilisent l'horodatage du client.

J'ai décrit les détails de l'émission here