As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Crie um plano de migração para migrar do Apache Cassandra para o Amazon Keyspaces
Para uma migração bem-sucedida do Apache Cassandra para o Amazon Keyspaces, recomendamos uma análise dos conceitos e das melhores práticas de migração aplicáveis, bem como uma comparação das opções disponíveis.
Este tópico descreve como o processo de migração funciona, apresentando vários conceitos-chave e as ferramentas e técnicas disponíveis para você. É possível avaliar as diferentes estratégias de migração para selecionar a mais adequada às suas necessidades.
**Topics**
+ [Compatibilidade funcional](#migrating-cassandra-compatibility)
+ [Custos estimados do Amazon Keyspaces](#migrating-cassandra-sizing)
+ [Escolher uma estratégia de migração](#migrating-cassandra-strategy)
+ [Migração on-line para o Amazon Keyspaces: estratégias e melhores práticas](migrating-online.md)
+ [Processo de migração off-line: Apache Cassandra para Amazon Keyspaces](migrating-offline.md)
+ [Usando uma solução de migração híbrida: Apache Cassandra para Amazon Keyspaces](migrating-hybrid.md)
## Compatibilidade funcional
Considere cuidadosamente as diferenças funcionais entre o Apache Cassandra e o Amazon Keyspaces antes da migração. O Amazon Keyspaces oferece suporte a todas as operações de plano de dados do Cassandra comumente usadas, como criar espaços de chaves e tabelas, ler dados e gravar dados.
No entanto, existem algumas Cassandra que o APIs Amazon Keyspaces não suporta. Para obter mais informações sobre o suporte APIs, consulte[Cassandra APIs, operações, funções e tipos de dados compatíveis](cassandra-apis.md). Para obter uma visão geral de todas as diferenças funcionais entre o Amazon Keyspaces e o Apache Cassandra, consulte [Diferenças funcionais: Amazon Keyspaces versus Apache Cassandra](functional-differences.md).
Para comparar o Cassandra APIs e o esquema que você está usando com a funcionalidade compatível no Amazon Keyspaces, você pode executar um script de compatibilidade disponível no kit de ferramentas do Amazon Keyspaces em. [GitHub](https://github.com/aws-samples/amazon-keyspaces-toolkit/blob/master/bin/toolkit-compat-tool.py)
**Como usar o script de compatibilidade**
1. Baixe o script de compatibilidade do Python [GitHub](https://github.com/aws-samples/amazon-keyspaces-toolkit/blob/master/bin/toolkit-compat-tool.py)e mova-o para um local que tenha acesso ao seu cluster Apache Cassandra existente.
1. O script de compatibilidade usa parâmetros semelhantes a `CQLSH`. Para `--host` e `--port` insira o endereço IP e a porta que você usa para se conectar e executar consultas em um dos nós do Cassandra em seu cluster.
Se seu cluster Cassandra usa autenticação, você também precisa fornecer `-username` e `-password`. Para usar o script de compatibilidade, você pode executar o seguinte comando.
```
python toolkit-compat-tool.py --host hostname or IP -u "username" -p "password" --port native transport port
```
## Custos estimados do Amazon Keyspaces
Esta seção fornece uma visão geral das informações que você precisa coletar das tabelas do Apache Cassandra para calcular o custo estimado do Amazon Keyspaces. Cada uma de suas tabelas exige tipos de dados diferentes, precisa oferecer suporte a diferentes consultas CQL e manter um tráfego distinto read/write .
Pensar em seus requisitos com base em tabelas se alinha aos modos de isolamento de recursos em nível de tabela e [capacidade de throughput de leitura/gravação](ReadWriteCapacityMode.md) do Amazon Keyspaces. Com o Amazon Keyspaces, você pode definir a capacidade de leitura/gravação e as [políticas de ajuste de escala automático](autoscaling.md) para tabelas de forma independente.
Compreender os requisitos das tabelas ajuda você a priorizar tabelas para migração com base na funcionalidade, no custo e no esforço de migração.
Colete as seguintes métricas da tabela do Cassandra antes de uma migração. Essas informações ajudam a estimar o custo da sua workload no Amazon Keyspaces.
+ **Nome da tabela**: o nome do espaço de chaves totalmente qualificado e o nome da tabela.
+ **Descrição**: uma descrição da tabela, por exemplo, como ela é usada ou que tipo de dados são armazenados nela.
+ **Média de leituras por segundo**: o número médio de leituras em nível de coordenadas na tabela em um grande intervalo de tempo.
+ **Média de gravações por segundo**: o número médio de gravações em nível de coordenadas na tabela em um grande intervalo de tempo.
+ **Tamanho médio da linha em bytes**: o tamanho médio da linha em bytes.
+ **Tamanho de armazenamento em GBs** — O tamanho bruto de armazenamento de uma tabela.
+ **Detalhamento da consistência de leitura**: a porcentagem de leituras que usam consistência eventual (`LOCAL_ONE` ou `ONE`) versus consistência forte (`LOCAL_QUORUM`).
Esta tabela mostra um exemplo das informações sobre suas tabelas que você precisa reunir ao planejar uma migração.
****
| Nome da tabela | Description | Média de leitura por segundo | Média de gravação por segundo | Tamanho médio da linha em bytes | Tamanho de armazenamento em GBs | Detalhamento de consistência de leitura |
| --- | --- | --- | --- | --- | --- | --- |
| mykeyspace.mytable | Usado para armazenar o histórico do carrinho de compras | 10.000 | 5.000 | 2.200 | 2.000 | 100% `LOCAL_ONE` |
| mykeyspace.mytable2 | Usado para armazenar as informações mais recentes do perfil | 20.000 | 1.000 | 850 | 1.000 | 25% `LOCAL_QUORUM` 75% `LOCAL_ONE` |
### Como coletar métricas de tabela
Esta seção fornece instruções passo a passo sobre como coletar as métricas de tabela necessárias do seu cluster Cassandra existente. Essas métricas incluem tamanho da linha, tamanho da tabela e read/write solicitações por segundo (RPS). Eles permitem que você avalie os requisitos de capacidade de throughput de uma tabela do Amazon Keyspaces e estime os preços.
**Como coletar métricas de tabela na tabela de origem do Cassandra**
1. Determinar o tamanho da linha
O tamanho da linha é importante para determinar a capacidade de leitura e a utilização da capacidade de gravação no Amazon Keyspaces. O diagrama a seguir mostra a distribuição de dados típica em um intervalo de tokens do Cassandra.
![\[Um diagrama mostrando a distribuição típica de dados em um intervalo de tokens do Cassandra usando o particionador do murmur3.\]](http://docs.aws.amazon.com/pt_br/keyspaces/latest/devguide/images/migration/migration-data-distribution.png)
Você pode usar um script de amostragem de tamanho de linha disponível [GitHub](https://github.com/aws-samples/amazon-keyspaces-toolkit/blob/master/bin/row-size-sampler.sh)para coletar métricas de tamanho de linha para cada tabela em seu cluster do Cassandra.
O script exporta dados da tabela do Apache Cassandra usando `cqlsh` e `awk` para calcular o mínimo, o máximo, a média e o desvio padrão do tamanho da linha em um conjunto de amostra configurável de dados da tabela. O amostrador de tamanho de linha passa os argumentos para `cqlsh`, portanto, os mesmos parâmetros podem ser usados para se conectar e ler do seu cluster do Cassandra.
A instrução a seguir é um exemplo disso.
```
./row-size-sampler.sh 10.22.33.44 9142 \\
-u "username" -p "password" --ssl
```
Para saber mais sobre como o tamanho da linha é calculado no Amazon Keyspaces, consulte [Estimar o tamanho da linha no Amazon Keyspaces](calculating-row-size.md).
1. Determinar o tamanho da tabela
Com o Amazon Keyspaces, você não precisa provisionar o armazenamento com antecedência. O Amazon Keyspaces monitora continuamente o tamanho faturável de suas tabelas para determinar suas cobranças de armazenamento. O armazenamento é cobrado por GB/mês. O tamanho da tabela do Amazon Keyspaces é baseado no tamanho bruto (não compactado) de uma única réplica.
Para monitorar o tamanho da tabela no Amazon Keyspaces, você pode usar a métrica `BillableTableSizeInBytes`, que é exibida para cada tabela em Console de gerenciamento da AWS.
Para estimar o tamanho faturável da sua tabela do Amazon Keyspaces, você pode usar um desses dois métodos:
+ Use o tamanho médio da linha e multiplique pelo número ou linhas.
Você pode estimar o tamanho da tabela Amazon Keyspaces multiplicando o tamanho médio da linha pelo número de linhas da tabela de origem do Cassandra. Use o script de amostra de tamanho de linha da seção anterior para capturar o tamanho médio da linha. Para capturar a contagem de linhas, você pode usar ferramentas como `dsbulk count` determinar o número total de linhas na tabela de origem.
+ Use o `nodetool` para coletar os metadados da tabela.
`Nodetool` é uma ferramenta administrativa fornecida na distribuição do Apache Cassandra que fornece uma visão sobre o estado do processo do Cassandra e retorna os metadados da tabela. Você pode usar `nodetool` para amostrar metadados sobre o tamanho da tabela e, com isso, extrapolar o tamanho da tabela no Amazon Keyspaces.
O comando a ser usado é `nodetool tablestats`. Tablestats retorna o tamanho e a taxa de compactação da tabela. O tamanho da tabela é armazenado como `tablelivespace` da tabela e você pode dividi-lo por `compression ratio`. Em seguida, multiplique esse valor de tamanho pelo número de nós. Por fim, divida pelo fator de replicação (normalmente três).
Essa é a fórmula completa do cálculo que você pode usar para avaliar o tamanho da tabela.
```
((tablelivespace / compression ratio) * (total number of nodes))/ (replication factor)
```
Vamos supor que seu cluster do Cassandra tenha 12 nós. A execução do `nodetool tablestats` comando retorna um `tablelivespace` de 200 GB e um `compression ratio` de 0,5. O espaço de chave tem um fator de replicação de três.
É assim que o cálculo desse exemplo se parece.
```
(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. Capture o número de leituras e gravações
Para determinar os requisitos de capacidade e ajuste de escala para suas tabelas do Amazon Keyspaces, capture a taxa de solicitação de leitura e gravação de suas tabelas do Cassandra antes da migração.
O Amazon Keyspaces não tem servidor e você paga apenas pelo que usa. Em geral, o preço da read/write taxa de transferência no Amazon Keyspaces é baseado no número e no tamanho das solicitações.
Há dois modos de capacidade no Amazon Keyspaces:
+ [Sob demanda](ReadWriteCapacityMode.OnDemand.md): esta é uma opção de faturamento flexível capaz de servir centenas de solicitações por segundo sem a necessidade de planejamento de capacidade. Ele oferece pay-per-request preços para solicitações de leitura e gravação, para que você pague somente pelo que usa.
+ [Provisionada](ReadWriteCapacityMode.Provisioned.md): se você selecionar o modo de capacidade de throughput provisionada, especifique o número de leituras e gravações por segundo necessárias para seu aplicativo. Isso ajuda você a gerenciar o uso do Amazon Keyspaces para permanecer em ou abaixo de uma taxa de solicitação definida para manter a previsibilidade.
O modo provisionado oferece [ajuste de escala automático](autoscaling.md) para ajustar automaticamente sua taxa provisionada para aumentar ou reduzir a escala verticalmente para melhorar a eficiência operacional. Para obter mais informações sobre o gerenciamento de recursos com tecnologia sem servidor, consulte [Como gerenciar os recursos de tecnologia sem servidor no Amazon Keyspaces (para Apache Cassandra)](serverless_resource_management.md).
Como você provisiona a capacidade de throughput de leitura e gravação no Amazon Keyspaces separadamente, você precisa medir a taxa de solicitações para leituras e gravações em suas tabelas existentes de forma independente.
Para reunir as métricas de utilização mais precisas do seu cluster Cassandra existente, capture a média de solicitações por segundo (RPS) para operações de leitura e gravação em nível de coordenador durante um longo período de tempo para uma tabela agregada em todos os nós em um único data center.
Capturar o RPS médio em um período de pelo menos várias semanas captura picos e baixos em seus padrões de tráfego, conforme mostrado no diagrama a seguir.
![\[Um diagrama mostrando a taxa média de solicitações por segundo por dia durante um período de duas semanas.\]](http://docs.aws.amazon.com/pt_br/keyspaces/latest/devguide/images/migration/migration-rps.png)
Você tem duas opções para determinar a taxa de solicitações de leitura e gravação da sua tabela do Cassandra.
+ Use o monitoramento existente do Cassandra
É possível usar as métricas mostradas na tabela a seguir para observar solicitações de leituras e gravações. Observe que os nomes das métricas podem mudar com base na ferramenta de monitoramento que você está usando.
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/keyspaces/latest/devguide/migrating-cassandra.html)
+ Usar a `nodetool`
Use `nodetool tablestats` e `nodetool info` para capturar a média de operações de leitura e gravação da tabela. `tablestats`retorna a contagem total de leituras e gravações a partir do momento em que o nó foi iniciado. `nodetool info` fornece o tempo de atividade de um nó em segundos.
Para receber a média de leituras e gravações por segundo, divida a contagem de leitura e gravação pelo tempo de atividade do nó em segundos. Em seguida, para leituras, você divide pelo nível de consistência e, para gravações, divide pelo fator de replicação. Esses cálculos são expressos nas fórmulas a seguir.
Fórmula para leituras médias por segundo:
```
((number of reads * number of nodes in cluster) / read consistency quorum (2)) / uptime
```
Fórmula para a média de gravações por segundo:
```
((number of writes * number of nodes in cluster) / replication factor of 3) / uptime
```
Vamos supor que temos um cluster de 12 nós que está ativo há 4 semanas. `nodetool info`retorna 2.419.200 segundos de tempo de atividade e `nodetool tablestats` retorna 1 bilhão de gravações e 2 bilhões de leituras. Esse exemplo resultaria no cálculo a seguir.
```
((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. Determine a utilização da capacidade da tabela
Para estimar a utilização média da capacidade, comece com as taxas médias de solicitação e o tamanho médio da linha da tabela de origem do Cassandra.
O Amazon Keyspaces usa unidades de *capacidade de leitura (RCUs) e unidades* de *capacidade de gravação* (WCUs) para medir a capacidade de transferência provisionada para leituras e gravações em tabelas. Para essa estimativa, usamos essas unidades para calcular as necessidades de capacidade de leitura e gravação da nova tabela do Amazon Keyspaces após a migração.
Posteriormente neste tópico, discutiremos como a escolha entre o modo de capacidade provisionada e sob demanda afeta o faturamento. Mas para a estimativa da utilização da capacidade neste exemplo, presumimos que a tabela esteja no modo provisionado.
+ **Leituras**: um RCU representa uma solicitação de leitura `LOCAL_QUORUM` ou duas solicitações de leitura `LOCAL_ONE` para uma linha com até 4 KB de tamanho. Se você precisar ler uma linha maior que 4 KB, a operação de leitura usará mais RCUs. O número total RCUs necessário depende do tamanho da linha e se você deseja usar `LOCAL_QUORUM` ou `LOCAL_ONE` ler a consistência.
Por exemplo, a leitura de uma linha de 8 KB requer 2 RCUs usando a consistência de `LOCAL_QUORUM` leitura e 1 RCU se você escolher a consistência de `LOCAL_ONE` leitura.
+ **Gravação**: um WCU representa uma gravação para uma linha com até 1 KB de tamanho. Todas as gravações estão usando `LOCAL_QUORUM` consistência e não há cobrança adicional pelo uso de transações leves (LWTs).
O número total WCUs necessário depende do tamanho da linha. Se você precisar gravar uma linha maior que 1 KB, a operação de gravação usa mais WCUs. Por exemplo, se o tamanho da linha for de 2 KB, você precisará de 2 WCUs para realizar uma solicitação de gravação.
A fórmula a seguir pode ser usada para estimar o necessário RCUs WCUs e.
+ A **capacidade de leitura em RCUs** pode ser determinada multiplicando as leituras por segundo pelo número de linhas lidas por leitura multiplicado pelo tamanho médio da linha dividido por 4 KB e arredondado para o número inteiro mais próximo.
+ A **capacidade de gravação em WCUs** pode ser determinada multiplicando o número de solicitações pelo tamanho médio da linha dividido por 1 KB e arredondado para o número inteiro mais próximo.
Isso é expresso nas fórmulas a seguir.
```
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 exemplo, se você estiver realizando 4.960 solicitações de leitura com um tamanho de linha de 2,5 KB em sua tabela do Cassandra, precisará de 4.960 no Amazon Keyspaces. RCUs Se você está realizando atualmente 1.653 solicitações de gravação por segundo com um tamanho de linha de 2,5 KB em sua tabela do Cassandra, você precisa de 4.959 por WCUs segundo no Amazon Keyspaces.
Esse exemplo é expresso nas fórmulas a seguir.
```
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
```
O uso de `eventual consistency` permite que você economize até metade da capacidade de throughput em cada solicitação de leitura. Cada leitura final consistente pode consumir até 8 KB. Você pode calcular eventuais leituras consistentes multiplicando o cálculo anterior por 0,5, conforme mostrado na fórmula a seguir.
```
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. Calcule a estimativa de preço mensal para o Amazon Keyspaces
Para estimar o faturamento mensal da tabela com base na taxa de transferência da read/write capacidade, você pode calcular os preços para o modo sob demanda e para o modo provisionado usando fórmulas diferentes e comparar as opções da sua tabela.
**Modo provisionado**: o consumo de capacidade de leitura e gravação é cobrado em uma taxa horária com base nas unidades de capacidade por segundo. Primeiro, divida essa taxa por 0,7 para representar a meta de utilização padrão de ajuste de escala automático de 70%. Em seguida, multiplique por 30 dias corridos, 24 horas por dia e preços tarifários regionais.
Esse cálculo está resumido nas fórmulas a seguir.
```
(read capacity per second / .7) * 24 hours * 30 days * regional rate
(write capacity per second / .7) * 24 hours * 30 days * regional rate
```
**Modo sob demanda**: a capacidade de leitura e gravação é cobrada de acordo com uma taxa por solicitação. Primeiro, multiplique a taxa de solicitações por 30 dias corridos e 24 horas por dia. Em seguida, divida por um milhão de unidades de solicitação. Por fim, multiplique pela taxa regional.
Esse cálculo está resumido nas fórmulas a seguir.
```
((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
```
## Escolher uma estratégia de migração
Você pode escolher entre as seguintes estratégias de migração ao migrar do Apache Cassandra para o Amazon Keyspaces:
+ **On-line**: essa é uma migração ao vivo usando gravações duplas para começar a gravar novos dados no Amazon Keyspaces e no cluster Cassandra simultaneamente. Esse tipo de migração é recomendado para aplicativos que exigem zero tempo de inatividade durante a migração e consistência de leitura após gravação.
Para saber mais sobre como planejar e implementar uma estratégia de migração on-line, consulte [Migração on-line para o Amazon Keyspaces: estratégias e melhores práticas](migrating-online.md).
+ **Off-line**: essa técnica de migração envolve a cópia de um conjunto de dados do Cassandra para o Amazon Keyspaces durante uma janela de tempo de inatividade. A migração off-line pode simplificar o processo de migração, pois não exige alterações em seu aplicativo ou resolução de conflitos entre dados históricos e novas gravações.
Para saber mais sobre como planejar uma migração off-line, consulte [Processo de migração off-line: Apache Cassandra para Amazon Keyspaces](migrating-offline.md).
+ **Híbrida**: essa técnica de migração permite que as alterações sejam replicadas para o Amazon Keyspaces quase em tempo real, mas sem consistência de leitura após gravação.
Para saber mais sobre como planejar uma migração híbrida, consulte [Usando uma solução de migração híbrida: Apache Cassandra para Amazon Keyspaces](migrating-hybrid.md).
Depois de analisar as técnicas de migração e as melhores práticas discutidas neste tópico, você pode colocar as opções disponíveis em uma árvore decisória para criar uma estratégia de migração com base em seus requisitos e recursos disponíveis.
# Migração on-line para o Amazon Keyspaces: estratégias e melhores práticas
Se precisar manter a disponibilidade do aplicativo durante uma migração do Apache Cassandra para o Amazon Keyspaces, você pode preparar uma estratégia de migração on-line personalizada implementando os principais componentes discutidos neste tópico. Ao seguir essas melhores práticas para migrações on-line, você pode garantir que a disponibilidade e a read-after-write consistência dos aplicativos sejam mantidas durante todo o processo de migração, minimizando o impacto sobre seus usuários.
Ao criar uma estratégia de migração on-line do Apache Cassandra para o Amazon Keyspaces, você precisa considerar as seguintes etapas principais.
1. **Escrever novos dados**
+ Proxy **ZDM Dual Write para migração do Amazon Keyspaces — Use o proxy** ZDM Dual Write disponível no [Github para realizar a migração sem tempo de inatividade do Apache Cassandra](https://github.com/aws-samples/amazon-keyspaces-examples/blob/main/migration/online/zdm-proxy/README.md) para o Amazon Keyspaces. O ZDM Proxy executa gravações duplas sem a necessidade de refatorar aplicativos existentes e executa leituras duplas para validação da consulta.
+ Gravações duplas em aplicativos: você pode implementar gravações duplas em seu aplicativo usando bibliotecas e drivers de cliente do Cassandra existentes. Designe um banco de dados como líder e o outro como seguidor. As falhas de gravação no banco de dados de seguidores são registradas em uma [fila de mensagens não entregues (DLQ)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html) para análise.
+ Gravações duplas no nível de mensagens: como alternativa, você pode configurar sua plataforma de mensagens existente para enviar gravações para o Cassandra e para o Amazon Keyspaces usando um consumidor adicional. Eventualmente, isso cria visualizações consistentes em ambos os bancos de dados.
1. **Migração de dados históricos**
+ Copiar dados históricos: você pode migrar dados históricos do Cassandra para o Amazon Keyspaces usando AWS Glue ou scripts personalizados de extração, transformação e carregamento (ETL). Gerencie a resolução de conflitos entre gravações duplas e cargas em massa usando técnicas como transações leves ou registros de data e hora.
+ Uso Time-To-Live (TTL): Para períodos mais curtos de retenção de dados, você pode usar o TTL no Cassandra e no Amazon Keyspaces para evitar o upload de dados históricos desnecessários. À medida que os dados antigos expiram no Cassandra e os novos dados são gravados por meio de gravações duplas, o Amazon Keyspaces acaba se atualizando.
1. **Validando dados**
+ Leituras duplas: implemente leituras duplas dos bancos de dados Cassandra (primário) e Amazon Keyspaces (secundário), comparando os resultados de forma assíncrona. As diferenças são registradas ou enviadas para uma DLQ.
+ Leituras de amostra: use as funções λ para amostrar e comparar dados periodicamente em ambos os sistemas, registrando quaisquer discrepâncias em um DLQ.
1. **Migrando o aplicativo**
+ Estratégia azul e verde: mude seu aplicativo para tratar o Amazon Keyspaces como o principal e o Cassandra como o armazenamento de dados secundário em uma única etapa. Monitore o desempenho e reverta se surgirem problemas.
+ Implantação canário: implemente gradualmente a migração primeiro para um subconjunto de usuários, aumentando incrementalmente o tráfego para o Amazon Keyspaces como principal até a migração completa.
1. **Desativação do Cassandra**
Depois que seu aplicativo for totalmente migrado para o Amazon Keyspaces e a consistência dos dados for validada, você poderá planejar a desativação do seu cluster Cassandra com base nas políticas de retenção de dados.
Ao planejar uma estratégia de migração on-line com esses componentes, você pode fazer a transição sem problemas para o serviço Amazon Keyspaces totalmente gerenciado com o mínimo de tempo de inatividade ou interrupção. As seções a seguir discutem esse componente em mais detalhes.
**Topics**
+ [Escrever novos dados durante uma migração on-line](migration-online-dw.md)
+ [Carregando dados históricos durante uma migração on-line](migration-online-historical.md)
+ [Validando a consistência dos dados durante uma migração on-line](migration-online-validation.md)
+ [Migrando o aplicativo durante uma migração on-line](migration-online-app-migration.md)
+ [Desativação do Cassandra após uma migração on-line](migration-online-decommission.md)
# Escrever novos dados durante uma migração on-line
A primeira etapa em um plano de migração on-line é garantir que todos os novos dados gravados pelo aplicativo sejam armazenados nos dois bancos de dados, em seu cluster Cassandra existente e no Amazon Keyspaces. O objetivo é fornecer uma visão consistente dos dois armazenamentos de dados. Você pode fazer isso aplicando todas as novas gravações nos dois bancos de dados. Para implementar gravações duplas, considere uma das três opções a seguir.
+ Proxy **ZDM Dual Write para migração do Amazon Keyspaces — Usando o proxy** ZDM para Amazon Keyspaces disponível no Github, você pode migrar suas cargas de trabalho do Apache [Cassandra](https://github.com/aws-samples/amazon-keyspaces-examples/blob/main/migration/online/zdm-proxy/README.md) para o Amazon Keyspaces sem tempo de inatividade do aplicativo. Essa solução aprimorada implementa as AWS melhores práticas e amplia os recursos oficiais do ZDM Proxy.
+ Execute migrações on-line entre o Apache Cassandra e o Amazon Keyspaces.
+ Grave dados nas tabelas de origem e de destino simultaneamente sem refatorar os aplicativos.
+ Valide consultas por meio de operações de leitura dupla.
A solução oferece os seguintes aprimoramentos para trabalhar com o Amazon Keyspaces e com o AWS Amazon Keyspaces.
+ **Implantação de contêiner** — Use uma imagem Docker pré-configurada do Amazon Elastic Container Registry (Amazon ECR) para implantações acessíveis por VPC.
+ **Infraestrutura como código** — implante usando AWS CloudFormation modelos para configuração automáticaAWS Fargate.
+ **Compatibilidade com Amazon Keyspaces** — Acesse tabelas do sistema com adaptações personalizadas para o Amazon Keyspaces.
A solução é executada no Amazon ECS com o Fargate, fornecendo escalabilidade sem servidor com base em suas demandas de carga de trabalho. Um balanceador de carga de rede distribui o tráfego de entrada do aplicativo em várias tarefas do Amazon ECS para obter alta disponibilidade.
![\[Implementação do proxy de gravação dupla ZDM para migrar dados do Apache Cassandra para o Amazon Keyspaces.\]](http://docs.aws.amazon.com/pt_br/keyspaces/latest/devguide/images/migration/online-migration-zdm.png)
+ **Gravações duplas do aplicativo**: você pode implementar gravações duplas com o mínimo de alterações no código do aplicativo, aproveitando as bibliotecas e os drivers existentes do cliente Cassandra. Você pode implementar gravações duplas em seu aplicativo existente ou criar uma nova camada na arquitetura para lidar com gravações duplas. Para obter mais informações e um estudo de caso de um cliente que mostra como as gravações duplas foram implementadas em um aplicativo existente, consulte o estudo de [caso de migração do Cassandra](https://aws.amazon.com/solutions/case-studies/intuit-apache-migration-case-study/).
Ao implementar gravações duplas, você pode designar um banco de dados como líder e o outro banco de dados como seguidor. Isso permite que você continue gravando no banco de dados original ou principal sem permitir que falhas de gravação no banco de dados seguidor ou no banco de dados de destino interrompam o caminho crítico do seu aplicativo.
Em vez de tentar novamente gravações com falha no seguidor, você pode usar o Amazon Simple Queue Service para registrar gravações com falha em uma [fila de mensagens não entregues (DLQ](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html)). O DLQ permite que você analise as gravações com falha no seguidor e determine por que o processamento não foi bem-sucedido no banco de dados de destino.
Para uma implementação de gravação dupla mais sofisticada, você pode seguir as AWS melhores práticas para criar uma sequência de transações locais usando o [padrão de saga](https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/saga.html). Um padrão saga certifica que, se uma transação falhar, a saga executa transações compensatórias para reverter as alterações do banco de dados feitas pelas transações anteriores.
Ao usar gravações duplas para uma migração on-line, você pode configurar as gravações duplas seguindo o padrão da saga para que cada gravação seja uma transação local para garantir operações atômicas em bancos de dados heterogêneos. Para obter mais informações sobre como projetar aplicativos distribuídos usando os padrões de design recomendados para oNuvem AWS, consulte [Padrões de design, arquiteturas e implementações de nuvem](https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/introduction).
![\[Implementando gravações duplas na camada do aplicativo ao migrar do Apache Cassandra para o Amazon Keyspaces.\]](http://docs.aws.amazon.com/pt_br/keyspaces/latest/devguide/images/migration/online-migration-dual-writes.png)
+ **Gravações duplas no nível de mensagens**: em vez de implementar gravações duplas na camada do aplicativo, você pode usar seu nível de mensagens existente para realizar gravações duplas no Cassandra e no Amazon Keyspaces.
Para fazer isso, você pode configurar um consumidor adicional em sua plataforma de mensagens para enviar gravações para os dois armazenamentos de dados. Essa abordagem fornece uma estratégia simples de baixo código usando a camada de mensagens para criar duas visualizações em ambos os bancos de dados que acabam sendo consistentes.
# Carregando dados históricos durante uma migração on-line
Depois de implementar gravações duplas para garantir que novos dados sejam gravados em ambos os armazenamentos de dados em tempo real, a próxima etapa do plano de migração é avaliar quantos dados históricos você precisa copiar ou carregar em massa do Cassandra para o Amazon Keyspaces. Isso garante que tanto os novos dados quanto os dados históricos estejam disponíveis no novo banco de dados do Amazon Keyspaces antes de você migrar o aplicativo.
Dependendo dos requisitos de retenção de dados, por exemplo, quantos dados históricos você precisa preservar com base nas políticas da sua organização, você pode considerar uma das duas opções a seguir.
+ **Upload em massa de dados históricos** — A migração de dados históricos de sua implantação atual do Cassandra para o Amazon Keyspaces pode ser realizada por meio de várias técnicas, por exemplo, usando AWS Glue scripts personalizados para extrair, transformar e carregar (ETL) os dados. Para obter mais informações sobre como usar AWS Glue para carregar dados históricos, consulte[Processo de migração off-line: Apache Cassandra para Amazon Keyspaces](migrating-offline.md).
Ao planejar o upload em massa de dados históricos, você precisa considerar como resolver conflitos que podem ocorrer quando novas gravações estão tentando atualizar os mesmos dados que estão sendo carregados. Espera-se que o upload em massa seja eventualmente consistente, o que significa que os dados chegarão a todos os nós eventualmente.
Se uma atualização dos mesmos dados ocorrer ao mesmo tempo devido a uma nova gravação, você deve garantir que ela não seja substituída pelo upload de dados históricos. Para garantir que você preserve as atualizações mais recentes de seus dados mesmo durante a importação em massa, você deve adicionar a resolução de conflitos nos scripts de upload em massa ou na lógica do aplicativo para gravações duplas.
Por exemplo, você pode usar [Transações leves](functional-differences.md#functional-differences.light-transactions) (LWT) para comparar e definir operações. Para fazer isso, você pode adicionar um campo adicional ao seu modelo de dados que represente a hora da modificação ou o estado.
Além disso, o Amazon Keyspaces oferece suporte à função de timestamp do Cassandra`WRITETIME`. Você pode usar os timestamps do lado do cliente do Amazon Keyspaces para preservar os timestamps do banco de dados de origem e implementar a resolução de conflitos. last-writer-wins Para obter mais informações, consulte [Carimbos de data/hora do lado do cliente no Amazon Keyspaces](client-side-timestamps.md).
+ **Usando Time-to-Live (TTL)** — Para períodos de retenção de dados menores que 30, 60 ou 90 dias, você pode usar o TTL no Cassandra e no Amazon Keyspaces durante a migração para evitar o upload de dados históricos desnecessários para o Amazon Keyspaces. O TTL permite definir um período de tempo após o qual os dados são removidos automaticamente do banco de dados.
Durante a fase de migração, em vez de copiar dados históricos para o Amazon Keyspaces, você pode definir as configurações de TTL para permitir que os dados históricos expirem automaticamente no sistema antigo (Cassandra), aplicando somente as novas gravações no Amazon Keyspaces usando o método de gravação dupla. Com o tempo, com os dados antigos expirando continuamente no cluster do Cassandra e os novos dados gravados usando o método de gravação dupla, o Amazon Keyspaces automaticamente se atualiza para conter os mesmos dados do Cassandra.
Essa abordagem pode reduzir significativamente a quantidade de dados a serem migrados, resultando em um processo de migração mais eficiente e simplificado. Você pode considerar essa abordagem ao lidar com grandes conjuntos de dados com diferentes requisitos de retenção de dados. Para obter mais informações sobre a TTL, consulte [Dados expirados com vida útil (TTL) para Amazon Keyspaces (para Apache Cassandra)](TTL.md).
Considere o exemplo a seguir de uma migração do Cassandra para o Amazon Keyspaces usando a expiração de dados TTL. Neste exemplo, definimos o TTL para ambos os bancos de dados para 60 dias e mostramos como o processo de migração progride em um período de 90 dias. Ambos os bancos de dados recebem os mesmos dados recém-gravados durante esse período usando o método de gravação dupla. Vamos analisar três fases diferentes da migração, cada fase dura 30 dias.
O funcionamento do processo de migração em cada fase é mostrado nas imagens a seguir.
![\[Usando TTL para expirar dados históricos ao migrar do Apache Cassandra para o Amazon Keyspaces.\]](http://docs.aws.amazon.com/pt_br/keyspaces/latest/devguide/images/migration/online-migration-TTL.png)
1. Após os primeiros 30 dias, o cluster Cassandra e o Amazon Keyspaces estão recebendo novas gravações. O cluster Cassandra também contém dados históricos que ainda não atingiram 60 dias de retenção, o que representa 50% dos dados no cluster.
Os dados com mais de 60 dias estão sendo excluídos automaticamente no cluster do Cassandra usando TTL. Nesse ponto, o Amazon Keyspaces contém 50% dos dados armazenados no cluster Cassandra, que é composto pelas novas gravações menos os dados históricos.
1. Depois de 60 dias, tanto o cluster Cassandra quanto o Amazon Keyspaces contêm os mesmos dados gravados nos últimos 60 dias.
1. Em 90 dias, tanto o Cassandra quanto o Amazon Keyspaces contêm os mesmos dados e estão expirando os dados na mesma taxa.
Este exemplo ilustra como evitar a etapa de carregamento de dados históricos usando TTL com uma data de expiração definida como 60 dias.
# Validando a consistência dos dados durante uma migração on-line
A próxima etapa do processo de migração on-line é a validação de dados. As gravações duplas estão adicionando novos dados ao seu banco de dados do Amazon Keyspaces e você concluiu a migração dos dados históricos usando upload em massa ou expiração de dados com TTL.
Agora você pode usar a fase de validação para confirmar se os dois armazenamentos de dados contêm, de fato, os mesmos dados e retornam os mesmos resultados de leitura. Você pode escolher uma das duas opções a seguir para validar se os dois bancos de dados contêm dados idênticos.
+ **Leituras duplas**: para validar se o banco de dados de origem e o banco de dados de destino contêm o mesmo conjunto de dados históricos e recém-gravados, você pode implementar leituras duplas. Para fazer isso, você lê o Cassandra principal e o banco de dados secundário do Amazon Keyspaces de forma semelhante ao método de gravação dupla e compara os resultados de forma assíncrona.
Os resultados do banco de dados primário são retornados ao cliente e os resultados do banco de dados secundário são usados para validar em relação ao conjunto de resultados primário. As diferenças encontradas podem ser registradas ou enviadas para uma [fila de mensagens não entregues (DLQ)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html) para posterior reconciliação.
No diagrama a seguir, o aplicativo está realizando uma leitura síncrona do Cassandra (que é o armazenamento de dados primário) e uma leitura assíncrona do Amazon Keyspaces, que é o armazenamento de dados secundário.
![\[Usando leituras duplas para validar a consistência dos dados durante uma migração on-line do Apache Cassandra para o Amazon Keyspaces.\]](http://docs.aws.amazon.com/pt_br/keyspaces/latest/devguide/images/migration/online-migration-dual-reads.png)
+ **Exemplos de leituras** — Uma solução alternativa que não exige alterações no código do aplicativo é usar AWS Lambda funções para obter amostras periódicas e aleatórias de dados do cluster Cassandra de origem e do banco de dados Amazon Keyspaces de destino.
Essas funções do Lambda podem ser configuradas para serem executadas em intervalos regulares. A função do Lambda recupera um subconjunto aleatório de dados dos sistemas de origem e destino e, em seguida, realiza uma comparação dos dados amostrados. Quaisquer discrepâncias ou incompatibilidades entre os dois conjuntos de dados podem ser registradas e enviadas para uma [fila de mensagens não entregues (DLQ](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html)) dedicada para posterior reconciliação.
Esse processo é ilustrado no diagrama a seguir.
![\[Usando leituras de amostra para validar a consistência dos dados durante a migração on-line do Apache Cassandra para o Amazon Keyspaces.\]](http://docs.aws.amazon.com/pt_br/keyspaces/latest/devguide/images/migration/online-migration-sample-reads.png)
# Migrando o aplicativo durante uma migração on-line
Na quarta fase de uma migração on-line, você está migrando seu aplicativo e fazendo a transição para o Amazon Keyspaces como armazenamento de dados primário. Isso significa que você alterna seu aplicativo para ler e gravar diretamente de e para o Amazon Keyspaces. Para garantir o mínimo de interrupção para seus usuários, esse deve ser um processo bem planejado e coordenado.
Duas soluções diferentes recomendadas para migração de aplicativos estão disponíveis: a estratégia de recorte azul esverdeado e a estratégia de corte canário. As seções a seguir descrevem essas estratégias em mais detalhes.
+ **Estratégia azul e verde**: usando essa abordagem, você muda seu aplicativo para tratar o Amazon Keyspaces como o armazenamento de dados primário e o Cassandra como o armazenamento de dados secundário em uma única etapa. Você pode fazer isso usando um sinalizador de AWS AppConfig recurso para controlar a eleição dos armazenamentos de dados primários e secundários na instância do aplicativo. Para obter mais informações sobre sinalizadores de atributos, consulte [Creating a feature flag configuration profile in AWS AppConfig](https://docs.aws.amazon.com/appconfig/latest/userguide/appconfig-creating-configuration-and-profile-feature-flags.html).
Depois de tornar o Amazon Keyspaces o armazenamento de dados principal, você monitora o comportamento e o desempenho do aplicativo, garantindo que o Amazon Keyspaces atenda aos seus requisitos e que a migração seja bem-sucedida.
Por exemplo, se você implementou leituras duplas para seu aplicativo, durante a fase de migração do aplicativo, você faz a transição das leituras primárias do Cassandra para o Amazon Keyspaces e as leituras secundárias do Amazon Keyspaces para o Cassandra. Após a transição, você continua monitorando e comparando os resultados conforme descrito na seção de [validação de dados](migration-online-validation.md) para garantir a consistência em ambos os bancos de dados antes de desativar o Cassandra.
Se você detectar algum problema, poderá reverter rapidamente para o estado anterior revertendo para o Cassandra como o armazenamento de dados primário. Você só prossegue para a fase de descomissionamento da migração se o Amazon Keyspaces estiver atendendo a todas as suas necessidades como armazenamento de dados primário.
![\[Usando a estratégia azul e verde para migrar um aplicativo do Apache Cassandra para o Amazon Keyspaces.\]](http://docs.aws.amazon.com/pt_br/keyspaces/latest/devguide/images/migration/online-migration-switch.png)
+ **Estratégia canário**: nessa abordagem, você gradualmente implementa a migração para um subconjunto de seus usuários ou tráfego. Inicialmente, uma pequena porcentagem do tráfego do seu aplicativo, por exemplo, 5% de todo o tráfego é roteado para a versão usando o Amazon Keyspaces como armazenamento de dados primário, enquanto o restante do tráfego continua usando o Cassandra como armazenamento de dados primário.
Isso permite que você teste minuciosamente a versão migrada com tráfego real e monitore seu desempenho, estabilidade e investigue possíveis problemas. Se você não detectar nenhum problema, poderá aumentar incrementalmente a porcentagem de tráfego roteado para o Amazon Keyspaces até que ele se torne o armazenamento de dados principal para todos os usuários e tráfego.
Essa implantação gradual minimiza o risco de interrupções generalizadas no serviço e permite um processo de migração mais controlado. Se surgirem problemas críticos durante a implantação canário, você poderá reverter rapidamente para a versão anterior usando o Cassandra como armazenamento de dados primário para o segmento de tráfego afetado. Você só prossegue para a fase de descomissionamento da migração depois de validar que o Amazon Keyspaces processa 100% dos seus usuários e tráfego conforme o esperado.
O diagrama a seguir ilustra as etapas individuais da estratégia canário.
![\[Usando a estratégia canário para migrar um aplicativo do Apache Cassandra para o Amazon Keyspaces.\]](http://docs.aws.amazon.com/pt_br/keyspaces/latest/devguide/images/migration/online-migration-canary.png)
# Desativação do Cassandra após uma migração on-line
Depois que a migração do aplicativo estiver concluída, seu aplicativo estiver totalmente em execução no Amazon Keyspaces e você tiver validado a consistência dos dados por um período de tempo, você poderá planejar a desativação do seu cluster Cassandra. Durante essa fase, você pode avaliar se os dados restantes em seu cluster do Cassandra precisam ser arquivados ou podem ser excluídos. Isso depende das políticas da sua organização para tratamento e retenção de dados.
Ao seguir essa estratégia e considerar as melhores práticas recomendadas descritas neste tópico ao planejar sua migração on-line do Cassandra para o Amazon Keyspaces, você pode garantir uma transição perfeita para o Amazon Keyspaces e, ao mesmo tempo, read-after-write manter a consistência e a disponibilidade do seu aplicativo.
A migração do Apache Cassandra para o Amazon Keyspaces pode oferecer vários benefícios, incluindo redução da sobrecarga operacional, ajuste de escala automático, segurança aprimorada e uma estrutura que ajuda você a atingir suas metas de conformidade. Ao planejar uma estratégia de migração on-line com gravações duplas, upload de dados históricos, validação de dados e implantação gradual, você pode garantir uma transição tranquila com o mínimo de interrupção para seu aplicativo e seus usuários.
A implementação da estratégia de migração on-line discutida neste tópico permite que você valide os resultados da migração, identifique e resolva quaisquer problemas e, por fim, desative sua implantação atual do Cassandra em favor do serviço Amazon Keyspaces totalmente gerenciado.
# Processo de migração off-line: Apache Cassandra para Amazon Keyspaces
As migrações off-line são adequadas para quando é possível permitir tempo de inatividade para realizar a migração. É comum entre as empresas ter janelas de manutenção para patches, grandes lançamentos ou tempo de inatividade para atualizações de hardware ou atualizações importantes. A migração off-line pode usar essa janela para copiar dados e transferir o tráfego do aplicativo do Apache Cassandra para o Amazon Keyspaces.
A migração off-line reduz as modificações no aplicativo porque não exige comunicação simultânea com o Cassandra e o Amazon Keyspaces. Além disso, com o fluxo de dados pausado, o estado exato pode ser copiado sem manter as mutações.
Neste exemplo, usamos o Amazon Simple Storage Service (Amazon S3) como uma área de preparação de dados durante a migração off-line para minimizar o tempo de inatividade. Você pode importar automaticamente os dados armazenados no formato Parquet no Amazon S3 em uma tabela do Amazon Keyspaces usando o conector Spark Cassandra e AWS Glue. Veja a seção a seguir uma visão geral de alto nível do processo. Você pode encontrar exemplos de código para esse processo no [Github.](https://github.com/aws-samples/amazon-keyspaces-examples/tree/main/scala/datastax-v4/aws-glue)
O processo de migração offline do Apache Cassandra para o Amazon Keyspaces usando o Amazon S3 requer os seguintes trabalhos. AWS Glue AWS Glue
1. Um trabalho de ETL que extrai e transforma dados de CQL e os armazena em um bucket do Amazon S3.
1. Um segundo trabalho que importa os dados do bucket para o Amazon Keyspaces.
1. Um terceiro trabalho para importar dados incrementais.
**Como realizar uma migração off-line do Cassandra para o Amazon Keyspaces em execução na Amazon EC2 em uma Amazon Virtual Private Cloud**
1. Primeiro, você pode AWS Glue exportar dados da tabela do Cassandra no formato Parquet e salvá-los em um bucket do Amazon S3. Você precisa executar um AWS Glue trabalho usando um AWS Glue conector para uma VPC onde reside a EC2 instância da Amazon que executa o Cassandra. Em seguida, usando o endpoint privado do Amazon S3, você pode salvar dados no bucket do Amazon S3.
O diagrama a seguir ilustra essas etapas:
![\[Migração de dados do Apache Cassandra da Amazon EC2 em execução em uma VPC para um bucket do Amazon S3 usando. AWS Glue\]](http://docs.aws.amazon.com/pt_br/keyspaces/latest/devguide/images/migration/migration-export.png)
1. Embaralhe os dados no bucket do Amazon S3 para melhorar a randomização de dados. Dados importados uniformemente permitem um tráfego mais distribuído na tabela de destino.
Essa etapa é necessária ao exportar dados do Cassandra com partições grandes (partições com mais de 1000 linhas) para evitar padrões de teclas de atalho ao inserir os dados no Amazon Keyspaces. Problemas com teclas de atalho causam `WriteThrottleEvents` no Amazon Keyspaces e resultam em maior tempo de carregamento.
![\[Um AWS Glue trabalho embaralha os dados de um bucket do Amazon S3 e os retorna para outro bucket do Amazon S3.\]](http://docs.aws.amazon.com/pt_br/keyspaces/latest/devguide/images/migration/migration-shuffle.png)
1. Use outro AWS Glue trabalho para importar dados do bucket do Amazon S3 para o Amazon Keyspaces. Os dados embaralhados no bucket do Amazon S3 são armazenados no formato Parquet.
![\[O trabalho de AWS Glue importação pega dados embaralhados do bucket do Amazon S3 e os move para uma tabela do Amazon Keyspaces.\]](http://docs.aws.amazon.com/pt_br/keyspaces/latest/devguide/images/migration/migration-import.png)
Para obter mais informações sobre o processo de migração off-line, consulte o workshop [Amazon Keyspaces with AWS Glue](https://catalog.workshops.aws/unlocking-amazonkeyspaces/en-US/keyspaces-with-glue)
# Usando uma solução de migração híbrida: Apache Cassandra para Amazon Keyspaces
A solução de migração a seguir pode ser considerada um híbrido entre migração on-line e off-line. Com essa abordagem híbrida, os dados são gravados no banco de dados de destino quase em tempo real, sem fornecer consistência de leitura após gravação. Isso significa que os dados recém-gravados não estarão imediatamente disponíveis e que atrasos são esperados. Se você precisar de consistência de leitura após gravação, consulte [Migração on-line para o Amazon Keyspaces: estratégias e melhores práticas](migrating-online.md).
Para uma migração quase em tempo real do Apache Cassandra para o Amazon Keyspaces, você pode escolher entre dois métodos disponíveis.
+ **CQLReplicator**— (Recomendado) CQLReplicator é um utilitário de código aberto disponível no [Github](https://github.com/aws-samples/cql-replicator) que ajuda você a migrar dados do Apache Cassandra para o Amazon Keyspaces quase em tempo real.
Para determinar as gravações e atualizações a serem propagadas para o banco de dados de destino, CQLReplicator escaneia o intervalo de tokens do Apache Cassandra e usa um AWS Glue trabalho para remover eventos duplicados e aplicar gravações e atualizações diretamente no Amazon Keyspaces.
+ **Captura de dados de alterações (CDC)**: se você estiver familiarizado com o Cassandra CDC, o recurso CDC integrado do Apache Cassandra, que permite capturar alterações copiando o log de confirmação em um diretório CDC separado, é outra opção para implementar uma migração híbrida.
Você pode fazer isso replicando as alterações de dados no Amazon Keyspaces, tornando o CDC uma opção alternativa para cenários de migração de dados.
Se você não precisar de consistência de leitura após gravação, você pode usar o pipeline CQLReplicator ou o CDC para migrar dados do Apache Cassandra para o Amazon Keyspaces com base em suas preferências e familiaridade com as ferramentas usadas em cada solução. Serviços da AWS Usar esses métodos para migrar dados quase em tempo real pode ser considerado uma abordagem híbrida de migração que oferece uma alternativa à migração on-line.
Essa estratégia é considerada uma abordagem híbrida porque, além das opções descritas neste tópico, você precisa implementar algumas etapas do progresso da migração on-line, por exemplo, a cópia histórica dos dados e as estratégias de migração de aplicativos discutidas no tópico de [migração on-line](migrating-online.md).
As seções a seguir detalham mais as opções de migração híbrida.
**Topics**
+ [Migre dados usando CQLReplicator](migration-hybrid-cql-rep.md)
+ [Migre dados usando a captura de dados de alteração (CDC)](migration-hybrid-cdc.md)
# Migre dados usando CQLReplicator
Com [CQLReplicator](https://github.com/aws-samples/cql-replicator), você pode ler dados do Apache Cassandra quase em tempo real por meio da digitalização inteligente do token ring do Cassandra usando consultas CQL. CQLReplicator não usa o Cassandra CDC e, em vez disso, implementa uma estratégia de armazenamento em cache para reduzir as penalidades de desempenho de escaneamentos completos.
Para reduzir o número de gravações no destino, remove CQLReplicator automaticamente os eventos de replicação duplicados. Com isso CQLReplicator, você pode ajustar a replicação de alterações do banco de dados de origem para o banco de dados de destino, permitindo uma migração quase em tempo real dos dados do Apache Cassandra para o Amazon Keyspaces.
O diagrama a seguir mostra a arquitetura típica de um CQLReplicator trabalho usandoAWS Glue.
1. **Para permitir o acesso ao Apache Cassandra em execução em uma VPC privada, configure uma AWS Glue conexão com o tipo de conexão Rede.**
1. Para remover duplicatas e ativar o armazenamento em cache de chaves com o CQLReplicator trabalho, configure o Amazon Simple Storage Service (Amazon S3).
1. O banco de dados de origem verificado do fluxo de CQLReplicator trabalho muda diretamente para o Amazon Keyspaces.
![\[Usando CQLReplicator para migrar dados do Apache Cassandra para o Amazon Keyspaces.\]](http://docs.aws.amazon.com/pt_br/keyspaces/latest/devguide/images/migration/hybrid-migration-CQLRep.png)
Para obter mais informações sobre o uso do processo de migração CQLReplicator, consulte a postagem a seguir no blog de AWS banco de dados [Migrar cargas de trabalho do Cassandra para o Amazon Keyspaces CQLReplicator usando e a orientação prescritiva Migrar cargas](https://aws.amazon.com/blogs/database/migrate-cassandra-workloads-to-amazon-keyspaces-using-cqlreplicator/) [de trabalho AWS do Apache](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/migrate-apache-cassandra-workloads-to-amazon-keyspaces-using-aws-glue.html) Cassandra para o Amazon Keyspaces usando. AWS Glue
# Migre dados usando a captura de dados de alteração (CDC)
Se você já está familiarizado com a configuração de um pipeline de captura de dados de alteração (CDC) com o [Debezium](https://debezium.io/), você pode usar essa opção para migrar dados para o Amazon Keyspaces como alternativa ao uso. CQLReplicator O Debezium é uma plataforma distribuída de código aberto para CDC, projetada para monitorar um banco de dados e capturar mudanças em nível de linha de forma confiável.
O [conector Debezium para Apache Cassandra](https://debezium.io/documentation/reference/stable/connectors/cassandra.html) carrega as alterações no Amazon Managed Streaming for Apache Kafka (Amazon MSK) para que elas possam ser consumidas e processadas por consumidores downstream que, por sua vez, gravam os dados no Amazon Keyspaces. Para obter mais informações, consulte a [orientação para a migração contínua de dados do Apache Cassandra para o Amazon Keyspaces](https://aws.amazon.com/solutions/guidance/continuous-data-migration-from-apache-cassandra-to-amazon-keyspaces/).
Para resolver quaisquer possíveis problemas de consistência de dados, você pode implementar um processo com o Amazon MSK em que um consumidor compara as chaves ou partições no Cassandra com as do Amazon Keyspaces.
Para implementar essa solução com sucesso, recomendamos considerar o seguinte.
+ Como analisar o registro de confirmação do CDC, por exemplo, como remover eventos duplicados.
+ Como manter o diretório CDC, por exemplo, como excluir registros antigos.
+ Como lidar com falhas parciais no Apache Cassandra, por exemplo, se uma gravação só for bem-sucedida em uma das três réplicas.
+ Como lidar com a alocação de recursos, por exemplo, aumentando o tamanho da instância para atender aos requisitos adicionais de CPU, memória, DISCO e E/S para o processo CDC que ocorre em um nó.
Esse padrão trata as mudanças do Cassandra como uma “dica” de que uma chave pode ter mudado em relação ao seu estado anterior. Para determinar se há alterações a serem propagadas para o banco de dados de destino, você deve primeiro ler do cluster Cassandra de origem usando uma operação de `LOCAL_QUORUM` para receber os registros mais recentes e depois gravá-los no Amazon Keyspaces.
No caso de exclusões ou atualizações de intervalos, talvez seja necessário realizar uma comparação com a partição inteira para determinar quais eventos de gravação ou atualização precisam ser gravados no banco de dados de destino.
Nos casos em que as gravações não são idempotentes, você também precisa comparar suas gravações com o que já está no banco de dados de destino antes de gravar no Amazon Keyspaces.
O diagrama a seguir mostra a arquitetura típica de um pipeline CDC usando o Debezium e o Amazon MSK.
![\[Usando um pipeline de captura de dados de alteração para migrar dados do Apache Cassandra para o Amazon Keyspaces.\]](http://docs.aws.amazon.com/pt_br/keyspaces/latest/devguide/images/migration/hybrid-migration-CDC.png)