Antecedentes e Observações:
Eu tenho um cluster de 3 nós em execução em produção (versão 3.11). Para a migração, tentei primeiro criar 1 novo nó com a versão cassandra 4.1.2 e adicionei esses nós ao cluster existente. Para adicionar esses nós, tive que executar -Dcassandra.skip_schema_check=true
o comando, caso contrário, o novo nó falharia na inicialização. Depois que consegui adicionar esses nós ao cluster existente, observei que os dados não estão sendo transmitidos para o novo nó da versão 3 para a versão 4. A ideia aqui era que, uma vez que os dados fossem replicados para os nós da versão 4, pudéssemos desligar os nós da versão 3 um por um e isso seria uma migração tranquila.
O documento para migração de 3.x para 4.x aqui sugere que a migração deve ser feita nó por nó e eu deveria primeiro derrubar um nó e então configurar o cassandra 4 nesse nó e então usar os mesmos arquivos de dados para executar o cassandra 4 e faça o mesmo para todos os nós.
Pergunta:
Minha pergunta é que, se eu prosseguir com a abordagem mencionada no documento datastax, chegará um momento em que a versão 4 e a versão 3 coexistirão enquanto minha carga de leitura/gravação ainda chegará ao cluster. Durante esse período, a transferência de dados entre 2 nós com versões diferentes não acontecerá, portanto, a solicitação de gravação indo para o nó da versão 4 não será replicada para o nó da versão 3 e vice-versa. Isso causará inconsistência de dados até que todos os nós sejam migrados e comecem a se comunicar entre si. Presumimos que os dados serão consistentes eventualmente aqui, mas se houver algum problema durante esse processo, não teremos como resolver os dados inconsistentes na produção. Então, quais etapas posso seguir para garantir que não haja inconsistência de dados e, se algo der errado, haja uma maneira mais fácil de corrigir os dados. E também queria entender por que a primeira abordagem mencionada acima não era suportada pelo cassandra, pois parece uma abordagem mais fácil para um desenvolvedor do ponto de vista da migração.
Existem vários usuários executando Cassandra e atualizando-os sem qualquer tempo de inatividade em seu aplicativo por muitas décadas.
Esta não é a abordagem recomendada. Se você está preocupado com o fato de seu cluster existente não suportar a carga e seus aplicativos não estarem usando os níveis de consistência corretos para leituras/gravações quando houver um nó que será desativado para reiniciar atualizações pós-binárias (de 3. x para 4.x), então você precisa primeiro expandir seu cluster adicionando novos nós com as mesmas versões 3.x exatas dos outros nós no cluster e, em seguida, fazer a atualização um por um para 4.x . Outra abordagem é descobrir um período de baixo ou nenhum tráfego e executar o processo de atualização um nó por vez, primeiro fazendo a atualização binária de 3.x para 4.x em todos os nós deste cluster e, finalmente, invocando o processo de atualização estável para converta SSTables existentes para o formato de versão mais recente.
Por exemplo, um cluster cujos nós estão executando Cassandra
3.11.15
é considerado totalmente atualizado quando todos os seus nós foram atualizados com êxito para Cassandra4.1.3
. Com apenas algumas exceções, o cluster como um todo continua a funcionar como se estivesse na versão anterior do Cassandra até que todos os nós do cluster sejam atualizados.Este não é um entendimento correto. O coordenador garantirá que a consistência de gravação será satisfeita de acordo com a configuração no driver cliente do aplicativo. Portanto, se seu aplicativo cliente tiver um nível de consistência de gravação
LOCAL_QUORUM
em uma tabela cujo keyspace tenha um fator de replicação definido como3
, ele satisfará pelo menos2
os nós de réplica que possuem a cópia de dados antes de reconhecer o cliente quando a gravação foi bem-sucedida (mesmo que um dos a réplica está ligada3.x
e a outra está na4.x
versão respectivamente).Há um guia de atualização fantástico aqui
3.x
que4.x
você deve familiarizar e seguir para o que está tentando alcançar aqui.Se precisar de ajuda adicional, você sempre pode obter uma assinatura do Luna .