Megosztás a következőn keresztül:

Az Apache Cassandra-hoz készült Azure Cosmos DB gyakori hibáinak elhárítása

  • Cikk

A KÖVETKEZŐKRE VONATKOZIK: Cassandra

Az Azure Cosmos DB Cassandra API-ja egy kompatibilitási réteg, amely a nyílt forráskódú Apache Cassandra-adatbázis vezetékes protokolljának támogatását biztosítja.

Ez a cikk az Apache Cassandra Azure Cosmos DB-t használó alkalmazások gyakori hibáit és megoldásait ismerteti. Ha a hiba nem szerepel a listában, és egy támogatott művelet Cassandra-ban való végrehajtásakor hibát tapasztal, de a hiba nem jelenik meg a natív Apache Cassandra használatakor, hozzon létre egy Azure-támogatás kérést.

Feljegyzés

Az Azure Cosmos DB teljes mértékben felügyelt natív felhőszolgáltatásként garantálja a Cassandra API rendelkezésre állását, átviteli sebességét és konzisztenciáját . A Cassandra API a karbantartás nélküli platformműveleteket és a nulla állásidő-javítást is lehetővé teszi.

Ezek a garanciák az Apache Cassandra korábbi implementációiban nem lehetségesek, ezért a Cassandra háttérműveletek API-jának nagy része különbözik az Apache Cassandra-tól. A gyakori hibák elkerülése érdekében bizonyos beállításokat és megközelítéseket ajánlunk.

NoNodeAvailableException

Ez a hiba egy legfelső szintű burkoló kivétel, amely számos lehetséges okot és belső kivételt tartalmazhat, amelyek közül sok ügyfélhez köthető.

Gyakori okok és megoldások:

  • Az Azure LoadBalancers tétlen időtúllépése: Ez a probléma a ClosedConnectionException. A probléma megoldásához állítsa be az illesztőprogram életben tartásának beállítását (lásd: A Java-illesztőprogram életben tartásának engedélyezése), és növelje az operációs rendszerben az életben tartási beállításokat, vagy állítsa be az üresjárati időtúllépést az Azure Load Balancerben.

  • Ügyfélalkalmazás erőforrás-kimerülése: Győződjön meg arról, hogy az ügyfélgépek elegendő erőforrással rendelkeznek a kérés teljesítéséhez.

Nem lehet csatlakozni egy gazdagéphez

A következő hibaüzenet jelenhet meg: "Nem lehet csatlakozni egy gazdagéphez, az újrapróbálkozások ütemezése 600000 ezredmásodpercben".

Ezt a hibát a forráshálózati címfordítás (SNAT) ügyféloldali kimerülése okozhatja. A probléma kizárásához kövesse az SNAT kimenő kapcsolatokra vonatkozó lépéseit.

A hiba egy tétlen időtúllépési probléma is lehet, amely miatt az Azure-terheléselosztó alapértelmezés szerint négy perc tétlenségi időtúllépéssel rendelkezik. Lásd: Terheléselosztó tétlen időtúllépése. Engedélyezze a Java-illesztőprogram életben tartását, és állítsa keepAlive az operációs rendszer időközét négy percnél rövidebbre.

A kivétel kezelésének további módjaiért tekintse meg a NoHostAvailableException hibaelhárítását.

OverloadedException (Java)

A kérelmek szabályozása azért történik, mert a felhasznált kérelemegységek teljes száma nagyobb, mint a kulcstérben vagy táblában kiépített kérelemegységek száma.

Fontolja meg egy kulcstérhez vagy táblához rendelt átviteli sebesség skálázását az Azure Portalról (lásd : Azure Cosmos DB rugalmas méretezése Apache Cassandra-fiókhoz) vagy újrapróbálkozási szabályzat implementálása.

Java esetén lásd a v3.x illesztőprogram és a v4.x illesztőprogram újrapróbálkozása során használt mintákat. Lásd még a Java-hoz készült Azure Cosmos DB Cassandra-bővítményeket.

OverloadedException a megfelelő átviteli sebesség ellenére

