Udostępnij za pośrednictwem

Rozwiązywanie typowych problemów w usłudze Azure Cosmos DB dla bazy danych Apache Cassandra

  • Artykuł

DOTYCZY: Kasandra

Interfejs API dla bazy danych Cassandra w usłudze Azure Cosmos DB to warstwa zgodności, która zapewnia obsługę protokołu przewodowego dla bazy danych Apache Cassandra typu open source.

W tym artykule opisano typowe błędy i rozwiązania dla aplikacji korzystających z usługi Azure Cosmos DB dla bazy danych Apache Cassandra. Jeśli błąd nie znajduje się na liście i występuje błąd podczas wykonywania obsługiwanej operacji w usłudze Cassandra, ale błąd nie występuje podczas korzystania z natywnej bazy danych Apache Cassandra, utwórz żądanie pomoc techniczna platformy Azure.

Uwaga

Jako w pełni zarządzana usługa natywna dla chmury usługa Azure Cosmos DB zapewnia gwarancje dotyczące dostępności, przepływności i spójności interfejsu API dla rozwiązania Cassandra. Interfejs API dla rozwiązania Cassandra ułatwia również operacje platformy bezobsługowej i stosowanie poprawek bez przestojów.

Te gwarancje nie są możliwe w poprzednich implementacjach systemu Apache Cassandra, więc wiele interfejsów API dla operacji zaplecza Cassandra różni się od bazy danych Apache Cassandra. Zalecamy określone ustawienia i podejścia, aby uniknąć typowych błędów.

NoNodeAvailableException

Ten błąd jest wyjątkiem otoki najwyższego poziomu z dużą liczbą możliwych przyczyn i wyjątków wewnętrznych, z których wiele może być powiązanych z klientem.

Typowe przyczyny i rozwiązania:

Nie można nawiązać połączenia z hostem

Ten błąd może wystąpić: "Nie można nawiązać połączenia z żadnym hostem, zaplanowanie ponawiania prób w milisekundach 600000".

Ten błąd może być spowodowany wyczerpaniem źródłowego tłumaczenia adresów sieciowych (SNAT) po stronie klienta. Wykonaj kroki opisane w temacie SNAT dla połączeń wychodzących, aby wykluczyć ten problem.

Błąd może być również problemem z limitem czasu bezczynności, w którym moduł równoważenia obciążenia platformy Azure domyślnie ma cztery minuty bezczynności. Zobacz Limit czasu bezczynności modułu równoważenia obciążenia. Włącz zachowanie aktywności dla sterownika Java i ustaw keepAlive interwał systemu operacyjnego na mniej niż cztery minuty.

Aby uzyskać więcej sposobów obsługi wyjątku, zobacz Troubleshoot NoHostAvailableException (Rozwiązywanie problemów z wyjątekami NoHostAvailableException ).

Przeciążony wyjątekException (Java)

Żądania są ograniczane, ponieważ łączna liczba wykorzystanych jednostek żądania jest większa niż liczba jednostek żądania aprowizowanej w przestrzeni kluczy lub tabeli.

Rozważ skalowanie przepływności przypisanej do przestrzeni kluczy lub tabeli z witryny Azure Portal (zobacz Elastyczne skalowanie konta usługi Azure Cosmos DB dla bazy danych Apache Cassandra) lub implementowanie zasad ponawiania prób.

W przypadku języka Java zobacz przykłady ponawiania prób dla sterownika v3.x i sterownika v4.x. Zobacz również rozszerzenia Cassandra usługi Azure Cosmos DB dla języka Java.

Przeciążony wyjątekException pomimo wystarczającej przepływności

