• 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
      • Erro ao startar Apache Cassandra 2.2.16

      Erro ao startar Apache Cassandra 2.2.16

      • Postado por Adriano Bonacin
      • Categorias cassandra, Database, NoSQL
      • Data 22/03/2020
      • Comentários 0 comentário

      Olá pessoal, tudo bem? Vou tirar a teia de aranha do blog e escrever novamente, sobre um caso que passei na última semana. Estava rolando um dos nossos treinamentos online de Cassandra, e já nos primeiros lab, a vergonha. Estávamos utilizando o Centos 7.7, rodando em um EC2 e a versão 2.2.16 do Cassandra.

      O passo a passo: yum update, instalar o Apache Cassandra e na hora de subir:

      [root@ip-172-31-82-243 ~]# service cassandra start
      Reloading systemd:                                         [  OK  ]
      Starting cassandra (via systemctl):  Job for cassandra.service failed because a configured resource limit was exceeded. See "systemctl status cassandra.service" and "journalctl -xe" for details.
                                                                 [FAILED]

      O processo java sobe mas perdemos a gestão do serviço, precisando baixá-lo com um kill -15.

      Consultando o status:

      [root@ip-172-31-82-243 ~]# systemctl status cassandra.service
      ● cassandra.service - LSB: distributed storage system for structured data
         Loaded: loaded (/etc/rc.d/init.d/cassandra; bad; vendor preset: disabled)
         Active: failed (Result: resources) since Sun 2020-03-22 11:40:16 UTC; 1min 0s ago
           Docs: man:systemd-sysv-generator(8)
        Process: 17197 ExecStart=/etc/rc.d/init.d/cassandra start (code=exited, status=0/SUCCESS)
      
      Mar 22 11:40:16 ip-172-31-82-243.ec2.internal systemd[1]: Starting LSB: distributed storage system for structured data...
      Mar 22 11:40:16 ip-172-31-82-243.ec2.internal su[17207]: (to cassandra) root on none
      Mar 22 11:40:16 ip-172-31-82-243.ec2.internal cassandra[17197]: Starting Cassandra: OK
      Mar 22 11:40:16 ip-172-31-82-243.ec2.internal systemd[1]: New main PID 17278 does not belong to service, and PID file is not owned by root. Refusing.
      Mar 22 11:40:16 ip-172-31-82-243.ec2.internal systemd[1]: New main PID 17278 does not belong to service, and PID file is not owned by root. Refusing.
      Mar 22 11:40:16 ip-172-31-82-243.ec2.internal systemd[1]: Failed to start LSB: distributed storage system for structured data.
      Mar 22 11:40:16 ip-172-31-82-243.ec2.internal systemd[1]: Unit cassandra.service entered failed state.
      Mar 22 11:40:16 ip-172-31-82-243.ec2.internal systemd[1]: cassandra.service failed.

      Como podemos ver, ele está up.

      [root@ip-172-31-82-243 ~]# cqlsh
      Connected to Test Cluster at 127.0.0.1:9042.
      [cqlsh 5.0.1 | Cassandra 2.2.16 | CQL spec 3.3.1 | Native protocol v4]
      Use HELP for help.
      cqlsh>

      Investigando o problema, encontrei um bug na versão que utilizamos (2.2.16) devido a alguma atualização de segurança no Sistema Operacional, que já deve vir corrigido nas próximas versões.

      A solução é fazer um ajuste no script de inicialização do serviço substituindo o “su” por “runuser”, em /etc/rc.d/init.d/cassandra. São dois trechos que devem ser alterados, o start e o stop:

      ANTES
      start)
          # Cassandra startup
          echo -n "Starting Cassandra: "
          [ -d `dirname "$pid_file"` ] || \
              install -m 755 -o $CASSANDRA_OWNR -g $CASSANDRA_OWNR -d `dirname $pid_file`
          su $CASSANDRA_OWNR -c "$CASSANDRA_PROG -p $pid_file" > $log_file 2>&1
          retval=$?
          [ $retval -eq 0 ] && touch $lock_file
          echo "OK"
          ;;
      stop)
          # Cassandra shutdown
          echo -n "Shutdown Cassandra: "
          su $CASSANDRA_OWNR -c "kill `cat $pid_file`"
          retval=$?
      DEPOIS
      start)
          # Cassandra startup
          echo -n "Starting Cassandra: "
          [ -d `dirname "$pid_file"` ] || \
              install -m 755 -o $CASSANDRA_OWNR -g $CASSANDRA_OWNR -d `dirname $pid_file`
          runuser -u $CASSANDRA_OWNR -- $CASSANDRA_PROG -p $pid_file > $log_file 2>&1 <<<<<<<AQUI
          chown root.root $pid_file <<<<<<<AQUI
          retval=$?
          [ $retval -eq 0 ] && touch $lock_file
          echo "OK"
          ;;
      stop)
          # Cassandra shutdown
          echo -n "Shutdown Cassandra: "
          runuser -u $CASSANDRA_OWNR -- kill `cat $pid_file` <<<<<<<AQUI
          retval=$?

      Agora mate o processo java relacionado e faça o reload dos serviços:

      [root@ip-172-31-82-243 ~]# ps -ef | grep java
      cassand+ 17278     1  1 11:40 ?        00:00:09 /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.242.b08-0.el7_7.x86_64/jre/bin/java -ea -javaagent:/usr/share/cassandra/lib/jamm-0.3.0.jar -XX:+CMSClassUnloadingEnabled -XX:+UseThreadPriorities -XX:ThreadPriorityPolicy=42 -Xms3897M -Xmx3897M ...
      [root@ip-172-31-82-243 ~]# kill -15 17278
      [root@ip-172-31-82-243 ~]# systemctl daemon-reload

      Depois tudo deve voltar ao normal.

      [root@ip-172-31-82-243 ~]# service cassandra start
      Starting cassandra (via systemctl):                        [  OK  ]
      [root@ip-172-31-82-243 ~]# service cassandra stop
      Stopping cassandra (via systemctl):                        [  OK  ]
      [root@ip-172-31-82-243 ~]# ps -ef | grep java
      root     18062 10891  0 11:53 pts/0    00:00:00 grep --color=auto java

      Era isso, só uma pequena referência para caso alguém precise. Se quiser ver mais alguns posts, visite nosso blog. E aqui se quiser algo relacionado a Cassandra.

      Até mais.

      Tag:cassandra

      • Compartilhe:
      Adriano Bonacin

      Post anterior

      Terraform Providers
      22/03/2020

      Você também pode gostar

      upgrade
      Upgrade Cassandra 2.2 para 3.11
      29 junho, 2019
      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?