Cassandra Commit et de récupération sur un seul noeud

Question

Je suis un débutant à Cassandra - J'ai été à la recherche d'informations liées aux commits et la récupération après un crash dans Cassandra sur un seul noeud. Et, en espérant que quelqu'un puisse clarifier les détails.

Je teste Cassandra - donc, configurez-le sur un seul noeud. J'utilise stresstool sur datastax pour insérer des millions de lignes. Que se passe-t-il en cas de panne électrique ou d'arrêt du système? Est-ce que toutes les données qui étaient dans la mémoire de Cassandra seront écrites sur le disque lors du redémarrage de Cassandra (je suppose que commitlog agit en tant qu'intermédiaire)? Combien de temps dure ce processus?

Merci!

Answer 1

Le journal de validation de Cassandra offre des écritures durables à Cassandra. Lorsque vous écrivez dans Cassandra, l'écriture est ajoutée au journal de validation avant que l'écriture ne soit reconnue au client. Cela signifie que chaque écriture pour laquelle le client reçoit une réponse réussie est garantie d'être écrite dans le journal de validation. L'écriture est également effectuée sur la memtable actuelle, qui sera éventuellement écrite sur le disque en tant que SSTable lorsqu'elle est suffisamment grande. Cela pourrait être long après l'écriture. Toutefois, le journal de validation n'est pas immédiatement synchronisé sur le disque pour des raisons de performances. La valeur par défaut est le mode périodique (défini par le paramètre commitlog_sync dans cassandra.yaml) avec une période de 10 secondes (définie par commitlog_sync_period_in_ms dans cassandra.yaml). Cela signifie que le journal de validation est synchronisé sur le disque toutes les 10 secondes. Avec ce comportement, vous pouvez perdre jusqu'à 10 secondes d'écritures si le serveur perd de la puissance. Si vous avez plusieurs nœuds dans votre cluster et que vous utilisez un facteur de réplication supérieur à un, vous devez perdre l'alimentation de plusieurs nœuds en moins de 10 secondes pour perdre des données.

Si cette fenêtre de risque n'est pas acceptable, vous pouvez utiliser le mode de traitement par lots pour le journal de validation. Ce mode ne reconnaît pas les écritures sur le client tant que le journal de validation n'a pas été synchronisé sur le disque. La fenêtre de temps est définie par commitlog_sync_batch_window_in_ms, la valeur par défaut est 50 ms. Cela augmentera significativement votre latence d'écriture et diminuera probablement aussi le débit, donc utilisez-le uniquement si le coût de la perte de quelques écritures reconnues est élevé. Il est particulièrement important de stocker votre journal de validation sur un lecteur distinct lorsque vous utilisez ce mode.

En cas de panne d'alimentation de votre serveur, Cassandra relance le journal de validation au démarrage pour reconstruire sa mémoire. Ce processus prendra quelques secondes (éventuellement des minutes) sur des serveurs très lourds.

Si vous souhaitez vous assurer que les données contenues dans les memtables sont écrites sur le disque, vous pouvez exécuter 'nodetool flush' (ceci fonctionne par noeud). Cela créera un nouveau SSTable et supprimera les journaux de validation faisant référence aux données dans les memtables vidées.

Answer 2

Vous demandez quelque chose comme

1. Qu'arrive t-il s'il y a une défaillance du réseau au moment où les données est en cours de chargement dans Oracle en utilisant SQL * Loader?
2. Ou ce qui se passe Sqoop arrête le traitement en raison de certaines conditions lors du transfert de données?

Simplement, quelles que soient les données transférées avant la panne électrique ou l'arrêt du système, elles resteront les mêmes. Venant à la deuxième question, lorsque la mémoire est vide, c'est-à-dire lorsque le nombre de clés dépasse une certaine limite (128 est la valeur par défaut) ou quand elle atteint la durée (horloge du cluster), elle est stockée dans sstable , espace immuable.