Бөлісу құралы:

Устранение распространенных проблем в Azure Cosmos DB для Apache Cassandra

  • Мақала

Область применения: Кассандра

API для Cassandra в Azure Cosmos DB — это уровень совместимости, обеспечивающий поддержку протокола проводного протокола для базы данных Apache Cassandra с открытым кодом.

В этой статье описываются распространенные ошибки и решения для приложений, использующих Azure Cosmos DB для Apache Cassandra. Если ваша ошибка не рассматривается здесь и возникает при выполнении поддерживаемой операции в Cassandra, но отсутствует при использовании встроенного Apache Cassandra, отправьте запрос в службу поддержки Azure.

Примечание.

Как полностью управляемая облачная служба Azure Cosmos DB обеспечивает гарантии доступности, пропускной способности и согласованности ДЛЯ API для Cassandra. API для Cassandra также упрощает операции платформы нулевого обслуживания и исправления без простоя.

Эти гарантии недоступны в предыдущих реализациях Apache Cassandra, поэтому многие из api для внутренних операций Cassandra отличаются от Apache Cassandra. Мы рекомендуем использовать определенные параметры и подходы для предотвращения возникновения распространенных ошибок.

NoNodeAvailableException

Эта ошибка является исключением оболочки верхнего уровня с большим количеством возможных причин и внутренних исключений, многие из которых могут быть связаны с клиентом.

Распространенные проблемы и их решения:

  • Тайм-аут простоя Azure LoadBalancers. Эта проблема также может проявляться как ClosedConnectionException. Чтобы устранить эту проблему, задайте параметр проверки активности в драйвере (см. раздел Включение проверки активности для драйвера Java) и увеличьте параметры проверки активности в операционной системе или настройте тайм-аут простоя в Azure Load Balancer.

  • Исчерпание ресурсов клиентского приложения. Убедитесь, что клиентские компьютеры имеют достаточно ресурсов для выполнения запроса.

Не удается подключиться к узлу

Может отобразиться такая ошибка: "Не удается подключиться ни к одному узлу, повторная попытка через 600000 мс".

Эта ошибка может быть вызвана исчерпанием преобразования адресов исходной сети (SNAT) на стороне клиента. Чтобы устранить эту ошибку, выполните действия, указанные в SNAT для исходящих подключений.

Эта ошибка также может быть связана с проблемой тайм-аута простоя, когда в подсистеме балансировки нагрузки Azure по умолчанию установлено четыре минуты для тайм-аута простоя. См. раздел Тайм-аут простоя подсистемы балансировки нагрузки. Включите проверку активности для драйвера Java и задайте значение менее четырех минут в качестве интервала keepAlive в операционной системе.

Дополнительные способы обработки исключения см. в статье об устранении неполадок с NoHostAvailableException.

OverloadedException (Java)

Запросы ограничиваются, потому что общее количество используемых единиц запроса превышает количество единиц запросов, предусмотренное для пространства ключей или таблицы.

Рассмотрите возможность масштабирования пропускной способности, назначенной пространству ключей или таблице из портал Azure (см. инструкции по эластичному масштабированию учетной записи Azure Cosmos DB для учетной записи Apache Cassandra) или реализации политики повторных попыток.

Для Java см. примеры повторных попыток для драйвера v3.x и драйвера v4.x. См. также расширения Cassandra для Azure Cosmos DB для Java.

Возникновение ошибки OverloadedException, несмотря на достаточную пропускную способность

Похоже, что система ограничивает запросы, даже несмотря на предоставление достаточной пропускной способности для объема запросов или затрат на используемые единицы запроса. Существуют две возможные причины.

  • Операции уровня схемы: API для Cassandra реализует бюджет пропускной способности системы для операций уровня схемы (CREATE TABLE, ALTER TABLE, DROP TABLE). Этого бюджета должно быть достаточно для операций со схемами в рабочей системе. Однако при наличии большого количества операций на уровне схемы это предельное значение может быть превышено.

    Так как бюджет не контролируется пользователем, можно уменьшить число выполняемых операций со схемой. Если это действие не устраняет проблему или не является целесообразным для вашей рабочей нагрузки, отправьте запрос в службу поддержки Azure.

  • Отклонение данных. Если пропускная способность подготовлена в API для Cassandra, она распределяется одинаково между физическими секциями, а каждая физическая секция имеет верхний предел. При большом объеме данных, передаваемых в конкретный раздел или запрашиваемых из него, к ним могут применяться ограничения скорости, даже если вы предусмотрели большую общую пропускную способность (единицы запроса) для этой таблицы.

    Проверьте модель данных и убедитесь в отсутствии чрезмерных отклонений, которые могут привести к возникновению разделов с высокой нагрузкой.

Периодические ошибки подключения (Java)

Подключение неожиданно прерывается или истекает время ожидания.

Драйверы Apache Cassandra для Java предоставляют две встроенные политики повторного подключения: ExponentialReconnectionPolicy и ConstantReconnectionPolicy. Значение по умолчанию — ExponentialReconnectionPolicy. Однако для Azure Cosmos DB для Apache Cassandra рекомендуется ConstantReconnectionPolicy использовать две секунды задержки.

См. документацию по драйверу Java 4.x, документацию по драйверу Java 3.x или примеры в разделе Настройка ReconnectionPolicy для драйверов Java.

Ошибка в политике балансировки нагрузки

Возможно, вы реализовали политику балансировки нагрузки в версии v3.x драйвера DataStax для Java с кодом, аналогичным приведенному ниже.

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

Если значение для withLocalDc() не соответствует центру обработки данных точки контакта, периодически может возникать следующая ошибка: com.datastax.driver.core.exceptions.NoHostAvailableException: All host(s) tried for query failed (no host was tried).

Реализуйте CosmosLoadBalancingPolicy. Для этого может потребоваться обновить DataStax с помощью следующего кода:

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

Сбой счетчика в большой таблице

При выполнении функции select count(*) from table или аналогичной с большим количеством строк, время ожидания сервера истекает.

Если вы используете локальный клиент CQLSH, измените параметры --connect-timeout или --request-timeout. См. статью cqlsh: оболочка CQL.

Если время ожидания счетчика все еще истекает, можно получить число записей из данных телеметрии сервера Azure Cosmos DB, перейдя на вкладку метрики на портале Azure, выбрав метрику document count, а затем добавив фильтр для базы данных или коллекции (аналог таблицы в Azure Cosmos DB). Затем в полученном графе можно навести указатель мыши на момент времени, за который нужно получить количество записей.

Представление метрик

Настройка ReconnectionPolicy для драйвера Java

Версия 3.x

Для версии 3.x драйвера Java настройте политику повторного подключения при создании объекта кластера:

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

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

Версия 4.x

Для версии 4.x драйвера Java настройте политику повторного подключения, переопределив параметры в файле 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
    }
}

Включение проверки активности для драйвера Java

Версия 3.x

Для версии 3.x драйвера Java установите проверку активности при создании объекта кластера, а затем убедитесь, что проверка активности включена в операционной системе:

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

Для версии 4.x драйвера Java установите проверку активности, переопределив параметры в файле reference.conf, а затем убедитесь, что проверка активности включена в операционной системе:

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

Следующие шаги