Veamos el siguiente escenario: una solicitud de escritura se envía a Cassandra, pero un nodo de réplica al que pertenece la escritura, no está disponible debido un problema de la red, falla de hardware o alguna otra razón. Con el fin de garantizar la disponibilidad general del anillo en tal situación, Cassandra implementa una función llamada transferencia indirecta. Se puede pensar en una sugerencia como una pequeña nota Post-it que contiene la información de la solicitud de escritura. Si el nodo de réplica al que pertenece la escritura ha fallado, el coordinador creará una sugerencia, que es un pequeño recordatorio que dice: "Tengo la información de escritura destinada al nodo 4. Voy a recordar esta escritura hasta que el nodo 4 vuelva a estar en línea; cuando lo haga, le enviaré la solicitud de escritura". Es decir, una vez que detecte a través de gossip que el nodo 4 está nuevamente en línea, el nodo 6 entregará al nodo 4 la orden de escritura. Cassandra tiene una sugerencia diferente para cada partición que se va a escribir.
Esto permite que Cassandra esté siempre disponible para escrituras, y generalmente permite que un clúster sostenga la misma carga de escritura incluso cuando algunos de los nodos están inactivos. También reduce el tiempo en que un nodo fallido será inconsistente después de que vuelva a estar en línea.
En general, las sugerencias no cuentan como escrituras para propósitos de nivel de consistencia. La excepción es el nivel de consistencia ANY, que se agregó en 0.6. Este nivel de consistencia significa que un traspaso indirecto solo será suficiente para el éxito de una operación de escritura. Es decir, incluso si solo se pudo grabar una pista, la escritura todavía cuenta como exitosa. Tenga en cuenta que la escritura se considera duradera, pero es posible que los datos no se puedan leer hasta que la sugerencia se envíe a la réplica de destino.
Existe un problema práctico con las transferencia indirecta (y, en este caso, los enfoques de entrega garantizados): si un nodo está fuera de línea durante algún tiempo, los consejos pueden acumularse considerablemente en otros nodos. Luego, cuando los otros nodos notan que el nodo fallado ha vuelto a estar en línea, tienden a inundar ese nodo con solicitudes, justo en el momento en que es más vulnerable (cuando está luchando para volver a trabajar después de una falla). Para resolver este problema, Cassandra limita el almacenamiento de sugerencias a una ventana de tiempo configurable. También es posible deshabilitar el traspaso insinuado por completo.
Como su nombre lo sugiere, org.apache.cassandra.db.HintedHandOffManager es la clase
que gestiona las transferencias indirectas internamente.
Aunque la Transferencia indirecta ayuda a aumentar la disponibilidad de Cassandra, no reemplaza completamente la necesidad de reparación manual para garantizar la consistencia.
