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

DOTYCZY: Cassandra

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ąpi błąd podczas wykonywania obsługiwanej operacji w systemie 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 bazy danych Cassandra. Interfejs API dla bazy danych Cassandra ułatwia również operacje platformy bezobsługowej i stosowanie poprawek bez przestojów.

Te gwarancje nie są możliwe w poprzednich implementacjach bazy danych Apache Cassandra, dlatego 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ć związanych z klientem.

Typowe przyczyny i rozwiązania:

• Limit czasu bezczynności modułów Azure LoadBalancers: ten problem może również występować jako ClosedConnectionException. Aby rozwiązać ten problem, ustaw ustawienie zachowania aktywności w sterowniku (zobacz Włączanie zachowania aktywności dla sterownika Java) i zwiększ ustawienia zachowania aktywności w systemie operacyjnym lub dostosuj limit czasu bezczynności w Azure Load Balancer.

• Wyczerpanie zasobów aplikacji klienckiej: upewnij się, że maszyny klienckie mają wystarczające zasoby do ukończenia żądania.

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

Może zostać wyświetlony następujący błąd: "Nie można nawiązać połączenia z żadnym hostem, planowanie 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.

Ten 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ł w systemie operacyjnym na mniej niż cztery minuty.

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

Przeciążony wyjątekException (Java)

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

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

Aby zapoznać się z językiem 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

Wygląda na to, że system ogranicza żądania, mimo że jest aprowizowana wystarczająca przepływność dla woluminu żądań lub zużytego kosztu jednostkowego żądania. Istnieją dwie możliwe przyczyny:

• Operacje na poziomie schematu: interfejs API dla bazy danych Cassandra implementuje budżet przepływności systemu dla operacji na poziomie schematu (CREATE TABLE, ALTER TABLE, DROP TABLE). Ten budżet powinien wystarczyć na operacje 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 w przypadku 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 odpytywanych z jednej konkretnej partycji, może być ograniczona szybkość, 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 nadmiernej niesymetryczności, która może powodować gorące partycje.

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

Nieoczekiwane przerywanie połączenia lub limit czasu.

Sterowniki apache Cassandra dla języka Java zapewniają dwie natywne zasady ponownego nawiązywania połączenia: ExponentialReconnectionPolicy i ConstantReconnectionPolicy. Wartość domyślna to ExponentialReconnectionPolicy. Jednak w przypadku usługi Azure Cosmos DB dla bazy danych Apache Cassandra zalecamy ConstantReconnectionPolicy opóźnienie dwusekundowe.

Zapoznaj się z dokumentacją sterownika Java 4.x, dokumentacją sterownika Java 3.x lub konfigurowaniem funkcji ReconnectionPolicy dla przykładów sterowników Języka 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 kontaktowego, może wystąpić sporadyczne wystąpienie błędu: com.datastax.driver.core.exceptions.NoHostAvailableException: All host(s) tried for query failed (no host was tried).

Zaimplementuj zasady CosmosLoadBalancingPolicy. Aby to zadziałało, może być konieczne uaktualnienie elementu 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

Po uruchomieniu select count(*) from table lub podobnym dla dużej liczby wierszy serwer upłynął limit czasu.

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 pobrać liczbę rekordów z telemetrii zaplecza usługi Azure Cosmos DB, przechodząc do karty metryki w 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.

Konfigurowanie funkcji ReconnectionPolicy dla sterownika Java

Wersja 3.x

W przypadku wersji 3.x sterownika Java skonfiguruj zasady ponownego nawiązywania połą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 nawiązywania połą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 obsługę utrzymania aktywności:

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 ustawienie keep-alive przez zastąpienie ustawień w reference.confsystemie , a następnie upewnij się, że w systemie operacyjnym włączono obsługę utrzymania aktywności:

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

Następne kroki

• Dowiedz się więcej o obsługiwanych funkcjach w usłudze Azure Cosmos DB dla bazy danych Apache Cassandra.
• Dowiedz się, jak przeprowadzić migrację z natywnego systemu Apache Cassandra do usługi Azure Cosmos DB dla bazy danych Apache Cassandra.