Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# Creación de un plan de migración para migrar de Apache Cassandra a Amazon Keyspaces
Para que la migración de Apache Cassandra a Amazon Keyspaces se realice correctamente, recomendamos revisar los conceptos y las prácticas recomendadas de migración aplicables, así como comparar las opciones disponibles.
En este tema se describe cómo funciona el proceso de migración y se presentan varios conceptos clave y las herramientas y técnicas que tiene a su disposición. Puede evaluar las diferentes estrategias de migración para seleccionar la que mejor se adapte a sus necesidades.
**Topics**
+ [Compatibilidad funcional](#migrating-cassandra-compatibility)
+ [Estimación de precios de Amazon Keyspaces](#migrating-cassandra-sizing)
+ [Elección de una estrategia de migración](#migrating-cassandra-strategy)
+ [Migración online a Amazon Keyspaces: estrategias y prácticas recomendadas](migrating-online.md)
+ [Proceso de migración sin conexión: de Apache Cassandra a Amazon Keyspaces](migrating-offline.md)
+ [Uso de una solución de migración híbrida: de Apache Cassandra a Amazon Keyspaces](migrating-hybrid.md)
## Compatibilidad funcional
Analice detenidamente las diferencias funcionales entre Apache Cassandra y Amazon Keyspaces antes de la migración. Amazon Keyspaces admite todas las operaciones del plano de datos de Cassandra de uso habitual, como la creación de espacios de claves y tablas, y la lectura y escritura de datos.
Sin embargo, hay algunas Cassandra APIs que Amazon Keyspaces no admite. Para obtener más información acerca de lo compatible APIs, consulte. [Cassandra APIs, operaciones, funciones y tipos de datos compatibles](cassandra-apis.md) Para obtener información general sobre todas las diferencias funcionales entre Amazon Keyspaces y Apache Cassandra, consulte [Diferencias funcionales: Amazon Keyspaces vs. Apache Cassandra](functional-differences.md).
Para comparar el Cassandra APIs y el esquema que está utilizando con las funciones compatibles en Amazon Keyspaces, puede ejecutar un script de compatibilidad disponible en el kit de herramientas de Amazon Keyspaces. [GitHub](https://github.com/aws-samples/amazon-keyspaces-toolkit/blob/master/bin/toolkit-compat-tool.py)
**Uso del script de compatibilidad**
1. Descargue el script de Python de compatibilidad [GitHub](https://github.com/aws-samples/amazon-keyspaces-toolkit/blob/master/bin/toolkit-compat-tool.py)y muévalo a una ubicación que tenga acceso a su clúster de Apache Cassandra existente.
1. El script de compatibilidad usa parámetros similares a `CQLSH`. Para `--host` y `--port`, introduzca la dirección IP y el puerto que utilice para conectarse y ejecutar consultas a uno de los nodos de Cassandra del clúster.
Si su clúster de Cassandra usa autenticación, también debe proporcionar `-username` y `-password`. Para utilizar el script de compatibilidad, puede ejecutar el siguiente comando.
```
python toolkit-compat-tool.py --host hostname or IP -u "username" -p "password" --port native transport port
```
## Estimación de precios de Amazon Keyspaces
En esta sección se proporciona información general de la información que debe recopilar de las tablas de Apache Cassandra para calcular el costo estimado de Amazon Keyspaces. Cada una de sus tablas requiere diferentes tipos de datos, debe admitir diferentes consultas de CQL y mantiene un tráfico distintivo read/write .
Plantearse sus requisitos en función de las tablas se ajusta a los modos de aislamiento de recursos de nivel de tabla y de [capacidad de rendimiento de lectura/escritura](ReadWriteCapacityMode.md) de Amazon Keyspaces. Con Amazon Keyspaces, puede definir la capacidad de lectura/escritura y las [políticas de escalado automático](autoscaling.md) para las tablas de forma independiente.
Comprender los requisitos de las tablas le ayuda a priorizarlas para la migración según la funcionalidad, el costo y el esfuerzo de migración.
Recopile las siguientes métricas de la tabla de Cassandra antes de una migración. Esta información ayuda a estimar el costo de la carga de trabajo en Amazon Keyspaces.
+ **Nombre de la tabla**: el nombre completo del espacio de claves y de la tabla.
+ **Descripción**: descripción de la tabla, por ejemplo, cómo se usa o qué tipo de datos se almacenan en ella.
+ **Promedio de lecturas por segundo**: el número medio de lecturas en las coordenadas para la tabla durante un intervalo de tiempo amplio.
+ **Promedio de escrituras por segundo**: el número medio de escrituras en las coordenadas para la tabla durante un intervalo de tiempo amplio.
+ **Promedio de tamaño de fila en bytes**: tamaño medio de fila en bytes.
+ **Tamaño de almacenamiento en GBs**: el tamaño de almacenamiento sin procesar de una tabla.
+ **Desglose de coherencia de lectura**: el porcentaje de lecturas que utilizan coherencia posterior (`LOCAL_ONE` o `ONE`) frente a las que utilizan coherencia sólida (`LOCAL_QUORUM`).
En esta tabla se muestra un ejemplo de la información relativa a las tablas que debe reunir al planificar una migración.
****
| Nombre de la tabla | Description (Descripción) | Promedio de lecturas por segundo | Promedio de escrituras por segundo | Promedio de tamaño de fila en bytes | Tamaño de almacenamiento en GBs | Desglose de coherencia de lectura |
| --- | --- | --- | --- | --- | --- | --- |
| mykeyspace.mytable | Se usa para almacenar el historial del carrito de la compra | 10 000 | 5 000 | 2.200 | 2,000 | 100% `LOCAL_ONE` |
| mykeyspace.mytable 2 | Se utiliza para almacenar la información de perfil más reciente | 20 000 | 1 000 | 850 | 1 000 | 25 % `LOCAL_QUORUM` 75 % `LOCAL_ONE` |
### Recopilación de las métricas de las tablas
En esta sección, se proporcionan instrucciones paso a paso sobre cómo recopilar las métricas de tabla necesarias del clúster de Cassandra existente. Estas métricas incluyen el tamaño de la fila, el tamaño de la tabla y read/write las solicitudes por segundo (RPS). Le permiten evaluar los requisitos de capacidad de rendimiento para una tabla de Amazon Keyspaces y estimar los precios.
**Recopilación de las métricas de la tabla de origen de Cassandra**
1. Determinación del tamaño de fila
El tamaño de fila es importante para determinar el uso de la capacidad de lectura y escritura en Amazon Keyspaces. En el siguiente diagrama se muestra la distribución de datos típica en un rango de tokens de Cassandra.
![\[Un diagrama en el que se muestra la distribución de datos típica en un rango de tokens de Cassandra con el particionador murmur3.\]](http://docs.aws.amazon.com/es_es/keyspaces/latest/devguide/images/migration/migration-data-distribution.png)
Puede usar un script de muestreo de tamaño de fila disponible [GitHub](https://github.com/aws-samples/amazon-keyspaces-toolkit/blob/master/bin/row-size-sampler.sh)para recopilar métricas de tamaño de fila para cada tabla de su clúster de Cassandra.
El script exporta los datos de la tabla desde Apache Cassandra utilizando `cqlsh` y `awk` para calcular la desviación mínima, máxima, media y estándar del tamaño de la fila sobre un conjunto configurable de datos de tabla de muestra. El muestreador de tamaño de fila pasa los argumentos a `cqlsh`, por lo que se pueden usar los mismos parámetros para conectarse y leer desde el clúster de Cassandra.
La siguiente instrucción es un ejemplo de ello.
```
./row-size-sampler.sh 10.22.33.44 9142 \\
-u "username" -p "password" --ssl
```
Para obtener más información sobre cómo se calcula el tamaño de las filas en Amazon Keyspaces, consulte [Estimación del tamaño de las filas en Amazon Keyspaces](calculating-row-size.md).
1. Determinación del tamaño de las tablas
Con Amazon Keyspaces, no es necesario aprovisionar el almacenamiento por adelantado. Amazon Keyspaces supervisa continuamente el tamaño facturable de sus tablas para determinar sus cargos por almacenamiento. El almacenamiento se factura por GB al mes. El tamaño de tabla de Amazon Keyspaces se basa en el tamaño sin procesar (sin comprimir) de una sola réplica.
Para supervisar el tamaño de tabla en Amazon Keyspaces, puede utilizar la métrica `BillableTableSizeInBytes`, que se muestra para cada tabla en la Consola de administración de AWS.
Para calcular el tamaño facturable de la tabla de Amazon Keyspaces, puede usar uno de estos dos métodos:
+ Utilizar el tamaño de fila promedio y multiplicar por el número de filas.
Puede estimar el tamaño de la tabla de Amazon Keyspaces multiplicando el tamaño medio de las filas por el número de filas de la tabla de origen de Cassandra. Utilizar el script de muestra de tamaño de fila de la sección anterior para registrar el tamaño medio de las filas. Para registrar el recuento de filas, puede utilizar herramientas como `dsbulk count` para determinar el número total de filas de la tabla de origen.
+ Utilizar `nodetool` para recopilar los metadatos de la tabla.
`Nodetool` es una herramienta administrativa incluida en la distribución de Apache Cassandra que proporciona información sobre el estado del proceso de Cassandra y devuelve los metadatos de la tabla. Puede utilizar `nodetool` para muestrear metadatos sobre el tamaño de la tabla y, con ello, extrapolar el tamaño de la tabla en Amazon Keyspaces.
El comando que se debe utilizar es `nodetool tablestats`. Tablestats devuelve el tamaño y la relación de compresión de la tabla. El tamaño de la tabla se guarda como el `tablelivespace` de la tabla y se puede dividir por la `compression ratio`. A continuación, multiplique este valor de tamaño por la cantidad de nodos. Por último, divida por el factor de replicación (normalmente es tres).
Esta es la fórmula completa del cálculo que puede utilizar para evaluar el tamaño de la tabla.
```
((tablelivespace / compression ratio) * (total number of nodes))/ (replication factor)
```
Supongamos que su clúster de Cassandra tiene 12 nodos. Al ejecutar el comando `nodetool tablestats`, se obtiene un `tablelivespace` de 200 GB y una `compression ratio` de 0,5. El espacio de claves tiene un factor de replicación de tres.
Este es el aspecto que tiene el cálculo para este ejemplo.
```
(200 GB / 0.5) * (12 nodes)/ (replication factor of 3)
= 4,800 GB / 3
= 1,600 GB is the table size estimate for Amazon Keyspaces
```
1. Registro del número de lecturas y escrituras
Para determinar los requisitos de capacidad y escalado de las tablas de Amazon Keyspaces, registre la tasa de solicitudes de lectura y escritura de las tablas de Cassandra antes de la migración.
Amazon Keyspaces se ejecuta sin servidor y solo se paga por lo que se usa. En general, el precio del read/write rendimiento en Amazon Keyspaces depende del número y el tamaño de las solicitudes.
Existen dos modos de capacidad en Amazon Keyspaces:
+ [Bajo demanda](ReadWriteCapacityMode.OnDemand.md): se trata de una opción de facturación flexible que permite atender miles de solicitudes por segundo sin tener que planificar la capacidad. Ofrece pay-per-request precios para las solicitudes de lectura y escritura, de modo que solo pague por lo que utilice.
+ [Aprovisionado](ReadWriteCapacityMode.Provisioned.md): si elige el modo de capacidad de rendimiento aprovisionado, especifica el número de lecturas y escrituras por segundo que se requieren para su aplicación. Esto le ayuda a gestionar el uso de Amazon Keyspaces para que se mantenga igual o inferior a una tasa de solicitudes definida a fin de mantener la previsibilidad.
El modo aprovisionado ofrece [escalado automático](autoscaling.md) para ajustar automáticamente la tasa aprovisionada para escalarla automática o verticalmente con el fin de mejorar la eficiencia operativa. Para obtener más información sobre la administración de recursos sin servidor, consulte [Administración de recursos sin servidor en Amazon Keyspaces (para Apache Cassandra)](serverless_resource_management.md).
Como la capacidad de rendimiento de lectura y escritura se aprovisiona por separado en Amazon Keyspaces, debe medir la tasa de solicitudes de lectura y escritura en sus tablas existentes de forma independiente.
Para recopilar las métricas de uso más precisas del clúster de Cassandra actual, registre el promedio de solicitudes por segundo (RPS) para las operaciones de lectura y escritura en el coordinador durante un período prolongado para obtener una tabla en la que aparezcan combinados todos los nodos de un solo centro de datos.
Al registrar el promedio de RPS durante un período de al menos varias semanas, quedan registrados los picos y valles de los patrones de tráfico, como se muestra en el siguiente diagrama.
![\[Un diagrama que muestra la tasa media de solicitudes por segundo y día durante un período de dos semanas.\]](http://docs.aws.amazon.com/es_es/keyspaces/latest/devguide/images/migration/migration-rps.png)
Tienes dos opciones para determinar la tasa de solicitudes de lectura y escritura de una tabla de Cassandra.
+ Utilizar la supervisión de Cassandra existente
Puede usar las métricas que se muestran en la siguiente tabla para observar las solicitudes de lectura y escritura. Tenga en cuenta que los nombres de las métricas pueden cambiar en función de la herramienta de supervisión que utilice.
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/keyspaces/latest/devguide/migrating-cassandra.html)
+ Utilizar `nodetool`
Utilice `nodetool tablestats` y `nodetool info` para registrar el promedio de operaciones de lectura y escritura de la tabla. `tablestats` devuelve el recuento total de lecturas y escrituras desde el momento en que se inició el nodo. `nodetool info` proporciona el tiempo de actividad de un nodo en segundos.
Para obtener el promedio de lecturas y escrituras por segundo, divida el recuento de lectura y escritura por el tiempo de actividad del nodo en segundos. A continuación, para las lecturas, se divide por el nivel de consistencia, y para las escrituras, se divide por el factor de replicación. Estos cálculos se expresan en las siguientes fórmulas.
Fórmula para el promedio de lecturas por segundo:
```
((number of reads * number of nodes in cluster) / read consistency quorum (2)) / uptime
```
Fórmula para el promedio de escrituras por segundo:
```
((number of writes * number of nodes in cluster) / replication factor of 3) / uptime
```
Supongamos que tenemos un clúster de 12 nodos que ha estado activo durante 4 semanas. `nodetool info` devuelve 2 419 200 segundos de tiempo de actividad y `nodetool tablestats` devuelve 1000 millones de escrituras y 2000 millones de lecturas. Este ejemplo daría como resultado el siguiente cálculo.
```
((2 billion reads * 12 in cluster) / read consistency quorum (2)) / 2,419,200 seconds
= 12 billion reads / 2,419,200 seconds
= 4,960 read request per second
((1 billion writes * 12 in cluster) / replication factor of 3) / 2,419,200 seconds
= 4 billion writes / 2,419,200 seconds
= 1,653 write request per second
```
1. Determinación del uso de la capacidad de la tabla
Para estimar el uso promedio de la capacidad, comience con el promedio de las tasas de solicitud y el promedio del tamaño de fila de la tabla de origen de Cassandra.
Amazon Keyspaces utiliza unidades de *capacidad de lectura (RCUs) y unidades* de *capacidad de escritura* (WCUs) para medir la capacidad de rendimiento aprovisionada para lecturas y escrituras en tablas. Para esta estimación, utilizamos estas unidades para calcular las necesidades de capacidad de lectura y escritura de la nueva tabla de Amazon Keyspaces tras la migración.
Más adelante en este tema analizaremos cómo afecta a la facturación la elección entre el modo de capacidad aprovisionada y el modo de capacidad bajo demanda. Sin embargo, para estimar el uso de la capacidad en este ejemplo, suponemos que la tabla está en modo aprovisionado.
+ **Lecturas**: una RCU representa una solicitud de lectura `LOCAL_QUORUM` o dos solicitudes de lectura `LOCAL_ONE` para una fila de hasta 4 KB de tamaño. Si necesita leer una fila con un tamaño superior a 4 KB, la operación de lectura utiliza más. RCUs El número total de elementos RCUs necesarios depende del tamaño de la fila y de si desea mantener la coherencia `LOCAL_QUORUM` o la coherencia de `LOCAL_ONE` lectura.
Por ejemplo, para leer una fila de 8 KB se necesitan 2 RCUs unidades con coherencia de `LOCAL_QUORUM` lectura y 1 RCU si elige la coherencia de `LOCAL_ONE` lectura.
+ **Escrituras**: una WCU representa una escritura para una fila de hasta 1 KB de tamaño. Todas las escrituras utilizan `LOCAL_QUORUM` la coherencia y no se aplica ningún cargo adicional por el uso de transacciones ligeras (LWTs).
La cantidad total WCUs requerida depende del tamaño de la fila. Si necesita escribir una fila de más de 1 KB, la operación de escritura utiliza más WCUs. Por ejemplo, si el tamaño de la fila es de 2 KB, necesitará 2 WCUs para realizar una solicitud de escritura.
Se puede usar la siguiente fórmula para estimar el RCUs y requerido WCUs.
+ **La capacidad de lectura** se RCUs puede determinar multiplicando las lecturas por segundo por el número de filas leídas por lectura, multiplicado por el tamaño medio de fila dividido entre 4 KB y redondeado al número entero más cercano.
+ **La capacidad de escritura** se WCUs puede determinar multiplicando el número de solicitudes por el tamaño medio de fila dividido por 1 KB y redondeado al número entero más cercano.
Esto se expresa en las siguientes fórmulas.
```
Read requests per second * ROUNDUP((Average Row Size)/4096 per unit) = RCUs per second
Write requests per second * ROUNDUP(Average Row Size/1024 per unit) = WCUs per second
```
Por ejemplo, si realiza 4.960 solicitudes de lectura con un tamaño de fila de 2,5 KB en su tabla de Cassandra, necesitará 4.960 en RCUs Amazon Keyspaces. Si actualmente realizas 1 653 solicitudes de escritura por segundo con un tamaño de fila de 2,5 KB en tu tabla de Cassandra, necesitas 4 959 por WCUs segundo en Amazon Keyspaces.
Este ejemplo se expresa en las siguientes fórmulas.
```
4,960 read requests per second * ROUNDUP( 2.5KB /4KB bytes per unit)
= 4,960 read requests per second * 1 RCU
= 4,960 RCUs
1,653 write requests per second * ROUNDUP(2.5KB/1KB per unit)
= 1,653 requests per second * 3 WCUs
= 4,959 WCUs
```
El uso de `eventual consistency` permite ahorrar hasta la mitad de la capacidad de rendimiento en cada solicitud de lectura. Cada lectura coherente posterior puede consumir hasta 8 KB. Puede calcular las lecturas coherentes posteriores multiplicando el cálculo anterior por 0,5, tal y como se muestra en la siguiente fórmula.
```
4,960 read requests per second * ROUNDUP( 2.5KB /4KB per unit) * .5
= 2,480 read request per second * 1 RCU
= 2,480 RCUs
```
1. Cálculo del precio mensual estimado para Amazon Keyspaces
Para calcular la facturación mensual de la tabla en función del rendimiento de la read/write capacidad, puede calcular los precios del modo bajo demanda y del modo aprovisionado mediante distintas fórmulas y comparar las opciones de la tabla.
**Modo aprovisionado**: el consumo de la capacidad de lectura y escritura se factura según una tarifa por hora basada en las unidades de capacidad por segundo. En primer lugar, divida esa tasa entre 0,7 para representar el objetivo de utilización predeterminado del escalado automático, que es del 70 %. Luego se debe multiplicar por 30 días naturales, 24 horas por día y los precios de las tarifas regionales.
Este cálculo se resume en las siguientes fórmulas.
```
(read capacity per second / .7) * 24 hours * 30 days * regional rate
(write capacity per second / .7) * 24 hours * 30 days * regional rate
```
**Modo bajo demanda**: la capacidad de lectura y escritura se factura según una tarifa por solicitud. En primer lugar, multiplique la tasa de solicitudes por 30 días naturales y 24 horas por día. A continuación, divida el resultado por un millón de unidades de solicitud. Por último, multiplique el resultado por la tarifa regional.
Este cálculo se resume en las siguientes fórmulas.
```
((read capacity per second * 30 * 24 * 60 * 60) / 1 Million read request units) * regional rate
((write capacity per second * 30 * 24 * 60 * 60) / 1 Million write request units) * regional rate
```
## Elección de una estrategia de migración
Puede elegir entre las siguientes estrategias de migración al migrar de Apache Cassandra a Amazon Keyspaces:
+ **En línea**: se trata de una migración en directo que utiliza escrituras duales para empezar a escribir nuevos datos en Amazon Keyspaces y en el clúster de Cassandra de forma simultánea. Este tipo de migración se recomienda para las aplicaciones que requieren cero tiempo de inactividad durante la migración y que requieren coherencia de lectura tras la escritura.
Para obtener más información sobre cómo planificar e implementar una estrategia de migración en línea, consulte [Migración online a Amazon Keyspaces: estrategias y prácticas recomendadas](migrating-online.md).
+ **Sin conexión**: esta técnica de migración implica copiar un conjunto de datos de Cassandra a Amazon Keyspaces durante un tiempo de inactividad. La migración sin conexión puede simplificar el proceso de migración, ya que no requiere cambios en la aplicación ni la resolución de conflictos entre los datos históricos y las nuevas escrituras.
Para obtener más información sobre cómo planificar una migración sin conexión, consulte [Proceso de migración sin conexión: de Apache Cassandra a Amazon Keyspaces](migrating-offline.md).
+ **Híbrida**: esta técnica de migración permite replicar los cambios en Amazon Keyspaces prácticamente en tiempo real, pero sin coherencia de lectura tras la escritura.
Para obtener más información sobre cómo planificar una migración híbrida, consulte [Uso de una solución de migración híbrida: de Apache Cassandra a Amazon Keyspaces](migrating-hybrid.md).
Tras revisar las técnicas de migración y las prácticas recomendadas que se describen en este tema, puede colocar las opciones disponibles en un árbol de decisiones para diseñar una estrategia de migración en función de sus requisitos y de los recursos disponibles.
# Migración online a Amazon Keyspaces: estrategias y prácticas recomendadas
Si necesita mantener la disponibilidad de las aplicaciones durante una migración de Apache Cassandra a Amazon Keyspaces, puede preparar una estrategia de migración en línea personalizada mediante la implementación de los componentes clave que se describen en este tema. Si sigue estas prácticas recomendadas para las migraciones en línea, puede garantizar que la disponibilidad y la read-after-write coherencia de las aplicaciones se mantengan durante todo el proceso de migración, lo que minimiza el impacto en los usuarios.
Al diseñar una estrategia de migración en línea de Apache Cassandra a Amazon Keyspaces, debe tener en cuenta los siguientes pasos clave.
1. **Escritura de nuevos datos**
+ Proxy de **escritura doble de ZDM para la migración de Amazon Keyspaces: utilice el proxy** de escritura doble de ZDM disponible [en](https://github.com/aws-samples/amazon-keyspaces-examples/blob/main/migration/online/zdm-proxy/README.md) Github para realizar una migración sin tiempo de inactividad de Apache Cassandra a Amazon Keyspaces. El proxy ZDM realiza escrituras duales sin necesidad de refactorizar las aplicaciones existentes y realiza lecturas duales para validar las consultas.
+ Escrituras duales de aplicación: puede implementar escrituras duales en su aplicación utilizando las bibliotecas de clientes y los controladores existentes de Cassandra. Designe una base de datos como líder y la otra como seguidora. Los errores de escritura en la base de datos seguidora se registran en una [cola de mensajes fallidos (DLQ)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html) para su análisis.
+ Escrituras duales en el nivel de mensajería: también puede configurar su plataforma de mensajería existente para enviar escrituras tanto a Cassandra como a Amazon Keyspaces con un consumidor adicional. Con el tiempo, esto crea vistas coherentes en ambas bases de datos.
1. **Migración de datos históricos**
+ Copia de datos históricos: puede migrar datos históricos de Cassandra a Amazon Keyspaces con AWS Glue o mediante scripts de extracción, transformación y carga (ETL) personalizados. Administre la resolución de conflictos entre escrituras duales y cargas en lotes mediante técnicas como las transacciones simplificadas o las marcas de tiempo.
+ Uso Time-To-Live (TTL): para períodos de retención de datos más cortos, puede usar TTL tanto en Cassandra como en Amazon Keyspaces para evitar cargar datos históricos innecesarios. A medida que los datos antiguos caducan en Cassandra y se escriben datos nuevos mediante escrituras duales, Amazon Keyspaces acaba poniéndose al día.
1. **Validación de los datos**
+ Lecturas duales: implemente lecturas duales tanto desde las bases de datos de Cassandra (principal) como desde las de Amazon Keyspaces (secundaria) y compare los resultados de forma asíncrona. Las diferencias se registran o se envían a una DLQ.
+ Lecturas de ejemplo: utilice funciones λ para muestrear y comparar periódicamente los datos entre ambos sistemas y registrar cualquier discrepancia en una DLQ.
1. **Migración de la aplicación**
+ Estrategia azul-verde: modifique su aplicación para que trate Amazon Keyspaces como el almacén de datos principal y Cassandra como el almacén de datos secundario en un solo paso. Supervise el rendimiento y deshaga esas modificaciones en caso de que surjan problemas.
+ Implementación canario: primero implemente gradualmente la migración a un subconjunto de usuarios, aumentando gradualmente el tráfico a Amazon Keyspaces como principal hasta que se migre por completo.
1. **Retirada de Cassandra**
Una vez que su aplicación se haya migrado por completo a Amazon Keyspaces y se haya validado la coherencia de datos, puede planificar la retirada del clúster de Cassandra en función de las políticas de retención de datos.
Si planifica una estrategia de migración en línea con estos componentes, podrá realizar una transición fluida al servicio de Amazon Keyspaces totalmente administrado con un tiempo de inactividad o interrupción mínimos. En las siguientes secciones se aborda cada componente de manera detallada.
**Topics**
+ [Escritura de nuevos datos durante una migración en línea](migration-online-dw.md)
+ [Carga de datos históricos durante una migración en línea](migration-online-historical.md)
+ [Validación de la coherencia de datos durante una migración en línea](migration-online-validation.md)
+ [Migración de la aplicación durante una migración en línea](migration-online-app-migration.md)
+ [Retirada de Cassandra tras una migración en línea](migration-online-decommission.md)
# Escritura de nuevos datos durante una migración en línea
El primer paso de un plan de migración en línea consiste en garantizar que cualquier dato nuevo que escriba la aplicación se almacene en ambas bases de datos, en el clúster de Cassandra existente y en Amazon Keyspaces. El objetivo es proporcionar una visión coherente de los dos almacenes de datos. Para ello, aplique todas las escrituras nuevas a ambas bases de datos. Para implementar escrituras duales, considere una de las tres opciones siguientes.
+ Migración de **proxy de escritura doble de ZDM para Amazon Keyspaces**: con el proxy de ZDM para Amazon Keyspaces disponible [en](https://github.com/aws-samples/amazon-keyspaces-examples/blob/main/migration/online/zdm-proxy/README.md) Github, puede migrar sus cargas de trabajo de Apache Cassandra a Amazon Keyspaces sin tiempo de inactividad de la aplicación. Esta solución mejorada implementa las AWS mejores prácticas y amplía las capacidades oficiales del proxy de ZDM.
+ Realice migraciones en línea entre Apache Cassandra y Amazon Keyspaces.
+ Escriba datos en las tablas de origen y destino simultáneamente sin refactorizar las aplicaciones.
+ Valide las consultas mediante operaciones de doble lectura.
La solución ofrece las siguientes mejoras para trabajar con AWS Amazon Keyspaces.
+ **Despliegue de contenedores**: utilice una imagen de Docker preconfigurada de Amazon Elastic Container Registry (Amazon ECR) para las implementaciones accesibles mediante VPC.
+ **Infraestructura como código**: impleméntela mediante AWS CloudFormation plantillas para una configuración automática. AWS Fargate
+ **Compatibilidad con Amazon Keyspaces**: acceda a las tablas del sistema con adaptaciones personalizadas para Amazon Keyspaces.
La solución se ejecuta en Amazon ECS con Fargate, lo que proporciona escalabilidad sin servidor en función de sus demandas de carga de trabajo. Un balanceador de carga de red distribuye el tráfico entrante de las aplicaciones entre varias tareas de Amazon ECS para lograr una alta disponibilidad.
![\[Implementación del proxy de escritura dual ZDM para migrar datos de Apache Cassandra a Amazon Keyspaces.\]](http://docs.aws.amazon.com/es_es/keyspaces/latest/devguide/images/migration/online-migration-zdm.png)
+ **Escrituras duales de aplicación**: puede implementar escrituras duales con cambios mínimos en el código de su aplicación aprovechando las bibliotecas de clientes y los controladores existentes de Cassandra. Puede implementar escrituras duales en su aplicación existente o crear una nueva capa en la arquitectura para administrar las escrituras duales. Para obtener más información y un caso práctico de un cliente que demuestra cómo se implementaron las escrituras duales en una aplicación existente, consulte este [caso práctico de migración de Cassandra](https://aws.amazon.com/solutions/case-studies/intuit-apache-migration-case-study/).
Al implementar escrituras duales, puede designar una base de datos como líder y la otra base de datos como seguidora. Esto le permite seguir escribiendo en la base de datos original (o líder) evitando que los errores de escritura en la base de datos de destino (o seguidora) interrumpan la ruta crítica de la aplicación.
En lugar de volver a intentar las escrituras fallidas en la seguidora, puede utilizar Amazon Simple Queue Service para registrar las escrituras fallidas en una [cola de mensajes fallidos (DLQ)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html). La DLQ le permite analizar las escrituras fallidas en la seguidora y determinar por qué no se ha realizado correctamente el procesamiento en la base de datos de destino.
[Para una implementación de escritura doble más sofisticada, puede seguir las AWS mejores prácticas para diseñar una secuencia de transacciones locales utilizando el patrón saga.](https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/saga.html) Un patrón saga asegura que, si se produce un error en una transacción, la saga ejecuta transacciones de compensación para revertir los cambios en la base de datos realizados por las transacciones anteriores.
Si utiliza escrituras duales para una migración en línea, puede configurar las escrituras duales para que sigan el patrón saga, de modo que cada escritura sea una transacción local que garantice las operaciones atómicas en bases de datos heterogéneas. Para obtener más información sobre cómo diseñar aplicaciones distribuidas utilizando los patrones de diseño recomendados para ellasNube de AWS, consulte [Patrones de diseño, arquitecturas e implementaciones en la nube](https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/introduction).
![\[Implementación de escrituras duales en la capa de aplicación al migrar de Apache Cassandra a Amazon Keyspaces.\]](http://docs.aws.amazon.com/es_es/keyspaces/latest/devguide/images/migration/online-migration-dual-writes.png)
+ **Escrituras duales en el nivel de mensajería**: en lugar de implementar escrituras duales en la capa de aplicación, puede usar el nivel de mensajería existente para realizar escrituras duales en Cassandra y Amazon Keyspaces.
Para ello, puede configurar un consumidor adicional para su plataforma de mensajería de modo que envíe las escrituras a ambos almacenes de datos. Este enfoque proporciona una estrategia sencilla y con poco código que utiliza el nivel de mensajería para crear dos vistas en ambas bases de datos que, en última instancia, sean coherentes.
# Carga de datos históricos durante una migración en línea
Tras implementar la escritura dual para garantizar que los nuevos datos se escriban en ambos almacenes de datos en tiempo real, el siguiente paso del plan de migración consiste en evaluar la cantidad de datos históricos que necesita copiar o cargar por lotes de Cassandra a Amazon Keyspaces. Esto garantiza que tanto los datos nuevos como los históricos estén disponibles en la nueva base de datos de Amazon Keyspaces antes de migrar la aplicación.
En función de sus requisitos de retención de datos, por ejemplo, de la cantidad de datos históricos que necesite conservar en función de las políticas de su organización, puede considerar una de las dos opciones siguientes.
+ **Carga masiva de datos históricos**: la migración de los datos históricos de su implementación actual de Cassandra a Amazon Keyspaces se puede realizar mediante diversas técnicas, por ejemplo, el AWS Glue uso de scripts personalizados para extraer, transformar y cargar (ETL) los datos. Para obtener más información acerca del uso de AWS Glue para cargar datos históricos, consulte [Proceso de migración sin conexión: de Apache Cassandra a Amazon Keyspaces](migrating-offline.md).
Al planificar la carga masiva de datos históricos, hay que tener en cuenta cómo resolver los conflictos que pueden producirse cuando se intenta actualizar con nuevas escrituras los mismos datos que se están cargando. Cabe esperar que la carga por lotes acabe siendo coherente, lo que significa que los datos llegarán a todos los nodos al final.
Si se produce una actualización de los mismos datos al mismo tiempo debido a una nueva escritura, debe asegurarse de que la carga de los datos históricos no los sobrescriba. Para asegurarse de conservar las últimas actualizaciones de sus datos incluso durante la importación por lotes, debe incorporar la solución de conflictos a los scripts de carga por lotes o a la lógica de la aplicación para las escrituras duales.
Por ejemplo, puede usar [Transacciones ligeras](functional-differences.md#functional-differences.light-transactions) (LWT) para comparar y configurar las operaciones. Para ello, puede agregar un campo adicional a su modelo de datos que represente el momento de la modificación o el estado.
Además, Amazon Keyspaces admite la función de marca de tiempo `WRITETIME` de Cassandra. Puede utilizar las marcas de tiempo del lado del cliente de Amazon Keyspaces para conservar las marcas de tiempo de la base de datos de origen e implementar la resolución de conflictos. last-writer-wins Para obtener más información, consulte [Marcas de tiempo del cliente en Amazon Keyspaces](client-side-timestamps.md).
+ **Uso de Time-to-Live (TTL)**: para períodos de retención de datos inferiores a 30, 60 o 90 días, puede usar TTL en Cassandra y Amazon Keyspaces durante la migración para evitar cargar datos históricos innecesarios en Amazon Keyspaces. El TTL le permite establecer un período de tiempo tras el cual se quitan automáticamente los datos de la base de datos.
Durante la fase de migración, en lugar de copiar los datos históricos a Amazon Keyspaces, puede configurar los ajustes del TTL para permitir que los datos históricos caduquen automáticamente en el sistema anterior (Cassandra) y aplicar únicamente las nuevas escrituras a Amazon Keyspaces mediante el método de escritura dual. Con el paso del tiempo, y dado que los datos antiguos caducan continuamente en el clúster de Cassandra y los nuevos se escriben con el método de escritura dual, Amazon Keyspaces se pone al día automáticamente para contener los mismos datos que Cassandra.
Este enfoque puede reducir considerablemente la cantidad de datos que se van a migrar, lo que se traduce en un proceso de migración más eficiente y optimizado. Puede plantearse este enfoque cuando se enfrente a conjuntos de datos grandes con requisitos de retención de datos variables. Para obtener más información sobre e TTL, consulte [Caducidad de datos con período de vida (TTL) para Amazon Keyspaces (para Apache Cassandra)](TTL.md).
Plantéese el siguiente ejemplo de una migración de Cassandra a Amazon Keyspaces mediante la caducidad de datos con TTL. En este ejemplo, establecemos el TTL de ambas bases de datos en 60 días y mostramos cómo progresa el proceso de migración durante un período de 90 días. Ambas bases de datos reciben los mismos datos recién escritos durante este período mediante el método de escritura dual. Vamos a analizar tres fases diferentes de la migración, cada una de las cuales dura 30 días.
En las siguientes imágenes se muestra cómo funciona el proceso de migración para cada fase.
![\[Uso del TTL para hacer caducar los datos históricos al migrar de Apache Cassandra a Amazon Keyspaces.\]](http://docs.aws.amazon.com/es_es/keyspaces/latest/devguide/images/migration/online-migration-TTL.png)
1. Tras los primeros 30 días, el clúster de Cassandra y Amazon Keyspaces han estado recibiendo nuevas escrituras. El clúster de Cassandra también contiene datos históricos que aún no han alcanzado los 60 días de retención, lo que representa el 50 % de los datos del clúster.
Los datos que tienen más de 60 días se eliminan automáticamente en el clúster de Cassandra mediante TTL. En este punto, Amazon Keyspaces contiene el 50 % de los datos almacenados en el clúster de Cassandra, que se compone de las nuevas escrituras menos los datos históricos.
1. Transcurridos 60 días, tanto el clúster de Cassandra como Amazon Keyspaces contienen los mismos datos escritos en los últimos 60 días.
1. En un plazo de 90 días, tanto Cassandra como Amazon Keyspaces contienen los mismos datos y los datos caducan al mismo ritmo.
Este ejemplo ilustra cómo evitar el paso de cargar datos históricos mediante el uso del TTL con una fecha de caducidad establecida en 60 días.
# Validación de la coherencia de datos durante una migración en línea
El siguiente paso del proceso de migración en línea es la validación de los datos. Las escrituras duales añaden nuevos datos a su base de datos de Amazon Keyspaces y ha completado la migración de los datos históricos mediante la carga por lotes o la caducidad de los datos con TTL.
Ahora puede utilizar la fase de validación para confirmar que ambos almacenes de datos contienen realmente los mismos datos y devuelven los mismos resultados de lectura. Puede elegir una de las dos opciones siguientes para validar que ambas bases de datos contengan datos idénticos.
+ **Lecturas duales**: para validar que tanto la base de datos de origen como la de destino contengan el mismo conjunto de datos históricos y recién escritos, puede implementar lecturas duales. Para ello, debe leer tanto la base de datos principal de Cassandra como la base de datos secundaria de Amazon Keyspaces, de forma similar al método de escritura dual, y comparar los resultados de forma asíncrona.
Los resultados de la base de datos principal se devuelven al cliente y los resultados de la base de datos secundaria se utilizan para validarlos con el conjunto de resultados principal. Las diferencias detectadas se pueden registrar o enviar a una [cola de mensajes fallidos (DLQ)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html) para su posterior conciliación.
En el siguiente diagrama, la aplicación realiza una lectura sincrónica desde Cassandra (que es el almacén de datos principal) y una lectura asincrónica desde Amazon Keyspaces, que es el almacén de datos secundario.
![\[Uso de lecturas duales para validar la coherencia de datos durante una migración en línea de Apache Cassandra a Amazon Keyspaces.\]](http://docs.aws.amazon.com/es_es/keyspaces/latest/devguide/images/migration/online-migration-dual-reads.png)
+ **Lecturas de muestra**: una solución alternativa que no requiere cambios en el código de la aplicación consiste en utilizar AWS Lambda funciones para muestrear de forma periódica y aleatoria los datos del clúster Cassandra de origen y de la base de datos Amazon Keyspaces de destino.
Estas funciones de Lambda se pueden configurar para que se ejecuten a intervalos regulares. La función de Lambda recupera un subconjunto aleatorio de datos de los sistemas de origen y destino y, a continuación, realiza una comparación de los datos muestreados. Cualquier discrepancia o discordancia entre los dos conjuntos de datos se puede registrar y enviar a una [cola de mensajes fallidos (DLQ)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html) específica para su posterior conciliación.
Este proceso se ilustra en el siguiente diagrama.
![\[Uso de lecturas de muestra para validar la coherencia de datos durante una migración en línea de Apache Cassandra a Amazon Keyspaces.\]](http://docs.aws.amazon.com/es_es/keyspaces/latest/devguide/images/migration/online-migration-sample-reads.png)
# Migración de la aplicación durante una migración en línea
En la cuarta fase de una migración en línea, migrará su aplicación y realizará la transición a Amazon Keyspaces como almacén de datos principal. Esto significa que puede cambiar la aplicación para que lea y escriba directamente desde y hacia Amazon Keyspaces. Para garantizar una interrupción mínima para sus usuarios, debe ser un proceso bien planificado y coordinado.
Hay disponibles dos soluciones recomendadas diferentes para la migración de aplicaciones: la estrategia de transición azul-verde y la estrategia de transición canario. En las siguientes secciones se describen estas estrategias con más detalle.
+ **Estrategia azul-verde**: mediante el uso de este enfoque, modifica su aplicación para que trate Amazon Keyspaces como el almacén de datos principal y Cassandra como el almacén de datos secundario en un solo paso. Para ello, utilice un indicador de AWS AppConfig función para controlar la elección de los almacenes de datos principales y secundarios en la instancia de la aplicación. Para obtener más información sobre marcas de características, consulte [Creación de un perfil de configuración de marcas de características en AWS AppConfig](https://docs.aws.amazon.com/appconfig/latest/userguide/appconfig-creating-configuration-and-profile-feature-flags.html).
Tras convertir Amazon Keyspaces en el almacén de datos principal, debe supervisar el comportamiento y el rendimiento de la aplicación para garantizar que Amazon Keyspaces cumpla sus requisitos y que la migración se realice correctamente.
Por ejemplo, si ha implementado lecturas duales para su aplicación, durante la fase de migración de la aplicación, pasará las lecturas principales de Cassandra a Amazon Keyspaces y las lecturas secundarias de Amazon Keyspaces a Cassandra. Tras la transición, debe seguir supervisando y comparando los resultados tal y como se describe en la sección de [validación de datos](migration-online-validation.md) para garantizar la coherencia en ambas bases de datos antes de retirar Cassandra del servicio.
Si detecta algún problema, puede volver rápidamente al estado anterior recuperando Cassandra como almacén de datos principal. Solo pasará a la fase de retirada de la migración si Amazon Keyspaces satisface todas sus necesidades como almacén de datos principal.
![\[Uso de la estrategia azul-verde para migrar una aplicación de Apache Cassandra a Amazon Keyspaces.\]](http://docs.aws.amazon.com/es_es/keyspaces/latest/devguide/images/migration/online-migration-switch.png)
+ **Estrategia canario**: con este enfoque, se lleva a cabo gradualmente la migración para un subconjunto de los usuarios o del tráfico. Inicialmente, un pequeño porcentaje del tráfico de la aplicación (por ejemplo, el 5 % de todo el tráfico) se redirige a la versión que utiliza Amazon Keyspaces como almacén de datos principal, mientras que el resto del tráfico sigue utilizando Cassandra como almacén de datos principal.
Esto le permite probar exhaustivamente la versión migrada con tráfico real, supervisar su rendimiento y estabilidad e investigar los posibles problemas. Si no detecta ningún problema, puede aumentar gradualmente el porcentaje de tráfico que se dirige a Amazon Keyspaces hasta que se convierta en el almacén de datos principal para todos los usuarios y todo el tráfico.
Esta implementación por etapas minimiza el riesgo de interrupciones generalizadas del servicio y permite un proceso de migración más controlado. Si surge algún problema grave durante la implementación canario, puede volver rápidamente a la versión anterior utilizando Cassandra como almacén de datos principal para el segmento de tráfico afectado. Solo pasará a la fase de retirada de la migración después de haber validado que Amazon Keyspaces procesa el 100 % de los usuarios y el tráfico según lo previsto.
El siguiente diagrama ilustra los pasos individuales de la estrategia canario.
![\[Uso de la estrategia canario para migrar una aplicación de Apache Cassandra a Amazon Keyspaces.\]](http://docs.aws.amazon.com/es_es/keyspaces/latest/devguide/images/migration/online-migration-canary.png)
# Retirada de Cassandra tras una migración en línea
Una vez finalizada la migración de la aplicación, cuando la aplicación se esté ejecutando completamente en Amazon Keyspaces y se haya validado la coherencia de datos durante un período de tiempo, puede planificar la retirada del clúster de Cassandra. Durante esta fase, puede evaluar si los datos que quedan en su clúster de Cassandra deben archivarse o si se pueden eliminar. Esto depende de las políticas de su organización en materia de tratamiento y retención de datos.
Si sigue esta estrategia y tiene en cuenta las mejores prácticas recomendadas que se describen en este tema al planificar la migración en línea de Cassandra a Amazon Keyspaces, puede garantizar una transición fluida a Amazon Keyspaces y, al mismo tiempo, read-after-write mantener la coherencia y la disponibilidad de su aplicación.
La migración de Apache Cassandra a Amazon Keyspaces puede ofrecer numerosas ventajas, como la reducción de los gastos operativos, el escalado automático, la mejora de la seguridad y un marco que le ayude a alcanzar sus objetivos de conformidad normativa. Al planificar una estrategia de migración en línea con escrituras duales, carga de datos históricos, validación de datos e implementación gradual, puede garantizar una transición fluida con una interrupción mínima para su aplicación y sus usuarios.
La implementación de la estrategia de migración en línea que se analiza en este tema le permite validar los resultados de la migración, identificar y abordar cualquier problema y, en última instancia, retirar su implementación actual de Cassandra en favor del servicio de Amazon Keyspaces totalmente administrado.
# Proceso de migración sin conexión: de Apache Cassandra a Amazon Keyspaces
Las migraciones sin conexión son adecuadas cuando se pueda permitir un tiempo de inactividad para llevarlas a cabo. Es habitual que las empresas tengan períodos de mantenimiento para la aplicación de parches o lanzamientos de gran tamaño, o tiempos de inactividad para llevar a cabo actualizaciones de hardware o cambios principales. La migración sin conexión puede aprovechar estos periodos para copiar datos y transferir el tráfico de aplicaciones de Apache Cassandra a Amazon Keyspaces.
La migración sin conexión reduce las modificaciones en la aplicación porque no requiere la comunicación simultánea con Cassandra y Amazon Keyspaces. Además, dado que el flujo de datos está pausado, se puede copiar el estado exacto sin mantener las mutaciones.
En este ejemplo, utilizamos Amazon Simple Storage Service (Amazon S3) como espacio provisional para los datos durante la migración sin conexión con el objetivo de minimizar el tiempo de inactividad. Puede importar automáticamente los datos que ha almacenado en formato Parquet en Amazon S3 a una tabla de Amazon Keyspaces mediante Spark Cassandra Connector y AWS Glue. En la siguiente sección se mostrará información general de alto nivel del proceso. Puede encontrar ejemplos de código para este proceso en [Github](https://github.com/aws-samples/amazon-keyspaces-examples/tree/main/scala/datastax-v4/aws-glue).
El proceso de migración sin conexión de Apache Cassandra a Amazon Keyspaces mediante Amazon S3 requiere AWS Glue los AWS Glue siguientes trabajos.
1. Un trabajo ETL que extraiga y transforme los datos de CQL y los almacena en un bucket de Amazon S3.
1. Un segundo trabajo que importe los datos del bucket a Amazon Keyspaces.
1. Un tercer trabajo que importe datos incrementales.
**Cómo realizar una migración offline a Amazon Keyspaces desde Cassandra que se ejecuta en Amazon EC2 en una Amazon Virtual Private Cloud**
1. Primero se exportan AWS Glue los datos de las tablas de Cassandra en formato Parquet y se guardan en un bucket de Amazon S3. Debe ejecutar un AWS Glue trabajo mediante un AWS Glue conector a una VPC en la que resida la EC2 instancia de Amazon que ejecuta Cassandra. A continuación, con el punto de conexión privado de Amazon S3, puede guardar los datos en el bucket de Amazon S3.
En el siguiente diagrama se muestran estos pasos.
![\[Migración de datos de Apache Cassandra desde Amazon EC2 que se ejecuta en una VPC a un bucket de Amazon S3 mediante. AWS Glue\]](http://docs.aws.amazon.com/es_es/keyspaces/latest/devguide/images/migration/migration-export.png)
1. Mezcla de los datos en el bucket de Amazon S3 para mejorar la asignación al azar de los datos. Los datos importados de manera uniforme permiten distribuir más el tráfico en la tabla de destino.
Este paso es obligatorio cuando se exportan datos de Cassandra con particiones grandes (particiones con más de 1000 filas) para evitar patrones de claves sobrecargadas al insertar los datos en Amazon Keyspaces. Los problemas por claves sobrecargadas provocan `WriteThrottleEvents` en Amazon Keyspaces y causan un aumento del tiempo de carga.
![\[Un AWS Glue trabajo mezcla los datos de un bucket de Amazon S3 y los devuelve a otro bucket de Amazon S3.\]](http://docs.aws.amazon.com/es_es/keyspaces/latest/devguide/images/migration/migration-shuffle.png)
1. Utilice otro AWS Glue trabajo para importar datos del bucket de Amazon S3 a Amazon Keyspaces. Los datos mezclados en el bucket de Amazon S3 se almacenan en formato Parquet.
![\[El trabajo de AWS Glue importación toma los datos mezclados del bucket de Amazon S3 y los mueve a una tabla de Amazon Keyspaces.\]](http://docs.aws.amazon.com/es_es/keyspaces/latest/devguide/images/migration/migration-import.png)
Para obtener más información sobre el proceso de migración fuera de línea, consulte el taller [Amazon Keyspaces with AWS Glue](https://catalog.workshops.aws/unlocking-amazonkeyspaces/en-US/keyspaces-with-glue)
# Uso de una solución de migración híbrida: de Apache Cassandra a Amazon Keyspaces
La siguiente solución de migración puede considerarse un híbrido entre la migración en línea y la migración sin conexión. Con este enfoque híbrido, se escriben los datos en la base de datos de destino casi en tiempo real sin proporcionar coherencia de lectura tras la escritura. Esto significa que los datos recién escritos no estarán disponibles de forma inmediata y que es previsible que se produzcan retrasos. Si necesita coherencia de lectura tras la escritura, consulte [Migración online a Amazon Keyspaces: estrategias y prácticas recomendadas](migrating-online.md).
Para realizar una migración casi en tiempo real de Apache Cassandra a Amazon Keyspaces, puede elegir entre dos métodos disponibles.
+ **CQLReplicator**— (Recomendado) CQLReplicator es una utilidad de código abierto disponible en [Github](https://github.com/aws-samples/cql-replicator) que le ayuda a migrar datos de Apache Cassandra a Amazon Keyspaces casi en tiempo real.
Para determinar las escrituras y actualizaciones que se van a propagar a la base de datos de destino, CQLReplicator escanea el rango de tokens de Apache Cassandra y utiliza un AWS Glue trabajo para eliminar los eventos duplicados y aplicar las escrituras y actualizaciones directamente a Amazon Keyspaces.
+ **Captura de datos de cambios (CDC)**: si conoce la CDC de Cassandra, otra opción para implementar una migración híbrida es utilizar la característica de CDC integrada en Apache Cassandra, que permite capturar los cambios copiando el registro de confirmaciones en un directorio de CDC independiente.
Para ello, puede replicar los cambios en los datos en Amazon Keyspaces, lo que convierte a la CDC en una opción alternativa para los escenarios de migración de datos.
Si no necesita coherencia de lectura tras escritura, puede utilizar la canalización CQLReplicator o una canalización de CDC para migrar los datos de Apache Cassandra a Amazon Keyspaces en función de sus preferencias y de su familiaridad con las herramientas utilizadas en cada Servicios de AWS solución. El uso de estos métodos para migrar datos prácticamente en tiempo real puede considerarse un enfoque de migración híbrido que ofrece una alternativa a la migración en línea.
Esta estrategia se considera un enfoque híbrido porque, además de las opciones descritas en este tema, deben implementarse algunos pasos del proceso de migración en línea, por ejemplo, la copia de los datos históricos y las estrategias de migración de aplicaciones que se analizan en el tema [migración en línea](migrating-online.md).
En las siguientes secciones, se explican las opciones de migración híbrida con más detalle.
**Topics**
+ [Migre los datos mediante CQLReplicator](migration-hybrid-cql-rep.md)
+ [Migración de datos mediante la captura de datos de cambios (CDC)](migration-hybrid-cdc.md)
# Migre los datos mediante CQLReplicator
Con él [CQLReplicator](https://github.com/aws-samples/cql-replicator), puede leer los datos de Apache Cassandra prácticamente en tiempo real escaneando de forma inteligente el anillo de fichas de Cassandra mediante consultas CQL. CQLReplicator no usa Cassandra CDC y, en su lugar, implementa una estrategia de almacenamiento en caché para reducir las penalizaciones de rendimiento de los escaneos completos.
Para reducir el número de escrituras en el destino, elimina CQLReplicator automáticamente los eventos de replicación duplicados. Con CQLReplicator, puede ajustar la replicación de los cambios de la base de datos de origen a la base de datos de destino, lo que permite una migración de datos casi en tiempo real de Apache Cassandra a Amazon Keyspaces.
El siguiente diagrama muestra la arquitectura típica de un CQLReplicator trabajo que utiliza. AWS Glue
1. **Para permitir el acceso a Apache Cassandra que se ejecuta en una VPC privada, configure AWS Glue una conexión con el tipo de conexión Red.**
1. Para eliminar los duplicados y habilitar el almacenamiento en caché de claves con la CQLReplicator tarea, configure Amazon Simple Storage Service (Amazon S3).
1. La base de datos fuente verificada de CQLReplicator Job Streams cambia directamente a Amazon Keyspaces.
![\[Se utiliza CQLReplicator para migrar datos de Apache Cassandra a Amazon Keyspaces.\]](http://docs.aws.amazon.com/es_es/keyspaces/latest/devguide/images/migration/hybrid-migration-CQLRep.png)
Para obtener más información sobre el proceso de migración mediante CQLReplicator, consulte la siguiente publicación en el blog de AWS bases de datos [Migre las cargas de trabajo de Cassandra a Amazon Keyspaces utilizando CQLReplicator](https://aws.amazon.com/blogs/database/migrate-cassandra-workloads-to-amazon-keyspaces-using-cqlreplicator/) y la guía AWS prescriptiva [Migre las cargas de trabajo de Apache Cassandra a](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/migrate-apache-cassandra-workloads-to-amazon-keyspaces-using-aws-glue.html) Amazon Keyspaces mediante el uso. AWS Glue
# Migración de datos mediante la captura de datos de cambios (CDC)
Si ya está familiarizado con la configuración de un proceso de captura de datos de cambios (CDC) con [Debezium](https://debezium.io/), puede usar esta opción para migrar datos a Amazon Keyspaces como alternativa a la de usarla. CQLReplicator Debezium es una plataforma distribuida de código abierto para la CDC, diseñada para supervisar una base de datos y capturar los cambios en las filas de manera fiable.
El [conector de Debezium para Apache Cassandra](https://debezium.io/documentation/reference/stable/connectors/cassandra.html) carga los cambios en Amazon Managed Streaming para Apache Kafka (Amazon MSK) de modo que los consumidores intermedios puedan consumirlos, procesarlos y escribir a su vez los datos en Amazon Keyspaces. Para obtener más información, consulte [Guidance for continuous data migration from Apache Cassandra to Amazon Keyspaces](https://aws.amazon.com/solutions/guidance/continuous-data-migration-from-apache-cassandra-to-amazon-keyspaces/).
Si quiere solucionar cualquier posible problema de coherencia de datos, puede implementar un proceso con Amazon MSK en el que un consumidor compare las claves o particiones de Cassandra con las de Amazon Keyspaces.
Para implementar esta solución correctamente, le recomendamos que tenga en cuenta lo siguiente.
+ Cómo analizar el registro de confirmaciones de la CDC; por ejemplo, cómo eliminar los eventos duplicados.
+ Cómo mantener el directorio de la CDC; por ejemplo, cómo eliminar los registros antiguos.
+ Cómo administrar los errores parciales en Apache Cassandra; por ejemplo, si una escritura solo se realiza correctamente en una de cada tres réplicas.
+ Cómo administrar la asignación de recursos, por ejemplo, aumentar el tamaño de la instancia para que admita los requisitos adicionales de CPU, memoria, disco y E/S para el proceso de CDC que se produce en un nodo.
Este patrón trata los cambios de Cassandra como “indicios” de que una clave puede haber cambiado con respecto a su estado anterior. Para determinar si hay cambios que propagar a la base de datos de destino, primero debe leer el clúster de Cassandra de origen mediante una operación `LOCAL_QUORUM` para recibir los registros más recientes y, a continuación, escribirlos en Amazon Keyspaces.
En el caso de eliminaciones o actualizaciones de rangos, es posible que deba realizar una comparación con la totalidad de la partición para determinar qué eventos de escritura o actualización deben escribirse en la base de datos de destino.
En los casos en que las escrituras no tengan idempotencia, también debe compararlas con lo que ya está en la base de datos de destino antes de que se efectúen en Amazon Keyspaces.
En el siguiente diagrama, se muestra la arquitectura típica de una canalización de CDC con Debezium y Amazon MSK.
![\[Uso de una canalización de captura de datos de cambios para migrar datos de Apache Cassandra a Amazon Keyspaces.\]](http://docs.aws.amazon.com/es_es/keyspaces/latest/devguide/images/migration/hybrid-migration-CDC.png)