sql >> Base de Datos >  >> RDS >> Database

Migración de su clúster de Cassandra

Por Ben Slater , Director de Producto, Instaclustr.

¿Mover una implementación de Apache Cassandra en vivo a una nueva ubicación? Es natural tener algunas preocupaciones, por ejemplo, cómo puede mantener los clústeres de Cassandra 100 % disponibles durante todo el proceso. Pero, el hecho es que si su aplicación puede permanecer en línea durante los cambios en la configuración de la conexión, puede permanecer totalmente disponible durante esta transición. Para mayor protección y tranquilidad, la siguiente técnica también incluye una estrategia de reversión rápida para volver a su configuración original, hasta el momento en que se complete la migración.

Aquí hay un orden de operaciones de migración de clúster Cassandra recomendado de siete pasos que evitará cualquier tiempo de inactividad:

1. Prepare su entorno actual.

En primer lugar, asegúrese de que su aplicación esté utilizando una política de balanceo de carga consciente del centro de datos, así como LOCAL_*. Además, compruebe que todas de los espacios de claves que se copiarán en el nuevo clúster están configurados para usar NetworkTopologyStrategy como su estrategia de replicación. También se recomienda que todos los espacios de claves usen esta estrategia de replicación cuando se creen, porque modificarla más tarde puede volverse complicado.

2. Cree el nuevo clúster.

Ahora es el momento de crear el nuevo clúster al que migrará. Algunas cosas con las que debe tener cuidado:asegúrese de que el nuevo clúster y el clúster original usen la misma versión de Cassandra y el mismo nombre de clúster. Además, el nuevo nombre del centro de datos que utilice debe ser diferente del nombre del centro de datos existente.

3. Únase a los grupos juntos.

Para hacer esto, primero realice los cambios necesarios en las reglas del firewall para permitir que los clústeres se unan, recordando que también pueden ser necesarios algunos cambios en el clúster de origen. Luego, cambie los nodos semilla del nuevo clúster e inícielos. Una vez hecho esto, el nuevo clúster será un segundo centro de datos en el clúster original.

4. Cambie la configuración de replicación.

A continuación, en el clúster existente, actualice la configuración de replicación para los espacios de claves que se copiarán, de modo que los datos ahora se repliquen con el nuevo centro de datos como destino.

5. Copie los datos en el nuevo clúster.

Cuando los clústeres se unen, Cassandra comenzará a replicar escrituras en el nuevo clúster. Sin embargo, aún es necesario copiar los datos existentes con la función de reconstrucción de nodetool. Es una práctica recomendada realizar esta función en el nuevo clúster uno o dos nodos a la vez, para no colocar una carga de transmisión abrumadora en el clúster existente.

6. Cambie los puntos de conexión de la aplicación.

Una vez que se completan todos los usos de la función de reconstrucción, cada uno de los clústeres contendrá una copia completa de los datos que se están migrando, que Cassandra mantendrá sincronizados automáticamente. Ahora es el momento de cambiar los puntos de conexión iniciales de su aplicación a los nodos en el nuevo clúster. Una vez que esto se complete, todas las lecturas y escrituras serán atendidas por el nuevo clúster y, posteriormente, se replicarán en el clúster original. Por último, es inteligente ejecutar una función de reparación en todo el clúster para garantizar que todos los datos se hayan replicado correctamente desde el original.

7. Apague el clúster original.

Complete el proceso con una pequeña limpieza posterior a la migración, eliminando el clúster original. Primero, cambie las reglas del firewall para desconectar el clúster original del nuevo. Luego, actualice la configuración de replicación en el nuevo clúster para detener la replicación de datos en el clúster original. Por último, apague el clúster original.

Y ahí lo tiene:su implementación de Apache Cassandra se ha migrado por completo, sin tiempo de inactividad, bajo riesgo y de una manera completamente transparente desde la perspectiva de sus usuarios finales.

Sobre el autor

Ben Slater es director de productos en Instaclustr, un proveedor de infraestructura de datos de código abierto Apache Cassandra de nivel empresarial, alojada y completamente administrada en la nube.