Compartilhar via

Solucionar problemas comuns no Azure Cosmos DB for Apache Cassandra

  • Artigo

APLICA-SE AO: Cassandra

A API for Cassandra no Azure Cosmos DB é uma camada de compatibilidade que fornece suporte de protocolo de transmissão para o banco de dados Apache Cassandra de software livre.

Este artigo descreve os erros comuns e as soluções para os aplicativos que usam o Azure Cosmos DB for Apache Cassandra. Se o erro não estiver listado e você tiver um erro ao executar uma operação com suporte no Cassandra, mas o erro não estiver presente ao usar o Apache Cassandra nativo, crie uma solicitação de suporte do Azure.

Observação

Como um serviço nativo de nuvem totalmente gerenciado, o Azure Cosmos DB fornece garantias sobre disponibilidade, taxa de transferência e consistência para a API for Cassandra. A API for Cassandra também facilita as operações de plataforma sem manutenção e patches sem tempo de inatividade.

Essas garantias não são possíveis em implementações anteriores do Apache Cassandra, ou seja, muitas das operações de back-end da API for Cassandra diferem daquelas do Apache Cassandra. Recomendamos configurações e abordagens específicas para ajudar a evitar erros comuns.

NoNodeAvailableException

Esse erro é uma exceção de wrapper de nível superior com muitas possíveis causas e exceções internas, muitas das quais podem estar relacionadas ao cliente.

Causas comuns e soluções:

  • Tempo limite ocioso do Azure LoadBalancers: esse problema também pode ser manifestado como ClosedConnectionException. Para resolver o problema, defina a configuração keep alive no driver (confira Habilitar keep alive para o driver Java) e aumente as configurações de keep alive em seu sistema operacional ou ajuste o tempo limite ocioso no Azure Load Balancer.

  • Esgotamento de recursos do aplicativo cliente: verifique se os computadores cliente têm recursos suficientes para concluir a solicitação.

Não é possível se conectar a um host

Talvez você veja este erro: "Não é possível se conectar a nenhum host, agendando a nova tentativa em 600.000 milissegundos".

Esse erro pode ser causado pelo esgotamento de SNAT (conversão de endereços de rede de origem) no lado do cliente. Siga as etapas em SNAT para conexões de saída para eliminar esse problema.

O erro também pode ser um problema de tempo limite ocioso em que o Azure Load Balancer tem quatro minutos de tempo limite ocioso por padrão. Confira Tempo limite ocioso do balanceador de carga. Habilite keep alive para o driver Java e defina o intervalo keepAlive no sistema operacional para menos de quatro minutos.

Confira solucionar problemas de NoHostAvailableException para conhecer mais maneiras de lidar com a exceção.

OverloadedException (Java)

As solicitações são limitadas porque o número total de unidades de solicitação consumidas é maior do que o número de unidades de solicitação que você provisionou na tabela ou no keyspace.

Considere a possibilidade de escalar a taxa de transferência atribuída a um keyspace ou a uma tabela no portal do Azure (confira Escalar de maneira elástica uma conta do Azure Cosmos DB for Apache Cassandra) ou implementar uma política de repetição.

Para Java, confira amostras de novas tentativas para o Driver v3.x e o Driver v4.x. Confira também Extensões do Cassandra do Azure Cosmos DB para Java.

OverloadedException apesar da taxa de transferência suficiente

O sistema parece estar limitando as solicitações, embora taxa de transferência suficiente seja provisionada para o volume de solicitação ou o custo da unidade de solicitação consumida. Há duas causas possíveis:

  • Operações de nível de esquema: a API for Cassandra implementa um orçamento de taxa de transferência do sistema para operações de nível de esquema (CREATE TABLE, ALTER TABLE e DROP TABLE). Esse orçamento deve ser suficiente para operações de esquema em um sistema de produção. No entanto, se você tiver um número alto de operações no nível de esquema, poderá exceder esse limite.

    Como o orçamento não é controlado pelo usuário, considere reduzir o número de operações de esquema que você executa. Se essa ação não resolver o problema ou não for viável para sua carga de trabalho, crie uma solicitação de suporte do Azure.

  • Distorção de dados: quando a taxa de transferência é provisionada na API for Cassandra, ela é dividida igualmente entre as partições físicas, e cada partição física tem um limite superior. Se você tiver uma grande quantidade de dados sendo inseridos ou consultados de uma partição específica, poderá haver um limite de taxa mesmo que você provisione uma grande quantidade de taxa de transferência geral (unidades de solicitação) para essa tabela.

    Examine seu modelo de dados e verifique se você não tem uma distorção excessiva que pode causar partições quentes.

