cassandra upgrade datastax cassandra-2.0 cassandra-2.2

Actualización de la versión de Cassandra de 2.0.9 a 2.2



upgrade datastax (2)

¿Pueden existir dos versiones de cassandra (2.0 y 2.2) en un centro de datos?

No, ellos no pueden.

¿Es este proceso lo suficientemente factible o deberíamos ir a la actualización en el lugar?

Tendrá que realizar una actualización en el lugar. Esto se debe a que Cassandra no puede transmitir en todas las versiones. Realizar una actualización en contexto permite que la nueva versión lea los SSTables de la versión anterior.

¿Hay una caída en este enfoque?

Como mencioné, no podrá transmitir datos de sus nodos existentes al nuevo 2.2 DC. Así que el arranque, la reconstrucción y la reparación están fuera de discusión.

El otro problema que tiene, es que 2.2.6 no es "compatible con actualización" con 2.0.9. De este DataStax doc: versiones de Apache Cassandra que requieren actualizaciones intermedias ...

Restricciones de Apache Cassandra 2.2.x.

  • Actualice versiones de Cassandra 2.1 posteriores o equivalentes a 2.1.9 directamente a Cassandra 2.2.x.
  • La actualización directa de Cassandra 2.0 y versiones anteriores no es compatible.

Primero tendrá que actualizar su clúster completo a Cassandra 2.1. Una vez que se complete la actualización a 2.1, puede actualizar sus nodos a 2.2.6.

Estamos planeando actualizar nuestro clúster que actualmente se ejecuta en 2.0.9 a 2.2.6. De acuerdo con la documentación y algunos blogs, las personas actualizan cassandra in situ, es decir, eliminan un nodo del anillo y lo actualizan de nuevo. Somos escépticos de seguir este enfoque ya que las cosas pueden salir mal (Esta es una base de datos de transacciones con un buen número de QPS).

Entonces planeamos agregar un nuevo centro de datos al clúster que habrá actualizado la versión de cassandra (2.2). Entonces la configuración debe tener dos datacenter uno antiguo (2.0.9) y el otro nuevo (2.2.6)

Este centro de datos es solo una copia de seguridad. Cuando el centro de datos se estabilice, cambiaremos la conexión del cliente a este centro de datos y, si funciona bien, iremos a este centro de datos y cerraremos el antiguo centro de datos o, de lo contrario, podremos recurrir al antiguo centro de datos y depurar lo que salió mal.

¿Es este proceso lo suficientemente factible o deberíamos ir a la actualización en el lugar?

¿Pueden existir dos versiones de cassandra (2.0 y 2.2) en un centro de datos?

¿Hay una caída en este enfoque?


Cassandra es un almacén de datos sin master distribuido. Para Cassandra no existe un centro de datos de "respaldo". Si va a agregar otro DC que ejecuta 2.2, está optando por una configuración de clúster de versión mixta, tal como lo haría al actualizar los nodos de forma individual. La única ventaja que veo es que los problemas de rendimiento deberían ser menos probables debido a los nodos añadidos. Sin embargo, agregar otro CD hará que la configuración de su clúster sea más compleja y puede presentar problemas que aún no conoce, pero que no tendrán nada que ver con la ejecución de versiones diferentes. ¿Cómo arrancarías el nuevo DC? ¿Cómo bajará el rendimiento del viejo efecto DC? El impacto operativo será mucho mayor con este enfoque en comparación con la actualización de los nodos individuales.

Si realmente no desea hacer actualizaciones continuas, le sugiero que configure el segundo DC como un clúster separado, importe una copia de seguridad y realice algunas pruebas (de carga). También cambie su código para escribir en ambos clústeres y eventualmente cambie al nuevo si está satisfecho. Si no quiere gastar tanto esfuerzo, simplemente realice la actualización progresiva.