university tutorial docs curso careers cassandra datastax data-migration downtime

tutorial - Alcanzar cero tiempo de inactividad Migraciones Cassandra/DataStax



download datastax (2)

Los cuatro pasos que ha delineado definitivamente son una opción viable a seguir. También existe la ruta de hacer una instalación binaria rodante simple: https://docs.datastax.com/en/latest-upgrade/upgrade/datastax_enterprise/upgrdCstarToDSE.html

Hablaré en el contexto de los pasos que proporcionó anteriormente. Si tiene curiosidad acerca de la instalación binaria rodante, definitivamente podemos conversar sobre eso también.

Nota: los enlaces a documentos son específicos de Cassandra 3.0 (DataStax 5.0); asegúrese de que las versiones de documentos coincidan con su versión de Cassandra.

Si la principal versión actual de Cassandra es la actual versión principal de Cassandra en DataStax, debería poder agregar los nodos ''DataStax'' como un nuevo DC en el mismo clúster al que pertenece su entorno Cassandra actual: http: //docs.datastax. com / en / cassandra / 3.0 / cassandra / operations / opsAddDCToCluster.html - Esto aportará los datos existentes de Cassandra DC a DataStax DC.

Si no coincide con las versiones de Cassandra (Cassandra actual es más antiguo / más reciente que DataStax Cassandra), entonces puede comunicarse con DataStax a través de https://academy.datastax.com/slack ya que el proceso será más específico para su entorno. y puede variar mucho

Como se describe en los documentos, querrá ejecutar

ALTER KEYSPACE "your-keyspace" WITH REPLICATION = {''class’: ''NetworkTopologyStrategy'', ''OldCassandraDC'':3, ''DataStaxDC'':3};

(obviamente cambiando el nombre de DC y el factor de replicación a sus especificaciones)

Esto asegurará que los nuevos datos de sus productores se replicarán en los nuevos nodos DataStax.

A continuación, puede ejecutar nodetool rebuild -- name_of_existing_data_center desde los nodos DataStax para transmitir datos desde los nodos Cassandra existentes. Dependiendo de la cantidad de datos que haya, puede llevar algo de tiempo, pero es la forma más fácil y fácil de hacerlo.

Luego, desearía actualizar los puntos de contacto en sus productores / consumidores uno por uno antes de desmantelar el viejo Cassandra DC.

Algunos consejos de mi experiencia:

  • Asegúrese de que sus nodos DataStax estén usando GosspingPropertyFileSnitch en cassandra.yaml antes de iniciar esos nodos.
  • Al ejecutar la nodetool rebuild , hágalo con la pantalla para que pueda ver cuándo se completa (o errores). De lo contrario, tendría que supervisar el progreso mediante el uso de nodetool netstats y verificar la actividad de transmisión.
  • Instale y ejecute OpsCenter para supervisar lo que está sucediendo en el clúster DataStax durante las reconstrucciones. Puede vigilar el rendimiento de la transmisión, las compactaciones pendientes y otras métricas específicas de Cassandra.
  • Cuando llega el momento de retirar el DC viejo, asegúrese de seguir estos pasos: http://docs.datastax.com/es/cassandra/3.0/cassandra/operations/opsDecomissionDC.html

¡Espero que ayude!

Tengo un clúster Cassandra (3 nodos, todos los nodos implementados en AWS) que estoy tratando de migrar a un clúster DataStax. Es simplemente el momento de dejar de administrar estos nodos yo mismo.

Tengo múltiples productores y consumidores todos los datos de lectura / escritura, durante todo el día, para mi clúster de Cassandra. No tengo la opción de poner una aplicación / servicio / proxy frente a mi clúster de Cassandra, y luego simplemente mover el interruptor de forma limpia para que todas las lecturas / escrituras vayan a / desde mi Cassandra, a DataStax. Por lo tanto, no hay una forma clara de migrar las tablas de a una por vez. También estoy tratando de lograr un tiempo de inactividad cero (o casi nulo) para todos los productores / consumidores de los datos. Un requisito difícil: la migración no puede ser con pérdida. ¡Sin datos perdidos!

