Os usuários me perguntaram diversas vezes por que certas propriedades de configuração do Cassandra 4.0 conf/cassandra.yamlnão estão mais no 4.1.
Por exemplo, o sinalizador que habilita o recurso experimental SASI:
enable_sasi_indexes: false
Para onde foram essas propriedades?
Os nós parecem estar usando mais memória do que quando estavam em execução com o Cassandra 2.1.
Quando os nós foram atualizados para uma versão mais recente do Cassandra, a utilização de memória nos servidores subitamente disparou, com alguns nós relatando erros de falta de memória. O que está causando esse comportamento?
O driver DBeaver Cassandra está disponível apenas na versão Pro. Como me conecto a um cluster Cassandra se estiver usando o Community Edition?
Uma empresa está executando um aplicativo de terceiros [de código fechado] que se conecta ao seu cluster Cassandra de código aberto. Eles gostariam de migrar para um Cassandra como serviço baseado em nuvem, mas precisam saber se o aplicativo pode suportá-lo.
Como eles podem determinar a versão do driver que o aplicativo está usando?
Ultimamente, fala-se um pouco sobre o uso de visualizações materializadas (MV) no Cassandra. Como usuário comum, é difícil saber se é ou não uma boa ideia usar MVs.
Qual é a recomendação para MVs e há orientações disponíveis sobre o assunto?
Um novo nó que está sendo adicionado a um cluster Cassandra é incapaz de fofocar com nós de propagação.
Outro sintoma é quando um existente que foi reiniciado não consegue fofocar com outros nós do cluster relatando o seguinte erro durante a inicialização:
ERROR [main] 2019-08-15 18:46:32,241 CassandraDaemon.java:749 - Exception encountered during startup
java.lang.RuntimeException: Unable to gossip with any peers
at org.apache.cassandra.gms.Gossiper.doShadowRound(Gossiper.java:1435) ~[apache-cassandra-3.11.4.jar:3.11.4]
at org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:566) ~[apache-cassandra-3.11.4.jar:3.11.4]
at org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:823) ~[apache-cassandra-3.11.4.jar:3.11.4]
at org.apache.cassandra.service.StorageService.initServer(StorageService.java:683) ~[apache-cassandra-3.11.4.jar:3.11.4]
at org.apache.cassandra.service.StorageService.initServer(StorageService.java:632) ~[apache-cassandra-3.11.4.jar:3.11.4]
at org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:388) ~[apache-cassandra-3.11.4.jar:3.11.4]
at org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:620) ~[apache-cassandra-3.11.4.jar:3.11.4]
at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:732) ~[apache-cassandra-3.11.4.jar:3.11.4]
Em alguns casos, outros nós são capazes de ver o nó afetado como operacional, mas um nó problemático é incapaz de fofocar com outros nós. Aqui está um exemplo de saída de nodetool gossipinfo:
/10.1.2.4
generation:0
heartbeat:0
/10.1.2.3
generation:0
heartbeat:0
/10.1.2.6
generation:1444263348
heartbeat:6232
...
DC:DC1
STATUS:NORMAL,-1041938454866204344
...
/10.1.2.5
generation:0
heartbeat:0
Um outro sintoma é que o nó afetado vê os nós em outro controlador de domínio como "inativos" ( DNou inativos/normais), conforme mostrado neste exemplo nodetool statusde saída:
Datacenter: r1
==============
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns Host ID Rack
DN 10.1.2.5 ? 256 9.0% 5279619a-550c-42b3-8150-61ad24f828f3 r1
DN 10.1.2.3 ? 256 9.1% 5d1fa459-cdac-4658-b68d-c6e0933afcee r1
DN 10.1.2.4 ? 256 10.5% a8f35c63-6a76-4e95-99f1-bef65d785366 r1
Datacenter: DC1
===============
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns Host ID Rack
UN 10.1.2.6 18.9 GB 256 9.5% 36fdcf57-0274-43b8-a501-c0e475e3e30b RAC1
Um cluster Cassandra, que na maior parte está operacional, às vezes experimenta interrupções de serviço, especialmente quando um (ou mais) nó não consegue se comunicar com outros nós no cluster.
Um sintoma são os nós subindo e descendo aleatoriamente sem motivo aparente. Aqui está um exemplo extraído de um system.lognó:
INFO [GossipTasks:1] 2016-04-29 02:47:32,559 Gossiper.java:1001 - InetAddress /10.1.2.3 is now DOWN
INFO [GossipTasks:1] 2016-04-29 02:50:47,123 Gossiper.java:1001 - InetAddress /10.1.2.4 is now DOWN
INFO [GossipTasks:1] 2016-04-29 02:54:59,640 Gossiper.java:1001 - InetAddress /10.1.2.5 is now DOWN
INFO [SharedPool-Worker-2] 2016-04-29 03:01:23,828 Gossiper.java:987 - InetAddress /10.1.2.4 is now UP
INFO [SharedPool-Worker-1] 2016-04-29 03:01:59,432 Gossiper.java:987 - InetAddress /10.1.2.5 is now UP
INFO [SharedPool-Worker-7] 2016-04-29 03:02:01,839 Gossiper.java:987 - InetAddress /10.1.2.3 is now UP
Da mesma forma, diferentes nós parecem estar inativos na nodetool statussaída, dependendo do nó em que o comando foi executado, por exemplo:
Datacenter: Cassandra
=====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns Host ID Rack
DN 10.1.2.3 8.97 GB 256 ? a50dfef5-229d-4d15-89d9-971bec01094b rack1
UN 10.1.2.5 8.9 GB 256 ? a16b71a2-9b95-4669-a6bd-d7326bd279e2 rack1
DN 10.1.2.4 9.09 GB 256 ? ac01b6f9-3cb9-47ff-83c6-0404836386eb rack1
UN 10.1.2.6 10.65 GB 256 ? 9c0ef3a2-aad7-4d06-b015-f32ddccac750 rack1
O que poderia estar causando esse problema?
Gostaria de me conectar ao meu Astra DB do Pentaho Data Integration (PDI também conhecido como "Spoon", anteriormente KETTLE). Como configuro o PDI?
Gostaria de me conectar ao meu Astra DB a partir do TablePlus (cliente GUI do banco de dados). Como configuro o TablePlus?
Por que os nós do Cassandra relatam tempos limite nos logs durante períodos de baixo tráfego?
O system.logrelatório de nós ConnectTimeoutExceptionentre nós ou erros de "soquete fechado".
Os operadores do Cassandra estão preocupados com a vulnerabilidade à exploração identificada no CVE-2021-44521.
Que medidas as operadoras podem tomar para mitigar o risco e a exposição à vulnerabilidade?
Como as junções do lado do servidor não são suportadas no CQL, as junções do lado do cliente são a preferência como solução alternativa?
Como migrar tabelas de aplicativos em um cluster Cassandra existente para um novo cluster?
O novo cluster tem uma topologia e atribuições de token diferentes para o cluster de origem.
Essa é uma pergunta comum dos operadores do Cassandra que desejam migrar dados de um cluster para outro.
Qual seria o procedimento para restaurar instantâneos de um cluster Cassandra para outro cluster com configuração idêntica?
Essa pergunta surge com bastante frequência. Para aqueles que são novos no Cassandra e particularmente na modelagem de dados, quais ferramentas estão disponíveis?
O Developer Studio costumava estar disponível na interface do usuário da Web do Astra, que fornecia uma interface semelhante a um notebook para interagir com o banco de dados.
Parece que não faz mais parte do Astra Dashboard. Ainda é possível se conectar ao Astra DB usando o DataStax Studio?
Em uma situação em que um nó continua subindo e descendo (por exemplo, fica temporariamente sem resposta devido ao GC), existe uma maneira de limitar as dicas armazenadas para o nó problemático para evitar o acúmulo de arquivos de dicas?
Ao configurar listas de acesso de firewall (ACLs), é necessário abrir a porta de gossip entre nós para todos os nós em um cluster Cassandra?
Por que a execução nodetoolretorna a seguinte exceção?
nodetool: Failed to connect to '127.0.0.1:7199' - \
URISyntaxException: 'Malformed IPv6 address at index 7: rmi://[127.0.0.1]:7199'.
Essa pergunta é comumente relatada por usuários do Cassandra após atualizar o Java nos servidores.
Há casos em que os operadores veem o seguinte aviso nos logs do Cassandra:
WARN ... Replica filtering protection has cached over 2000 rows during query \
[SELECT ... FROM ... WHERE ...]. (See 'cached_replica_rows_warn_threshold' in cassandra.yaml.)
Ou, na pior das hipóteses, um erro:
ERROR ... Replica filtering protection has cached over 32000 rows during query \
[SELECT ... FROM ... WHERE ...]. (See 'cached_replica_rows_fail_threshold' in cassandra.yaml.)
O que essas entradas de log significam?