Adicionando nodes no cluster de Cassandra
Introdução
No artigo anterior falamos sobre todas as configurações que são necessárias para nosso cluster. Agora chegou a hora de adicionar nodes no cluster. Vou seguir do ponto que paramos lá. Finalmente chegou a parte fácil.
Adicionando nodes no cluster
Seria hora daquela conversa toda sobre escalar seu banco de dados horizontalmente, mas você já deve ter ouvido isso mais de 30 vezes só esta semana. Então vamos partir direto para a parte de mão na massa.
Novamente aqui, precisamos que nossos novos nodes tenham tudo instalado corretamente, como fizemos aqui: java, python, cassandra. Também precisamos de toda a configuração que fizemos no último artigo.
Uma vez que garantimos que tudo está em ordem, vamos startar o cassandra no nosso node2.
[rocky@node2 ~]$ cat /etc/cassandra/conf/cassandra.yaml | egrep -v '^$|^#' | egrep '^cluster_name|^listen_interface|^rpc_interface|^storage_port|^ssl_storage_port|^native_transport_port|^rpc_address|^lister_address|seeds'
cluster_name: 'Yadax'
# seeds is actually a comma-delimited list of addresses.
- seeds: "10.0.7.8,10.0.11.239"
storage_port: 7000
ssl_storage_port: 7001
listen_interface: eth0
native_transport_port: 9042
rpc_interface: eth0
[rocky@node2 ~]$
[rocky@node2 ~]$ sudo service cassandra start
Starting cassandra (via systemctl): [ OK ]
[rocky@node2 ~]$
O que acontece quando adicionamos um node?
Entender a resposta desta pergunta é um ponto crítico para compreender como funciona um cluster Cassandra. Vou tentar explicar os conceitos básicos envolvidos aqui.
Os nodes que fazem parte do cluster ou datacenter são responsáveis pela totalidade dos dados. Quando adicionamos um novo node, ele assume a responsabilidade por parte dos dados. Com isso, os antigos nodes deixam de ser responsáveis por parte deles. Aqui temos duas implicações:
1 – O novo node precisa receber os dados que passa a ser responsável. Esse processo é chamado de bootstrap e ele ocorre automaticamente sempre que adicionamos um node, exceto em dois casos: quando o node é um seed ou quando explicitamos o parâmetro auto_bootstrap: false no cassandra.yaml. Este é um processo que pode levar um tempo considerável para clusters grandes.
2 – Os nodes antigos que deixaram de ser responsáveis por parte dos dados, não os limpam automaticamente. Precisamos executar um processo de cleanup, usando o nodetool.
Nodetool
O que nos mostra agora o nodetool status? No mesmo datacenter (dc1), o segundo node fica no rack2. Vemos os dois como UN. Para ver o node com status UJ, precisamos executar o nodetool status antes de finalizar o bootstrap.
[rocky@node1 ~]$ nodetool status
Datacenter: dc1
===============
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns (effective) Host ID Rack
UN 10.0.11.239 70.21 KiB 16 100.0% 10aed899-3cce-4c53-a77f-830d990949a3 rack2
UN 10.0.7.8 125.39 KiB 16 100.0% cab5eaa2-7816-4750-88be-ab94ad9c89b7 rack1
[rocky@node1 ~]$
Vamos agora adicionar o terceiro node, que está em outro datacenter. Novamente, se estiver tudo certinho, basta startar o Cassandra.
Neste caso eu fui rápido no gatilho e consegui pegar o status joining. Repare que o novo node aparece em outro datacenter.
[rocky@node1 ~]$ nodetool status
Datacenter: dc1
===============
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns (effective) Host ID Rack
UN 10.0.11.239 70.21 KiB 16 100.0% 10aed899-3cce-4c53-a77f-830d990949a3 rack2
UN 10.0.7.8 125.39 KiB 16 100.0% cab5eaa2-7816-4750-88be-ab94ad9c89b7 rack1
Datacenter: dc2
===============
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns (effective) Host ID Rack
UJ 10.0.3.116 30.42 KiB 16 ? dfceb2bd-9c30-41af-914c-db50ff4ff8e6 rack1
nodetool cleanup
No nosso caso o cluster é novo, não inserimos nenhum dado antes de adicionar os nodes, mas o procedimento de limpeza é executar o nodetool cleanup. Aqui ele executará quase instantaneamente, mas fique ligado que clusters grandes consomem bastante tempo e espaço em disco (temporariamente).
Portanto, em todos os nodes antigos precisamos:
[rocky@node1 ~]$ nodetool cleanup
[rocky@node1 ~]$
E como ficou nosso status final?
[rocky@node1 ~]$ nodetool status
Datacenter: dc1
===============
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns (effective) Host ID Rack
UN 10.0.11.239 70.21 KiB 16 56.9% 10aed899-3cce-4c53-a77f-830d990949a3 rack2
UN 10.0.7.8 125.39 KiB 16 67.2% cab5eaa2-7816-4750-88be-ab94ad9c89b7 rack1
Datacenter: dc2
===============
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns (effective) Host ID Rack
UN 10.0.3.116 70.23 KiB 16 76.0% dfceb2bd-9c30-41af-914c-db50ff4ff8e6 rack1
Conclusão
Finalmente temos agora nosso cluster rodando, com dois datacenters, três nodes. É claro que isto está longe de ser um ambiente de produção. Normalmente usamos pelo menos três nodes (e dois seeds) por datacenter.
Podemos expandi-lo ao tamanho desejado. Podemos ter datacenters na AWS, na OCI, na Azure. A estratégia multi cloud se baseia nisso: você tem um datacenter de Cassandra rodando na AWS junto com sua aplicação. Outro datacenter na Azure, com a aplicação também na Azure e o Cassandra se responsabiliza pela replicação, você está livre deste trabalho.
Espero que tenham gostado do conteúdo. Mais artigos sobre Cassandra virão.
Você também pode gostar
Login com: Google