Primeiros passos com o Apache Cassandra
Introdução
Agora que sabemos o passo a passo para a instalação do Cassandra (veja aqui), vamos falar dos primeiros passos para sua administração. Aqui ainda estamos longe de um ambiente de produção, porém mais próximos. Neste momento vamos aceitar apenas conexões locais e explorar algumas opções disponíveis para interagir com o Cassandra.
Iniciando o Cassandra
Se você instalou o Cassandra como fizemos no último artigo, você deve ter um serviço chamado Cassandra na sua VM. Se não tiver, tente o systemctl daemon-reload ou o service cassandra start fará isso automaticamente. Mas ainda não inicie o Cassandra.
[rocky@node1 ~]$ sudo service cassandra status
Unit cassandra.service could not be found.
[rocky@node1 ~]$ sudo systemctl daemon-reload
[rocky@node1 ~]$ sudo service cassandra status
● cassandra.service - LSB: distributed storage system for structured data
Loaded: loaded (/etc/rc.d/init.d/cassandra; generated)
Active: inactive (dead)
Docs: man:systemd-sysv-generator(8)
[rocky@node1 ~]$
Também antes de startar o Cassandra, vamos dar uma olhada nas portas que nosso server está ouvindo. Se quiser mais informações sobre isso, recomendo uma lida nesse post. Neste caso o ss substitui o netstat.
[rocky@node1 ~]$ ss -nltp
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0 128 0.0.0.0:111 0.0.0.0:*
LISTEN 0 128 0.0.0.0:22 0.0.0.0:*
LISTEN 0 128 [::]:111 [::]:*
LISTEN 0 128 [::]:22 [::]:*
Agora vamos startar nosso Cassandra. Ele leva alguns minutos para subir e quando finalizar veremos que nosso server agora ouve em mais algumas portas:
[rocky@node1 ~]$ sudo service cassandra start
Starting cassandra (via systemctl): [ OK ]
[rocky@node1 ~]$
[rocky@node1 ~]$ ss -nltp
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0 128 0.0.0.0:111 0.0.0.0:*
LISTEN 0 2048 127.0.0.1:9042 0.0.0.0:*
LISTEN 0 128 0.0.0.0:22 0.0.0.0:*
LISTEN 0 512 127.0.0.1:7000 0.0.0.0:*
LISTEN 0 50 127.0.0.1:39321 0.0.0.0:*
LISTEN 0 50 127.0.0.1:7199 0.0.0.0:*
LISTEN 0 128 [::]:111 [::]:*
LISTEN 0 128 [::]:22 [::]:*
O que isso quer dizer: o Cassandra agora ouve nas portas 9042, 7000 e 7199 (entre outras e podem ser diferentes se você usar SSL). A porta 9042 (native protocol port) recebe conexões de clientes, é o que faz a porta 3306 no MySQL, 1521 no Oracle. Já a porta 7000 (storage port) é usada para comunicação entre os nodes de Cassandra e a porta 7199 (JMX port) é usada para fins de monitoração ou administração através do JMX (vamos falar disso em outro artigo, é importante).
Conectando ao Cassandra
Nosso client do Cassandra é o CQLSH, escrito em python. É o nosso SQLPlus do Oracle, mysql do MySQL, mongosh do MongoDB. É nossa tela preta, nosso command line, disponível nos próprios nodes do Cassandra. Se foi fácil instalar e startar o Cassandra, conectar nele é ainda mais fácil.
[rocky@node1 ~]$ cqlsh
Connected to Test Cluster at 127.0.0.1:9042
[cqlsh 6.1.0 | Cassandra 4.1.2 | CQL spec 3.4.6 | Native protocol v5]
Use HELP for help.
cqlsh> desc keyspaces
system system_distributed system_traces system_virtual_schema
system_auth system_schema system_views
cqlsh> exit
[rocky@node1 ~]$
Na conexão já conseguimos obter algumas informações, como o nome do cluster (Test Cluster), interface (127.0.0.1) e porta (9042), versão do cqlsh (6.1.0) e do Cassandra (4.1.2), além da versão da especificação do CQL, Cassandra Query Language, (3.4.6) e por fim a versão do Native protocol em uso (v5).
Se você executar um desc keyspaces, você verá todas as keyspaces que existem atualmente. Por enquanto não vou me aprofundar no cqlsh porque nos próximos artigos vamos falar de estruturas lógicas e aí sim fará mais sentido essa conversa.
nodetool
Uma das principais ferramentas que usaremos para administrar nossos clusters de Cassandra é o nodetool. Há muito o que discutir sobre ela, vamos ter um post dedicado às várias opções que ela tem. A primeira vamos usar agora, uma forma de ver a saúde e quem faz parte do nosso cluster, bem como qual seu datacenter e rack. Assim como o DB, o nodetool ainda não exige credenciais, um ponto que discutiremos no futuro.
As informações importantes que o nodetool status nos mostra são:
- Status/State. Com um cluster rodando, é importante que todos os nodes estejam com UN, que significa que o node está Up e Normal. Outros estágios que veremos é UJ como estamos adicionando um node no cluster e UL ou DL quando estamos removendo um node.
- Datacenter. Visto que podemos controlar o número de réplicas ou mesmo a consistência por datacenter, essa informação é bastante relevante.
- Rack: O Cassandra possui uma característica que é de gravar réplicas em racks diferentes, portanto essa informação também é importante.
- Endereço IP: Este é o endereço IP da interface do node
Por enquanto isso é suficiente para termos uma ideia. Neste caso você pode notar que nosso único node está no datacenter1, rack1 e com Status/State Up e Normal (UN). Além disso vemos que nosso node possui IP 127.0.0.1
[rocky@node1 ~]$ nodetool status
Datacenter: datacenter1
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns (effective) Host ID Rack
UN 127.0.0.1 104.34 KiB 16 100.0% 8ff6c64d-ca51-4d37-9a44-abb498c96ba4 rack1
Arquivos de configuração
De volta o Linux, vou mostrar os principais arquivos de configuração do Cassandra. Eles normalmente ficam em /etc/cassandra/conf para as instalações com gerenciador de pacotes. O principal deles é o cassandra.yaml e nele vamos encontrar uma variedade de parâmetros que controlam onde os dados serão armazenados (data_file_directories), o nome do cluster (cluster_name) entre muitas outras coisas.
- /etc/cassandra/conf/cassandra.yaml
Outros arquivos que usamos para configurar o JMX, nome do DC e Rack quando usamos GossipingPropertyFileSnitch e as configurações do Java são respectivamente:
- /etc/cassandra/conf/cassandra-env.sh
- /etc/cassandra/conf/cassandra-rackdc.properties
- /etc/cassandra/conf/cassandra.yaml
No próximo artigo que vamos criar nosso primeiro cluster, discutiremos os parâmetros que precisam ser alterados. Não vou entrar em muitos detalhes aqui.
Diretório de dados
Um parâmetro que gostaria de comentar agora é o data_file_directories. Seu valor default é /var/lib/cassandra/data, e representa onde seus dados serão armazenados. Se a gente listar o conteúdo deste diretório, veremos nada mais nada menos que nossas keyspaces:
[rocky@node1 ~]$ ls /var/lib/cassandra/data
system system_auth system_distributed system_schema system_traces
[rocky@node1 ~]$
Se olharmos um nível acima, no /var/lib/cassandra, veremos outras estruturas importantes que falaremos pouco a pouco, como commitlogs e hints:
[rocky@node1 ~]$ ls /var/lib/cassandra
commitlog data hints saved_caches
[rocky@node1 ~]$
Limpando nosso servidor
Por fim, uma coisa que precisaremos fazer bastante quando estudamos Cassandra é limpar todo o conteúdo de um cluster, seja pra mudar o cluster_name ou o número de tokens.
Agora que sabemos onde estão estas estruturas, basta pararmos nosso serviço do cassandra e limpar todo o conteúdo do /var/lib/cassandra/.
[rocky@node1 ~]$ sudo service cassandra stop
[rocky@node1 ~]$
[rocky@node1 ~]$ rm -rf /var/lib/cassandra/*
[rocky@node1 ~]$
Na próxima vez que você startar o Cassandra ele sobe novinho em folha, como se fosse a primeira vez.
Conclusão
Aqui vimos como inicializar o nosso primeiro ambiente Cassandra. Ainda é um ambiente local, muito diferente do que costumamos usar em produção, que é um cluster com múltiplos nodes. Vamos usar as informações discutidas aqui para entender os próximos passos e criar nosso primeiro cluster.
Você também pode gostar
Login com: Google