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=trueo 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.