Partilhar via

Solucionar problemas comuns no Azure Cosmos DB para Apache Cassandra

  • Artigo

APLICA-SE A: Cassandra

A API para Cassandra no Azure Cosmos DB é uma camada de compatibilidade que fornece suporte de protocolo de conexão para o banco de dados Apache Cassandra de código aberto.

Este artigo descreve erros comuns e soluções para aplicativos que usam o Azure Cosmos DB para 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.

Nota

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

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

NoNodeAvailableException

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

Causas e soluções comuns:

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

  • Exaustão de recursos do aplicativo cliente: certifique-se de que as máquinas cliente tenham recursos suficientes para concluir a solicitação.

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

Poderá ver este erro: "Não é possível ligar a qualquer anfitrião, agendando nova tentativa em 600000 milissegundos."

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

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

Consulte solucionar problemas NoHostAvailableException para obter 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 no espaço de chave ou na tabela.

Considere dimensionar a taxa de transferência atribuída a um espaço de chave ou tabela a partir do portal do Azure (consulte Dimensionar elasticamente uma conta do Azure Cosmos DB para Apache Cassandra) ou implementar uma política de repetição.

Para Java, consulte Exemplos de repetição para o driver v3.x e o driver v4.x. Consulte também Azure Cosmos DB Cassandra Extensions for Java.

OverloadedException apesar da taxa de transferência suficiente

O sistema parece estar limitando as solicitações, mesmo que uma taxa de transferência suficiente seja provisionada para o volume de solicitações ou o custo unitário de solicitação consumido. Existem duas causas possíveis:

  • Operações no nível do esquema: A API para Cassandra implementa um orçamento de taxa de transferência do sistema para operações no nível do esquema (CREATE TABLE, ALTER TABLE, 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 grande número de operações no nível do 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.

  • Inclinação de dados: quando a taxa de transferência é provisionada na API para Cassandra, ela é dividida igualmente entre 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, ela poderá ser limitada mesmo se você provisionar uma grande quantidade de taxa de transferência geral (unidades de solicitação) para essa tabela.

    Reveja o seu modelo de dados e certifique-se de que não tem distorções excessivas que possam causar partições quentes.

Erros de conectividade intermitentes (Java)

A conexão cai ou expira inesperadamente.

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

Consulte a documentação para o driver Java 4.x, a documentação para o driver Java 3.x ou Configuring ReconnectionPolicy para os exemplos de 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 Java DataStax, com 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 for withLocalDc() não corresponder ao datacenter do ponto de contato, você poderá enfrentar um erro intermitente: com.datastax.driver.core.exceptions.NoHostAvailableException: All host(s) tried for query failed (no host was tried).

Implemente o 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 grande mesa

Quando você executa select count(*) from table ou similar para um grande número de linhas, o servidor expira.

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

Se a contagem ainda atingir o tempo limite, 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 counte adicionando um filtro para o banco de dados ou coleção (o analógico da tabela no Azure Cosmos DB). Em seguida, você pode passar o mouse sobre o gráfico resultante para o ponto no tempo em que deseja uma contagem do número de registros.

Visualização de métricas

Configurar 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 Java, configure a política de reconexão substituindo as reference.conf configurações no arquivo:

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
    }
}

Ativar keep-alive para o driver Java

Versão 3.x

Para a versão 3.x do driver Java, defina keep-alive ao criar um objeto de cluster e verifique se keep-alive está ativado 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 Java, defina keep-alive substituindo as configurações em reference.conf, e verifique se keep-alive está ativado no sistema operacional:

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

Próximos passos