Известные проблемы ADB Control

Дарья Барышева
Проблема С версии Fixed Обходное решение

В AltLinux 8 обновление Docker engine может повредить пакет docker-compose, что приводит к ошибкам в запуске сервиса ADB Control

 — 

На стороне AltLinux

Исправьте /usr/lib/python3/site-packages/compose/service.py путем замены:

container.image_config['ContainerConfig'].get('Volumes') or {}

на:

container.image_config['Config'].get('Volumes') or {}

При настройке LDAP-аутентификации для ADB Control с типом FreeIPA список групп не загружается при создании нового сопоставления с группами LDAP-сервера на вкладке Users → LDAP group mapping

4.0.0

 — 

Используйте базовую аутентификацию или LDAP с типом MSAD (Microsoft Active Directory)

При обновлении кластера с версии 6.27.1.56 до 6.27.1.58 возникает ошибка при использовании внешнего ADB Control

4.10.3

4.10.3

Обновите кластер с сервисом ADB Control до обновления кластеров, которые используют этот ADB Control в качестве внешнего (в поле External ADB Control server parameters)

После отмены транзакции узлы плана в секции Plan & progress будут по-прежнему иметь статус executing и отображать увеличивающееся время выполнения

4.8.8

4.9.1

Необходимо иметь в виду, что у отмененных запросов нет выполняющихся процессов

В ADB Control 4.8.8 реализованы изменения в API, затрагивающие взаимодействие между основным и внешним сервисами ADB Control разных версий.

Когда кластер ADB с основным ADB Control обновляется до версии 6.27.1.56.b1, в кластерах более ранних версий, использующих этот ADB Control как внешний, будет невозможно выполнять действия Reconfigure/Start с сервисом ADB Control

4.8.8

4.8.8

Чтобы обеспечить работоспособность всех действий сервиса ADB Control, обновите кластеры с внешним ADB Control и версией 6.27.1.56.b1 и ниже до версии 6.27.1.56.b1

При обновлении ADB Control до версии 4.3.2 настройки задачи Export job (заполненные на странице Configuration → Job policy → Metrics offload) возвращаются к значениям по умолчанию

4.3.2

4.3.2

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

Активация Standby после переключения с master завершается с ошибкой в кластерах с установленным ADB Control/ADBM

4.3.1

4.3.2

Используйте внешний ADB Control/ADBM

В ADB Control 4.2.1 невозможно зарегистрировать внешние кластеры ADB с версиями ниже 6.23.3

4.2.1

4.2.1

Обновите кластер ADB до версии 6.23.3

Отключение отправки метрик вложенных запросов в ADB Control может вызвать "зависание" ADB-запросов

4.1.0

4.10.3

Включите GUC, отвечающий за отправку метрик вложенных запросов, в ADB Control или в ADB (как показано ниже):

$ gpconfig -c adcc.monitor_inner_queries -v on
$ gpstop -u

Команды появляются в статусе Running на странице Monitoring → Commands → Online, но спустя 14-16 секунд переходят в статус Unknown (без обновления метрик). После завершения команды все метрики становятся доступны на странице Monitoring → Commands → History, но статус Unknown сохраняется

4.1.0

4.2.0

  1. Используя psql или иной SQL IDE, установите пароль для пользователя adcc с помощью следующей команды:

    ALTER USER adcc WITH ENCRYPTED PASSWORD '<password>';

  2. Откройте страницу Configuration → Clusters в UI ADCC и перейдите к редактированию соединения с кластером.

  3. Установите пароль <password>, выбранный на шаге 1, в поле Password и нажмите Save.

Существует потенциальный риск утечки памяти для специфических запросов, затрагиваемых gpperfmon. При выполнении запросов к большим таблицам с использованием функций UDF, генерирующих межкортежные запросы, можно столкнуться с повышенным потреблением RAM и даже ошибками OOM. Например, представление information_schema.columns может вызвать значительную утечку памяти при обращении к большому системному каталогу

4.0.0

4.1.0

Возможное решение заключается в отключении метрик мониторинга (операция требует перезапуска кластера):

  1. Удалите gpadcc из shared_preload_libraries, например:

    $ gpconfig -c shared_preload_libraries -v ""

  2. Отключите следующие параметры:

    $ gpconfig -c gp_enable_gpperfmon -v off
$ gpconfig -c adcc.explain_log_verbose -v off
$ gpconfig -c adcc.explain_log_analyze -v off

  3. Перезапустите кластер:

    $ gpstop -a -M fast
$ gpstart a

Имейте в виду, что это обходное решение не отключает ADCC UI и Arenadata DB Backup Manager

Сервер Backend ADCC не может подключиться к серверу ADCC UI. Периодически может не работать обновление данных на странице с детальной информацией

4.0.0

4.1.0

  1. Подключитесь к серверу ADCC через SSH.

  2. Перейдите в директорию /opt/adcc.

  3. Отредактируйте файл docker-compose.yaml. Для сервисов adcc_ui_server и adcc_backend_server измените значение переменной окружения ADCC_EUREKA_CLIENT_PREFER_IP_ADDRESS на true.

  4. Выполните следующую команду и дождитесь остановки всех Docker-контейнеров:

    $ docker-compose down

  5. Выполните команду:

    $ docker-compose up -d

Невозможно настроить задачу Data cleanup на странице Configuration. ADCC способен работать без очистки данных, однако необходимо следить за размером базы данных с метриками

4.0.0

4.1.0

  1. Подключитесь к серверу ADCC через SSH.

  2. Перейдите в директорию /opt/adcc.

  3. Отредактируйте файл docker-compose.yaml: для сервиса adcc_scheduler добавьте дополнительную переменную окружения ADCC_SCHEDULER_GRPC_PORT: 6572.

  4. Выполните следующую команду и дождитесь остановки всех Docker-контейнеров:

    $ docker-compose down

  5. Выполните команду:

    $ docker-compose up -d
Нашли ошибку? Выделите текст и нажмите Ctrl+Enter чтобы сообщить о ней