Estoy pensando que la mejor estrategia aquí es un proceso de cuatro pasos:

  1. De alguna manera, configure DataStax para que sea una réplica de mi clúster Cassandra, creando de manera efectiva la replicación de transmisión a DataStax
  2. Una vez que DataStax esté totalmente "atrapado" con los otros nodos en mi Cassandra, mantenga a los productores escribiendo en mi clúster Cassandra actual, pero corte los consumidores / lectores a DataStax (es decir, reconfigúrelos para conectarse a DataStax, y luego reinícielos) ) No es cero el tiempo de inactividad, pero probablemente pueda vivir con un simple reinicio. ( De nuevo, las soluciones de tiempo de inactividad cero son muy preferidas ) .
  3. Cortar a los productores a DataStax. Nuevamente, solo cerca del cero tiempo de inactividad, ya que esto implica reconfigurar a los productores para que apunten a DataStax, y luego requiere un reinicio para recoger las nuevas configuraciones. Se preferirían soluciones de tiempo de inactividad cero.
  4. Una vez que el tráfico de replicación del "antiguo" clúster Cassandra se agota a cero, ahora no tenemos información "nueva" que mis nodos DataStax necesiten escribir en DataStax. Mata esos nodos con fuego.

Esta solución es la más mínimamente invasiva, la solución de tiempo de inactividad más cercano a cero que se me ocurre, pero asume algunas cosas:

  • Quizás no sea posible tratar DataStax como un nodo adicional al que se puede replicar ( sí / no? )
  • Tal vez Cassandra y / o DataStax tienen algunas características / capacidades mágicas que no conozco, que pueden manejar las migraciones mejor que esta solución; o tal vez hay herramientas de terceros (idealmente de código abierto) que podrían manejar esto mejor
  • No tengo idea de cómo controlaría el "tráfico" de replicación proveniente de los "viejos" nodos Cassandra en DataStax. Tendría que saber cómo hacer esto antes de poder cerrar de forma segura + matar los nodos antiguos (de nuevo, no puedo perder datos).

Supongo que me pregunto si esta estrategia es: (1) factible / factible, y (2) óptima; y si hay algunas características / herramientas en el ecosistema Cassandra / DataStax que podría aprovechar para mejorar esto (más rápido y sin tiempo de inactividad).

Supongo que se refiere al producto administrado por Datastax, donde ejecutan cassandra por usted. Si solo quiere decir "ejecutar DSE en sus propias instancias de AWS", puede realizar una actualización binaria in situ.

Las preguntas que hizo se le hacen mejor a Datastax: si va a pagarlas, también puede formularles preguntas (eso es lo que hacen los clientes).

Su enfoque de 4 pasos es bastante lógico, pero probablemente demasiado complejo. La mayoría de los controladores de Casandra descubrirán automáticamente nuevos hosts y desalojarán automáticamente hosts antiguos / salientes, por lo que una vez que tenga todos los nuevos nodos Administrados Datastax en el clúster (suponiendo que lo permitan), puede ejecutar la reparación para garantizar la coherencia y luego retirar su nodos existentes: tu aplicación seguirá funcionando (¿no es genial Cassandra?). Deberá actualizar la configuración de su aplicación para tener los nuevos nodos administrados por Datastax en la configuración / puntos finales de su aplicación, pero eso no necesita hacerse de antemano.

La única advertencia aquí es la latencia involucrada: pasar de su entorno a Datastax Managed puede introducir latencia. En ese caso, tiene un paso intermedio que puede considerar donde agrega los nodos Datastax Managed como un "Datacenter" diferente dentro de cassandra, expande el factor de replicación y usa los niveles de coherencia LOCAL_ para controlar qué DC obtiene las consultas (y luego PUEDE mueva a sus productores / consumidores individualmente).