Úgy tűnik, hogy a rendszer szabályozza a kérelmeket, annak ellenére, hogy elegendő átviteli sebesség van kiépítve a kérelemmennyiséghez vagy a felhasznált kérelemegység-költséghez. Két lehetséges oka lehet:

  • Sémaszintű műveletek: A Cassandra API a sémaszintű műveletek (CREATE TABLE, ALTER TABLE, DROP TABLE) rendszerteljesítmény-költségvetését implementálja. Ennek a költségvetésnek elegendőnek kell lennie a sémaműveletekhez egy éles rendszerben. Ha azonban sok sémaszintű művelettel rendelkezik, túllépheti ezt a korlátot.

    Mivel a költségvetés nem felhasználó által vezérelhető, érdemes lehet csökkenteni a futtatott sémaműveletek számát. Ha ez a művelet nem oldja meg a problémát, vagy a számítási feladat nem megvalósítható, hozzon létre egy Azure-támogatás kérelmet.

  • Adateltérés: Ha az átviteli sebesség ki van építve a Cassandra API-ban, az egyenlően oszlik meg a fizikai partíciók között, és minden fizikai partíció felső korlátot tartalmaz. Ha nagy mennyiségű adat van beszúrva vagy lekérdezve egy adott partícióról, az akkor is korlátozott lehet, ha nagy mennyiségű teljes átviteli sebességet (kérelemegységet) helyez üzembe az adott táblához.

    Tekintse át az adatmodellt, és győződjön meg arról, hogy nincs túlzott eltérés, amely gyakori partíciókat okozhat.

Időszakos csatlakozási hibák (Java)

A kapcsolat váratlanul megszakad vagy túllépi az időkorlátot.

A Java-hoz készült Apache Cassandra-illesztőprogramok két natív újracsatlakozási házirendet biztosítanak: ExponentialReconnectionPolicy és ConstantReconnectionPolicy. Az alapértelmezett érték ExponentialReconnectionPolicy. Az Apache Cassandra-hoz készült Azure Cosmos DB esetében azonban két másodperces késést javasoljuk ConstantReconnectionPolicy .

Tekintse meg a Java 4.x illesztőprogram dokumentációját, a Java 3.x-illesztőprogram dokumentációját, vagy a Java-illesztőprogramok példáihoz a ReconnectionPolicy konfigurálását.

Terheléselosztási szabályzattal kapcsolatos hiba

Előfordulhat, hogy a Java DataStax-illesztőprogram 3.x verziójában implementált egy terheléselosztási szabályzatot a következőhöz hasonló kóddal:

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

Ha az érték nem egyezik a kapcsolattartási pont adatközpontjának értékével withLocalDc() , előfordulhat, hogy időszakos hibát tapasztal: com.datastax.driver.core.exceptions.NoHostAvailableException: All host(s) tried for query failed (no host was tried).

Implementálja a CosmosLoadBalancingPolicyt. A működéshez szükség lehet a DataStax frissítésére az alábbi kód használatával:

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

A darabszám nagy táblán meghiúsul

Nagy számú sor futtatásakor select count(*) from table vagy hasonló futtatásakor a kiszolgáló túllépi az időkorlátot.

Ha helyi CQLSH-ügyfelet használ, módosítsa a --connect-timeout beállításokat.--request-timeout Lásd : cqlsh: a CQL-rendszerhéj.

Ha a darabszám továbbra is túllépi az időkorlátot, az Azure Cosmos DB háttértelemetria rekordjainak számát lekérheti az Azure Portal Metrikák lapjára lépve kiválasztva a metrikát document count, majd hozzáadhat egy szűrőt az adatbázishoz vagy gyűjteményhez (az Azure Cosmos DB-ben lévő táblázat analógja). Ezután rámutathat az eredményként kapott gráfra arra az időpontra, amikor a rekordok számának számát szeretné megjeleníteni.

metrikák nézet

A ReconnectionPolicy konfigurálása a Java-illesztőprogramhoz

3.x-es verzió

A Java-illesztőprogram 3.x verziójához konfigurálja az újracsatlakozási szabályzatot fürtobjektum létrehozásakor:

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

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

4.x-es verzió

A Java-illesztőprogram 4.x verziójához konfigurálja az újracsatlakozási szabályzatot a reference.conf fájl beállításainak felülírásával:

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

A Java-illesztőprogram életben tartásának engedélyezése

3.x-es verzió

A Java-illesztőprogram 3.x-es verziójához állítsa be az életben tartást fürtobjektum létrehozásakor, majd győződjön meg arról, hogy az életben tartás engedélyezve van az operációs rendszerben:

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

4.x-es verzió

A Java-illesztőprogram 4.x verziójához állítsa be az életben tartást a beállítások reference.conffelülírásával, majd győződjön meg arról, hogy az életben tartás engedélyezve van az operációs rendszerben:

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

Következő lépések