Le transfert indiqué est simplement une mesure anti-entropie supplémentaire. c'est-à-dire que vous n'avez pas besoin d'effectuer des réparations immédiatement et que les données sont cohérentes (en cas de panne mineure) lorsque le nœud revient en ligne.
Je suppose que ce serait simplement trop compliqué de prendre soin de cela avec la réplication tout le temps parce que vous auriez à marquer d'une manière ou d'une autre les données qui n'ont pas été répliquées etc. Fondamentalement vous auriez encore quelque chose de semblable au transfert suggéré .
Quelques trucs de documents officiels: https://docs.datastax.com/en/cassandra/2.1/cassandra/dml/dml_about_hh_c.html#concept_ds_ifg_jqx_zj__extreme-write-availability
Fondamentalement, il est de maximiser le débit d'écriture du cluster alors qu'il ya des pannes mineures. Il est configurable et vous pouvez le désactiver dans le cas où vous avez décrit quand il y a des niveaux de cohérence élevés impliqués à la fois en lecture et en écriture.
De plus, vous devez exécuter la "répétition", c'est-à-dire réparer de toute façon. Parce que le transfert suggéré ne peut pas vraiment prendre soin de tout cela. Personnellement, je les ai utilisés dans une situation R-CL: ONE, W-CL: ONE, RF: 2, NODES: 3. Ils ont été très utiles car nous avons maintenu le débit d'écriture pendant la maintenance et le redémarrage du cluster . Donc, je dirais que cela fonctionne bien dans une situation où W-CL < RF.
Là encore il y a des opinions comme celui-ci:
https://blog.threatstack.com/scaling-cassandra-lessons-learned
En fait, il suffit de les désactiver dans la configuration. Il est trop facile de perdre des données pendant une panne prolongée ou un pic de charge, et si un nœud tombe en panne à cause du pic de charge, vous allez simplement contourner le problème autour de l'anneau, en supprimant plusieurs ou tous les nœuds. Nous n'avons jamais expérimenté cela sur Cassandra, mais nous l'avons fait sur d'autres systèmes supportant des transferts suggérés.
Merci beaucoup pour la réponse! J'ai encore quelques questions. Comment HH optimise-t-elle le débit d'écriture? Pourquoi Cassandra demande-t-elle aux gens de faire la réparation manuellement plutôt que de programmer une réparation automatique régulière (comme la réparation en lecture)? – roymaztang
Fondamentalement, la réparation est une opération coûteuse, car toutes les données doivent être comparées à l'arbre de merkle, donc c'est aux administrateurs de planifier. Il y a même des outils qui le font automatiquement comme https://github.com/spotify/cassandra-reaper. Plus ou moins ce processus devrait s'exécuter une fois avec la période gc_grace pour garder les données cohérentes. La maximisation est faite indirectement. Lorsqu'un nœud tombe en panne, il n'accepte pas les écritures. Si le nœud du coordinateur les enregistre (opération bon marché) après le retour du nœud, vous avez la même quantité d'enregistrements écrits partout dans le cluster que si le nœud était là tout le temps. –