• Home
    • Sobre Nós
  • Treinamentos

    Sobre Nossos Cursos

    • Treinamentos
    • Teste seus conhecimentos
    • Perfil Instrutor – LinkedIn
  • Consultoria
    • DBA ORACLE
    • DBA CASSANDRA
    • AWS
  • Blog
  • Contato
    Alguma dúvida?
    (11) 98193-2301
    contato@yadax.com.br
    Login
    YadaxYadax
    • Home
      • Sobre Nós
    • Treinamentos

      Sobre Nossos Cursos

      • Treinamentos
      • Teste seus conhecimentos
      • Perfil Instrutor – LinkedIn
    • Consultoria
      • DBA ORACLE
      • DBA CASSANDRA
      • AWS
    • Blog
    • Contato

      cassandra

      • Home
      • Blog
      • cassandra
      • Upgrade Cassandra 2.2 para 3.11

      Upgrade Cassandra 2.2 para 3.11

      • Postado por Adriano Bonacin
      • Categorias cassandra, NoSQL
      • Data 29/06/2019
      • Comentários 0 comentário

      Introdução

      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.

       

      Pré-upgrade

      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.

      Cuidados durante o Upgrade

      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.

       

      Upgrade

      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

       Lembre-se de começar pelos seeds, aqui começaremos pelo node 172.31.86.172.

      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.

      Conclusã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.

      Tag:cassandra, NoSQL, upgrade

      • Compartilhe:
      Adriano Bonacin

      Post anterior

      Adicionar NiFi em um cluster Cloudera
      29/06/2019

      Próximo post

      AWS Free Tier
      15/09/2019

      Você também pode gostar

      bug_cassandra
      Erro ao startar Apache Cassandra 2.2.16
      22 março, 2020
      scylla_fast
      Conheça o Scylla DB
      9 maio, 2019
      dynamodb
      AWS – Rodando DynamoDB local
      3 maio, 2019

      Deixe uma resposta Cancelar resposta

      Você precisa fazer o login para publicar um comentário.

      Buscar

      Categorias

      • AWS
      • Bigdata
      • cassandra
      • Database
      • DynamoDB
      • Eventos
      • IAM
      • Linux
      • NiFi
      • NoSQL
      • Redshift
      • scala
      • scylladb
      • SSH
      • Terraform

      YADAX

      • Sobre nós
      • Blog

      Links

      • Próximos cursos

      Suporte

      • Consultoria
      • Contato

      Yadax. Todos os direitos reservados.

      • DBA CASSANDRA
      • DBA ORACLE
      • AWS
      • NoSQL

      Seu time de Data Engineer/DBA precisa de ajuda com uma nova tecnologia?

      Solicite nossos treinamentos In Company.

      Conheça

      Conecte com:

      Login com: Facebook Login com: Google

      logo

      Faça login com sua conta de site

      Conecte com:

      FacebookGoogle

      logo


      Perdeu sua senha?