System wydaje się ograniczać żądania, mimo że wystarczająca przepływność jest aprowizowana dla woluminu żądań lub zużywanego kosztu jednostkowego żądania. Istnieją dwie możliwe przyczyny:

  • Operacje na poziomie schematu: interfejs API dla rozwiązania Cassandra implementuje budżet przepływności systemu dla operacji na poziomie schematu (CREATE TABLE, ALTER TABLE, DROP TABLE). Ten budżet powinien być wystarczający dla operacji schematu w systemie produkcyjnym. Jeśli jednak masz dużą liczbę operacji na poziomie schematu, możesz przekroczyć ten limit.

    Ponieważ budżet nie jest kontrolowany przez użytkownika, rozważ zmniejszenie liczby uruchomionych operacji schematu. Jeśli ta akcja nie rozwiąże problemu lub nie jest to możliwe dla obciążenia, utwórz żądanie pomoc techniczna platformy Azure.

  • Niesymetryczność danych: gdy przepływność jest aprowizowana w interfejsie API dla bazy danych Cassandra, jest ona podzielona równomiernie między partycje fizyczne, a każda partycja fizyczna ma górny limit. Jeśli masz dużą ilość danych wstawionych lub odpytujących z jednej konkretnej partycji, może to być ograniczone szybkością, nawet jeśli aprowizujesz dużą ilość ogólnej przepływności (jednostek żądań) dla tej tabeli.

    Przejrzyj model danych i upewnij się, że nie masz nadmiernego niesymetryczności, które mogą powodować gorące partycje.

Sporadyczne błędy łączności (Java)

Połączenie spada lub nieoczekiwanie kończy się limitem czasu.

Sterowniki apache Cassandra dla języka Java zapewniają dwie natywne zasady ponownego łączenia: ExponentialReconnectionPolicy i ConstantReconnectionPolicy. Wartość domyślna to ExponentialReconnectionPolicy. Jednak w przypadku usługi Azure Cosmos DB dla bazy danych Apache Cassandra zalecamy ConstantReconnectionPolicy użycie dwóch sekund opóźnienia.

Zapoznaj się z dokumentacją sterownika Java 4.x, dokumentacją sterownika Java 3.x lub Konfigurowanie funkcji ReconnectionPolicy dla przykładów sterownika Java.

Błąd z zasadami równoważenia obciążenia

Być może zaimplementowano zasady równoważenia obciążenia w wersji 3.x sterownika Java DataStax z kodem podobnym do:

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();

Jeśli wartość parametru withLocalDc() nie jest zgodna z centrum danych punktu kontaktu, może wystąpić sporadycznie błąd: com.datastax.driver.core.exceptions.NoHostAvailableException: All host(s) tried for query failed (no host was tried).

Zaimplementuj element CosmosLoadBalancingPolicy. Aby to działało, może być konieczne uaktualnienie środowiska DataStax przy użyciu następującego kodu:

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

Liczba kończy się niepowodzeniem w dużej tabeli

W przypadku uruchamiania select count(*) from table lub podobnego dla dużej liczby wierszy limit czasu serwera.

Jeśli używasz lokalnego klienta CQLSH, zmień --connect-timeout ustawienia lub --request-timeout . Zobacz cqlsh: powłoka CQL.

Jeśli liczba nadal przekracza limit czasu, możesz uzyskać liczbę rekordów z telemetrii zaplecza usługi Azure Cosmos DB, przechodząc do karty metryki w witrynie Azure Portal, wybierając metrykę document count, a następnie dodając filtr dla bazy danych lub kolekcji (analog tabeli w usłudze Azure Cosmos DB). Następnie możesz umieścić wskaźnik myszy na wykresie wynikowym dla punktu w czasie, w którym ma zostać wyświetlona liczba rekordów.

widok metryk

Konfigurowanie funkcji ReconnectionPolicy dla sterownika Java

Wersja 3.x

W przypadku wersji 3.x sterownika Java skonfiguruj zasady ponownego łączenia podczas tworzenia obiektu klastra:

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

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

Wersja 4.x

W przypadku wersji 4.x sterownika Java skonfiguruj zasady ponownego łączenia, przesłaniając ustawienia w reference.conf pliku:

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

Włączanie zachowania aktywności dla sterownika Java

Wersja 3.x

W przypadku wersji 3.x sterownika Java ustaw wartość keep-alive podczas tworzenia obiektu klastra, a następnie upewnij się, że w systemie operacyjnym włączono funkcję keep-alive:

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

Wersja 4.x

W przypadku wersji 4.x sterownika Java ustaw wartość keep-alive przez zastąpienie ustawień w reference.confsystemie , a następnie upewnij się, że w systemie operacyjnym włączono obsługę zachowania aktywności:

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

Następne kroki