Upgrade Cassandra 2.2 para 3.11
Vou voltar a falar um pouco de cassandra, agora sobre o procedimento de upgrade.
Não é raro a correria do dia a dia impedir que mantenhamos nossos softwares atualizados. A cada nova versão temos várias correções de bugs, outras features, melhorias de performance, de segurança.
Diferente de outros DBs, no Cassandra é tudo bem tranquilo. É um procedimento que, tomando alguns cuidados, tem praticamente zero downtime. Será um Rolling Upgrade, onde fazemos nó a nó enquanto os demais continuam recebendo e respondendo as requisições.
Partiremos do Apache Cassandra 2.2.14 para a última versão estável disponível, a 3.11.4. Caso você desejasse fazer o upgrade para a versão 4.0 (nesta data ainda em desenvolvimento), como o GAP entre as versões é muito grande, recomenda-se passar primeiro pela versão 3.
Cuidados que precisamos ter pré-upgrade:
– Repair em todos os nodes, se você faz isso regularmente, não precisa se preocupar com este passo.
– Backup dos seus dados e arquivos de configurações. Vai que…
– Verificar a compatibilidade dos drivers utilizados pela app, talvez seja necessário recompilá-la junto com o upgrade do driver.
Aqui você encontra a matriz de compatibilidade do driver Datastax Enterprise e do Apache Cassandra.
Em linhas gerais, os cuidados que precisamos ter durante o upgrade:
– Não habilitar novas features. Ok, estaremos bastante ocupados para pensar em habilitar alguma coisa neste momento. 🙂
– Não executar repairs. Aqui certifique-se que não tenha nenhum script agendado, algo no OpsCenter.
– Não adicione (bootstrap) ou remova nodes (decommission).
– Não execute DDL e Truncates. Certifique-se que sua aplicação não faça nada assim.
– Não habilite Change Data Capture (CDC).
– Não altere credenciais ou permissões.
– Upgrade completo do DC antes de começar o outro, começando pelos Seeds.
– Se houver algum problema com o upgrade das SSTables, você pode ter impactos de performance e consumo excessivo de discos.
– Acompanhar (tail -f) os logs em todos os nodes.
O upgrade estará completo quando todas as SSTables forem atualizadas.
Para o procedimento do upgrade, os passos serão:
– nodetool drain
– stop cassandra
– remove cassandra 2 (Será feito um backup do seu arquivo de configuração)
Erasing : cassandra-2.2.14-1.noarch 1/1
warning: /etc/cassandra/default.conf/cassandra.yaml saved as /etc/cassandra/default.conf/cassandra.yaml.rpmsave
– install cassandra 3
– ajuste configs
– start cassandra
– nodetool upgradesstables
O comando nodetool drain faz com que o node realize um flush de todas as MemTables e pare de receber conexões. Nossa App não pode perceber. Lembrando sempre de acompanhar os logs, nos outros nodes vemos a seguinte mensagem:
INFO [GossipStage:1] 2019-06-29 17:35:24,122 Gossiper.java:995 - InetAddress /172.31.86.172 is now DOWN
No próprio node vemos:
INFO [RMI TCP Connection(8)-127.0.0.1] 2019-06-29 17:35:26,775 StorageService.java:1203 - DRAINED
Neste ponto já podemos remover o binário do cassandra 2.2.14 e instalar o novo, 3.11.4. Primeiro paramos o serviço do cassandra e em seguida faremos o yum remove.
[root@ip-172-31-86-172 ~]# service cassandra stop Stopping cassandra (via systemctl): [ OK ]
[root@ip-172-31-86-172 ~]# yum remove -y cassandra Loaded plugins: fastestmirror Resolving Dependencies --> Running transaction check ---> Package cassandra.noarch 0:2.2.14-1 will be erased --> Finished Dependency Resolution Dependencies Resolved ======================================================================================================= Package Arch Version Repository Size ======================================================================================================= Removing: cassandra noarch 2.2.14-1 @cassandra 31 M Transaction Summary ======================================================================================================= Remove 1 Package Installed size: 31 M Downloading packages: Running transaction check Running transaction test Transaction test succeeded Running transaction Erasing : cassandra-2.2.14-1.noarch 1/1 warning: /etc/cassandra/default.conf/cassandra.yaml saved as /etc/cassandra/default.conf/cassandra.yaml.rpmsave warning: file /etc/cassandra/default.conf/cassandra-topology.properties: remove failed: No such file or directory warning: /etc/cassandra/default.conf/cassandra-rackdc.properties saved as /etc/cassandra/default.conf/cassandra-rackdc.properties.rpmsave warning: /etc/cassandra/default.conf/cassandra-env.sh saved as /etc/cassandra/default.conf/cassandra-env.sh.rpmsave Verifying : cassandra-2.2.14-1.noarch 1/1 Removed: cassandra.noarch 0:2.2.14-1 Complete!
Um destaque para o procedimento de remoção, em que é feito um backup do nosso cassandra.yaml atual.
Seguindo, faça a instalação do cassandra 3. No meu caso, as máquinas estão com acesso a internet, então estou usando o repositório da própria apache. Vou apenas alterar sua versão e fazer a instalação.
[root@ip-172-31-86-172 ~]# yum install -y cassandra Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile * base: centos4.zswap.net * extras: centos4.zswap.net * updates: centos4.zswap.net cassandra/signature | 833 B 00:00:00 cassandra/signature | 2.9 kB 00:00:00 !!! cassandra/primary_db | 4.2 kB 00:00:00 Resolving Dependencies --> Running transaction check ---> Package cassandra.noarch 0:3.11.4-1 will be installed --> Finished Dependency Resolution Dependencies Resolved ======================================================================================================= Package Arch Version Repository Size ======================================================================================================= Installing: cassandra noarch 3.11.4-1 cassandra 28 M Transaction Summary ======================================================================================================= Install 1 Package Total download size: 28 M Installed size: 38 M Downloading packages: cassandra-3.11.4-1.noarch.rpm | 28 MB 00:00:02 Running transaction check Running transaction test Transaction test succeeded Running transaction Installing : cassandra-3.11.4-1.noarch 1/1 warning: /etc/cassandra/default.conf/jvm.options created as /etc/cassandra/default.conf/jvm.options.rpmnew Verifying : cassandra-3.11.4-1.noarch 1/1 Installed: cassandra.noarch 0:3.11.4-1 Complete!
Vamos recuperar o cassandra.yaml que foi backupeado, fazer os ajustes desejados e startar o node novamente.
[root@ip-172-31-86-172 ~]# cp /etc/cassandra/conf/cassandra.yaml.rpmsave /etc/cassandra/conf/cassandra.yaml cp: overwrite ‘/etc/cassandra/conf/cassandra.yaml’? y [root@ip-172-31-86-172 ~]# vi /etc/cassandra/conf/cassandra.yaml [root@ip-172-31-86-172 ~]# service cassandra start Starting cassandra (via systemctl): [ OK ] [root@ip-172-31-86-172 ~]#
Veremos no log:
INFO [main] 2019-06-29 18:23:15,907 Server.java:156 - Starting listening for CQL clients on /172.31.86.172:9042 (unencrypted)... INFO [main] 2019-06-29 18:23:16,122 ThriftServer.java:116 - Binding thrift service to /172.31.86.172:9160 INFO [Thread-2] 2019-06-29 18:23:16,185 ThriftServer.java:133 - Listening for thrift clients...
Nos outros nodes:
INFO [SharedPool-Worker-1] 2019-06-29 18:23:04,178 Gossiper.java:980 - InetAddress /172.31.86.172 is now UP INFO [GossipStage:1] 2019-06-29 18:23:06,775 StorageService.java:1996 - Node /172.31.86.172 state jump to NORMAL
Agora precisamos do upgrade das SSTables. Elas são reescritas com o formato da versão atual instalada, podendo ser utilizada para upgrades ou downgrades. Você verá que os arquivos mudarão de nome. Neste ponto, a demora depende diretamente do seu volume de dados, então se seu cluster for gigante, é a hora de tomar um café, descansar um pouco. Novamente, sua aplicação não deve perceber nada.
Atualmente temos:
Após o nodetool upgradesstables, podemos conferir que os nomes foram realmente alterados. Se quiser acompanhar o andamento do upgrade, a quantidade dos arquivos é um bom indicativo.
Com isso temos nosso node em uma versão atualizada e o nodetool describecluster indica isto. Basta repetir o procedimento para os outros seeds e em seguida para os outros nodes do cluster.
Continuando nos próximos:
INFO [main] 2019-06-29 18:58:03,087 Server.java:156 - Starting listening for CQL clients on /172.31.89.197:9042 (unencrypted)... INFO [main] 2019-06-29 18:58:03,415 ThriftServer.java:116 - Binding thrift service to /172.31.89.197:9160 INFO [Thread-2] 2019-06-29 18:58:03,446 ThriftServer.java:133 - Listening for thrift clients...
...
INFO [main] 2019-06-29 19:36:11,183 Server.java:156 - Starting listening for CQL clients on /172.31.90.31:9042 (unencrypted)... INFO [main] 2019-06-29 19:36:11,619 ThriftServer.java:116 - Binding thrift service to /172.31.90.31:9160 INFO [Thread-2] 2019-06-29 19:36:11,652 ThriftServer.java:133 - Listening for thrift clients...
Por fim, vemos que agora todos nossos nodes estão na mesma versão.
É claro que é bom sempre testar bastante antes de realizar o procedimento e para isso eu tenho um script python que fica fazendo inserts a cada segundo. Serve para validar se todo o procedimento é realmente feito com zero downtime. Se quiser ajuda com o setup de um ambiente lab ou mesmo o script para validar, só dar um alô.
Curtiram? Se for realizar o procedimento e puder, me chame no whats, linkedin, face… Vai ser legal saber o que passou por aí. Dúvidas? Críticas? Sugestões? Correções? Sempre bem vindas.
Até a próxima.
Você também pode gostar
Conheça o Scylla DB
AWS – Rodando DynamoDB local