Erros de conectividade intermitente (Java)

A conexão cai ou expira inesperadamente.

Os drivers do Apache Cassandra para Java fornecem duas políticas de reconexão nativas: ExponentialReconnectionPolicy e ConstantReconnectionPolicy. O padrão é ExponentialReconnectionPolicy. No entanto, para o Azure Cosmos DB for Apache Cassandra, recomendamos ConstantReconnectionPolicy com um atraso de dois segundos.

Confira a documentação do driver Java 4.x, a documentação do driver Java 3.x ou exemplos de Como configurar ReconnectionPolicy para o driver Java.

Erro com a política de balanceamento de carga

Você pode ter implementado uma política de balanceamento de carga na v3.x do driver DataStax do Java, com um código semelhante a:

cluster = Cluster.builder()
        .addContactPoint(cassandraHost)
        .withPort(cassandraPort)
        .withCredentials(cassandraUsername, cassandraPassword)
        .withPoolingOptions(new PoolingOptions() .setConnectionsPerHost(HostDistance.LOCAL, 1, 2)
                .setMaxRequestsPerConnection(HostDistance.LOCAL, 32000).setMaxQueueSize(Integer.MAX_VALUE))
        .withSSL(sslOptions)
        .withLoadBalancingPolicy(DCAwareRoundRobinPolicy.builder().withLocalDc("West US").build())
        .withQueryOptions(new QueryOptions().setConsistencyLevel(ConsistencyLevel.LOCAL_QUORUM))
        .withSocketOptions(getSocketOptions())
        .build();

Se o valor para withLocalDc() não corresponder ao datacenter do ponto de contato, você poderá encontrar um erro intermitente: com.datastax.driver.core.exceptions.NoHostAvailableException: All host(s) tried for query failed (no host was tried).

Implemente a CosmosLoadBalancingPolicy. Para fazê-lo funcionar, talvez seja necessário atualizar o DataStax usando o seguinte código:

LoadBalancingPolicy loadBalancingPolicy = new CosmosLoadBalancingPolicy.Builder().withWriteDC("West US").withReadDC("West US").build();

A contagem falha em uma tabela grande

Quando você executa select count(*) from table ou semelhante para várias linhas, o servidor atinge o tempo limite.

Se você estiver usando um cliente CQLSH local, altere as configurações de --connect-timeout ou --request-timeout. Confira cqlsh: o shell CQL.

Se a contagem ainda estiver expirando, você poderá obter uma contagem de registros da telemetria de back-end do Azure Cosmos DB acessando a guia Métricas no portal do Azure, selecionando a métrica document count e adicionando um filtro ao banco de dados ou à coleção (a analogia da tabela no Azure Cosmos DB). Em seguida, você pode passar o mouse sobre o grafo resultante para o ponto no tempo em que você deseja uma contagem do número de registros.

exibição de métricas

Configurar a ReconnectionPolicy para o driver Java

Versão 3.x

Para a versão 3.x do driver Java, configure a política de reconexão ao criar um objeto de cluster:

import com.datastax.driver.core.policies.ConstantReconnectionPolicy;

Cluster.builder()
  .withReconnectionPolicy(new ConstantReconnectionPolicy(2000))
  .build();

Versão 4.x

Para a versão 4.x do driver do Java, configure a política de reconexão substituindo as configurações no arquivo reference.conf:

datastax-java-driver {
  advanced {
    reconnection-policy{
      # The driver provides two implementations out of the box: ExponentialReconnectionPolicy and
      # ConstantReconnectionPolicy. We recommend ConstantReconnectionPolicy for API for Cassandra, with 
      # base-delay of 2 seconds.
      class = ConstantReconnectionPolicy
      base-delay = 2 second
    }
}

Habilitar keep alive para o driver Java

Versão 3.x

Para a versão 3.x do driver do Java, defina keep alive ao criar um objeto de cluster e verifique se keep alive está habilitado no sistema operacional:

import java.net.SocketOptions;
    
SocketOptions options = new SocketOptions();
options.setKeepAlive(true);
cluster = Cluster.builder().addContactPoints(contactPoints).withPort(port)
  .withCredentials(cassandraUsername, cassandraPassword)
  .withSocketOptions(options)
  .build();

Versão 4.x

Para a versão 4.x do driver do Java, defina keep alive substituindo as configurações em reference.conf e verifique se keep alive está habilitado no sistema operacional:

datastax-java-driver {
  advanced {
    socket{
      keep-alive = true
    }
}

Próximas etapas