system.local e system.peers
Introdução
Nos nossos artigos sobre nosso primeiro cluster e adicionando mais nodes, falamos um pouquinho do nodetool e como ele nos mostra os membros do nosso cluster. Porém, às vezes queremos obter essa informação através de uma query. É sobre isso que vamos falar hoje, como obter informações sobre o próprio node e seus pares, usando as tabelas system.local e system.peers.
Nodetool
Conforme já falamos anteriormente, o nodetool status nos mostra algumas informações interessantes sobre nosso cluster.
[rocky@ip-10-0-7-113 ~]$ nodetool status
Datacenter: datacenter1
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns (effective) Host ID Rack
UN 10.0.12.231 234.15 KiB 8 72.4% 93249f03-45d7-4441-b396-63685631983e rack3
UN 10.0.7.113 202.94 KiB 8 63.7% af3feb69-92fe-4781-ab74-6671a6a77fbd rack1
UN 10.0.3.129 221.97 KiB 8 63.9% 2c532de2-5619-4ff0-ac10-853479bc2db0 rack2
system.local
Porém também há outras informações que não estão mostradas aí, talvez apareça em alguma outra opção do nodetool. Vamos olhar para a system.local. Conectando no nosso cqlsh, podemos ver o conteúdo da system.local:
[rocky@ip-10-0-7-113 ~]$ cqlsh
Connected to AnsibleApache at 10.0.7.113:9042
[cqlsh 6.1.0 | Cassandra 4.1-alpha1 | CQL spec 3.4.5 | Native protocol v5]
Use HELP for help.
cassandra@cqlsh> desc system.local
CREATE TABLE system.local (
key text PRIMARY KEY,
bootstrapped text,
broadcast_address inet,
broadcast_port int,
cluster_name text,
cql_version text,
data_center text,
gossip_generation int,
host_id uuid,
listen_address inet,
listen_port int,
native_protocol_version text,
partitioner text,
rack text,
release_version text,
rpc_address inet,
rpc_port int,
schema_version uuid,
tokens set,
truncated_at map<uuid, blob>
) …;
De cara já vemos que há várias informações que ainda não havíamos visto. A maioria delas foram configuradas no cassandra.yaml ou são referentes à instalação/versão do cassandra. Vamos dar uma olhada no conteúdo:
[rocky@ip-10-0-7-113 ~]$ cqlsh
Connected to AnsibleApache at 10.0.7.113:9042
[cqlsh 6.1.0 | Cassandra 4.1-alpha1 | CQL spec 3.4.5 | Native protocol v5]
Use HELP for help.
cassandra@cqlsh> select key, cluster_name, data_center, rack, schema_version, release_version from system.local;
key | cluster_name | data_center | rack | schema_version | release_version
-------+---------------+-------------+-------+--------------------------------------+-----------------
local | AnsibleApache | datacenter1 | rack1 | 54e17321-3f2e-37ca-9b08-d91ba7bdd369 | 4.1-alpha1
Nodetool describecluster
Parte destas informações são expostas por outra opção do nodetool, a describecluster. Aqui ele nos mostra o cluster_name, endpoint_snitch e outras informações que ainda não discutimos. Além disso, na versão 4.1 há um resumo de algumas estatísticas importantes, além da lista de keyspaces e seus Replication Factors.
[rocky@ip-10-0-7-113 ~]$ nodetool describecluster
Cluster Information:
Name: AnsibleApache
Snitch: org.apache.cassandra.locator.GossipingPropertyFileSnitch
DynamicEndPointSnitch: enabled
Partitioner: org.apache.cassandra.dht.Murmur3Partitioner
Schema versions:
54e17321-3f2e-37ca-9b08-d91ba7bdd369: [10.0.3.129, 10.0.7.113, 10.0.12.231]
Stats for all nodes:
Live: 3
Joining: 0
Moving: 0
Leaving: 0
Unreachable: 0
Data Centers:
datacenter1 #Nodes: 3 #Down: 0
Database versions:
4.1.0-alpha1: [10.0.3.129:7000, 10.0.7.113:7000, 10.0.12.231:7000]
Keyspaces:
system_schema -> Replication class: LocalStrategy {}
system -> Replication class: LocalStrategy {}
system_auth -> Replication class: SimpleStrategy {replication_factor=1}
system_distributed -> Replication class: SimpleStrategy {replication_factor=3}
system_traces -> Replication class: SimpleStrategy {replication_factor=2}
[rocky@ip-10-0-7-113 ~]$
system.peers
Na tabela system.local obtemos detalhes do node que estamos conectados. Na system.peers (peers = pares em português), ao contrário, mostra as informações dos outros nodes conectados no cluster. Podemos começar olhando suas colunas:
cassandra@cqlsh> desc system.peers;
CREATE TABLE system.peers (
peer inet PRIMARY KEY,
data_center text,
host_id uuid,
preferred_ip inet,
rack text,
release_version text,
rpc_address inet,
schema_version uuid,
tokens set
)...
Vamos fazer uma consulta para ver esses valores. De novo, vou buscar só alguns deles, mas acredito que a ideia está clara do que podemos fazer.
cassandra@cqlsh> select peer, data_center, rack, release_version,schema_version from system.peers;
peer | data_center | rack | release_version | schema_version
-------------+-------------+-------+-----------------+--------------------------------------
10.0.12.231 | datacenter1 | rack3 | 4.1-alpha1 | 54e17321-3f2e-37ca-9b08-d91ba7bdd369
10.0.3.129 | datacenter1 | rack2 | 4.1-alpha1 | 54e17321-3f2e-37ca-9b08-d91ba7bdd369
schema_version
Aqui é uma conversa interessante para outro artigo, mostrando um passo a passo de como isso funciona, mas aqui só queria deixar registrado que para o schema_version a gente precisa ter todos os nodes com o mesmo valor. Caso este valor esteja diferente ao longo dos nodes, o Cassandra não permiter mais que você faça alterações em seu schema (comandos DDLs).
Conclusão
Aqui queria mostrar que além das informações mostradas pelo nodetool, podemos obter informações através de algumas tabelas. Normalmente o nodetool é suficiente, mas fica esta alternativa para casos que você precise de alguma coisa específica.
Caso queira aprofundar nesta linha, sugiro verificar as tabelas da keyspace system e no que elas conseguem te ajudar.
Você também pode gostar
Login com: Google