Перейти к содержимому
Последнее обновление

Частые вопросы по эксплуатации

В этом документе собраны распространённые проблемы, возникающие при эксплуатации Doris. Документ будет периодически обновляться.

Исполняемый файл BE doris_be, упоминаемый в этом документе, в предыдущих версиях назывался palo_be.

Q1. Почему при выводе узла BE из эксплуатации с помощью DECOMMISSION всегда остаются некоторые таблеты?​

Во время вывода узла из эксплуатации можно просматривать его tabletNum с помощью show backends. Значение tabletNum будет уменьшаться: это означает, что шарды данных переносятся с этого узла. Когда значение достигнет 0, система автоматически удалит узел. Однако в некоторых случаях tabletNum уменьшается до определённого значения и перестаёт меняться. Обычно это происходит по одной из следующих двух причин:

  1. Эти таблеты принадлежат таблицам, разделам или материализованным представлениям, которые были недавно удалены. Недавно удалённые объекты сохраняются в корзине. Логика вывода из эксплуатации не обрабатывает такие шарды. Чтобы изменить срок хранения объектов в корзине, можно изменить параметр конфигурации FE catalog_trash_expire_second. После удаления объектов из корзины эти таблеты будут обработаны.

  2. При выполнении задач переноса этих таблетов возникли проблемы. В этом случае нужно использовать show proc "/cluster_balance", чтобы просмотреть конкретные ошибки задач.

В описанных ситуациях сначала можно выполнить show proc "/cluster_health/tablet_health";, чтобы проверить, есть ли в кластере неисправные шарды. Если их количество равно 0, этот BE можно сразу удалить с помощью оператора drop backend. В противном случае необходимо отдельно проверить состояние реплик неисправных шардов.

Q2. Как настроить priority_networks?​

priority_networks — параметр конфигурации FE и BE. Он прежде всего помогает системе выбрать правильный IP-адрес сетевого интерфейса в качестве собственного IP-адреса. Рекомендуется всегда задавать этот параметр явно, чтобы избежать ошибочного выбора IP-адреса при последующем добавлении сетевых интерфейсов на серверы.

Значение priority_networks задаётся в формате CIDR. Оно состоит из двух частей: IP-адреса в десятичной записи с точками и длины префикса. Например, 10.168.1.0/8 соответствует всем IP-адресам вида 10.xx.xx.xx, а 10.168.1.0/16 — всем IP-адресам вида 10.168.xx.xx.

Формат CIDR используется вместо указания конкретного IP-адреса, чтобы все узлы могли использовать одно и то же значение конфигурации. Например, для двух узлов с адресами 10.168.10.1 и 10.168.10.2 можно задать 10.168.10.0/24 в качестве значения priority_networks.

Q3. Что такое Master, Follower и Observer в FE?​

Прежде всего, у FE есть только две роли: Follower и Observer. Master — это один из FE, выбранный из группы узлов Follower. Master можно считать особым видом Follower. Поэтому на вопрос о количестве FE в кластере и их ролях следует отвечать, указывая общее количество узлов FE, а также количество узлов с ролями Follower и Observer.

Все узлы FE с ролью Follower образуют группу, в которой проводятся выборы, аналогичную группе в протоколе консенсуса Paxos. Внутри этой группы один из Follower избирается Master. При сбое Master другой Follower автоматически избирается новым Master. Узлы Observer не участвуют в выборах и поэтому не могут стать Master.

Запись в журнал метаданных считается успешной, только если она успешно сохранена на большинстве узлов Follower. Например, при наличии 3 узлов FE требуются 2 успешные записи. Именно поэтому количество узлов с ролью Follower должно быть нечётным.

Роль Observer, как следует из названия, выполняет функции наблюдателя: синхронизирует успешно записанные журналы метаданных и обслуживает запросы на чтение метаданных. Она не участвует в логике записи на большинство узлов.

Обычно можно развернуть 1 узел Follower + 2 узла Observer или 3 узла Follower + N узлов Observer. Первый вариант проще в эксплуатации и обслуживании: в нём практически не возникают сложные ошибки, связанные с протоколами согласованности между узлами Follower. Большинство организаций использует этот подход. Второй вариант обеспечивает высокую доступность записи метаданных. При большом количестве одновременно выполняемых запросов можно увеличить число узлов Observer.

Q4. Почему после добавления новых дисков на узлы данные не распределяются на эти диски?​

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

Кроме того, Doris пока не поддерживает балансировку между дисками одного узла. Поэтому после добавления новых дисков данные не будут перераспределены на них.

Однако при переносе данных между узлами Doris учитывает состояние дисков. Например, при переносе шарда с узла A на узел B предпочтение отдаётся дискам узла B с меньшей долей занятого пространства.

Эту проблему можно решить 3 способами:

  1. Создать новые таблицы

    Создайте новую таблицу с помощью оператора create table like, а затем используйте insert into select, чтобы скопировать данные из старой таблицы в новую. При создании новой таблицы её шарды будут размещаться в том числе на новых дисках, поэтому данные также будут записываться на них. Этот способ подходит для небольших объёмов данных, в пределах десятков GB.

  2. Использовать команду Decommission

    Команда decommission предназначена для безопасного вывода узла BE из эксплуатации. Сначала она переносит шарды данных с этого узла на другие узлы, а затем удаляет узел. Как уже упоминалось, при переносе данных предпочтение отдаётся дискам с меньшей долей занятого пространства. Поэтому этот способ позволяет принудительно перенести данные на диски других узлов. После завершения переноса выполните cancel для этой операции decommission, чтобы данные снова распределились на исходный узел. Если выполнить эти действия для всех узлов BE, данные будут равномерно распределены по всем дискам всех узлов.

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

    admin set frontend config("drop_backend_after_decommission" = "false");

  3. Перенести данные вручную с помощью API

    Doris предоставляет HTTP API, который позволяет вручную указать шарды данных для переноса с одного диска на другой.

Q5. Как правильно читать журналы FE/BE?​

Во многих случаях для поиска причин неполадок необходимо обращаться к журналам. Ниже описаны формат журналов FE/BE и способы их просмотра.

  1. FE

    Основные журналы FE:

    • fe.log: основной журнал. Содержит все записи, кроме содержимого fe.out.

    • fe.warn.log: часть основного журнала, содержащая только записи уровней WARN и ERROR.

    • fe.out: журнал стандартного вывода и вывода ошибок (stdout и stderr).

    • fe.audit.log: журнал аудита, в котором записываются все SQL-запросы, полученные этим FE.

    Пример типичной записи журнала FE:

    2021-09-16 23:13:22,502 INFO (tablet scheduler|43) [BeLoadRebalancer.selectAlternativeTabletsForCluster():85] cluster is balance: default_cluster with medium: HDD. skip

    • 2021-09-16 23:13:22,502: время записи в журнале.

    • INFO: уровень записи. По умолчанию используется INFO.

    • (tablet scheduler|43): имя и идентификатор потока. По идентификатору можно просмотреть контекст потока, чтобы выяснить, что в нём происходило.

    • BeLoadRebalancer.selectAlternativeTabletsForCluster():85: имя класса, имя метода и номер строки кода.

    • cluster is balance xxx: текст записи.

    Обычно следует просматривать журнал fe.log. В особых случаях некоторые записи могут выводиться в fe.out.

  2. BE

    Основные журналы BE:

    • be.INFO: основной журнал. Фактически это символическая ссылка на последний файл be.INFO.xxxx.

    • be.WARNING: часть основного журнала, содержащая только записи уровней WARN и FATAL. Фактически это символическая ссылка на последний файл be.WARN.xxxx.

    • be.out: журнал стандартного вывода и вывода ошибок (stdout и stderr).

    Пример типичной записи журнала BE:

    I0916 23:21:22.038795 28087 task_worker_pool.cpp:1594] finish report TASK. master host: 10.10.10.10, port: 9222

    • I0916 23:21:22.038795: уровень записи, дата и время. Заглавная буква I обозначает INFO, W — WARN, F — FATAL.

    • 28087: идентификатор потока. По нему можно просмотреть контекст потока, чтобы выяснить, что в нём происходило.

    • task_worker_pool.cpp:1594: файл исходного кода и номер строки.

    • finish report TASK xxx: текст записи.

    Обычно следует просматривать журнал be.INFO. В особых случаях, например при аварийном завершении BE, необходимо просмотреть be.out.

Q6. Как искать причину остановки узлов FE/BE?​

  1. BE

    BE — это процесс на C/C++, который может аварийно завершиться из-за ошибок программы, например выхода за границы памяти или обращения по недопустимому адресу, а также из-за нехватки памяти — Out Of Memory (OOM). Чтобы выяснить причину, выполните следующие действия:

    1. Проверьте be.out

      При завершении программы из-за нештатной ситуации процесс BE выводит текущий стек ошибки в be.out. Обратите внимание: используется именно be.out, а не be.INFO или be.WARNING. По стеку ошибки обычно можно примерно определить место сбоя в программе.

      Если в be.out присутствует стек ошибки, причиной обычно является ошибка программы, которую обычный пользователь может не суметь устранить самостоятельно. Обратитесь за помощью в группу WeChat, GitHub Discussion или список рассылки dev и приложите соответствующий стек ошибки, чтобы ускорить поиск причины.

    2. dmesg

      Если в be.out нет стека ошибки, скорее всего, система принудительно завершила процесс из-за OOM. В этом случае выполните команду dmesg -T, чтобы просмотреть системный журнал Linux. Если в конце есть запись вида Memory cgroup out of memory: Kill process 7187 (doris_be) score 1007 or sacrifice child, причиной была нехватка памяти.

      Проблемы с памятью могут возникать по разным причинам, включая тяжёлые запросы, импорт данных, compaction и другие операции. Использование памяти в Doris постоянно оптимизируется. За помощью можно обратиться в группу WeChat, GitHub Discussion или список рассылки dev.

    3. Проверьте, есть ли в be.INFO записи, начинающиеся с F

      Записи, начинающиеся с F, имеют уровень Fatal. Например, F0916 обозначает запись Fatal от 16 сентября. Такие записи обычно указывают на нарушение утверждений программы. Нарушение утверждения немедленно завершает процесс и свидетельствует об ошибке в программе. За помощью можно обратиться в группу WeChat, GitHub Discussion или список рассылки dev.

  2. FE

    FE — это процесс Java, который устойчивее программ на C/C++. Обычно причиной аварийного завершения FE бывает OOM (Out-of-Memory) или сбой записи метаданных. При таких ошибках стек обычно сохраняется в fe.log или fe.out. Дальнейшую диагностику необходимо проводить на основе этого стека.

Q7. Настройка каталогов данных SSD и HDD: при создании таблиц иногда возникает ошибка Failed to find enough host with storage medium and tag​

Doris позволяет настроить несколько путей хранения для узла BE. Обычно достаточно задать один путь хранения на каждый диск. При этом для путей можно указать тип носителя, например SSD или HDD. SSD обозначает высокоскоростные устройства хранения, а HDD — низкоскоростные.

Если в кластере используется только один тип носителя, например только HDD или только SSD, рекомендуется не указывать тип носителя явно в be.conf. Ошибка Failed to find enough host with storage medium and tag обычно возникает, когда в be.conf настроен только носитель SSD, а при создании таблицы явно указано properties {"storage_medium" = "hdd"}. Аналогично, если в be.conf настроен только носитель HDD, а при создании таблицы явно указано properties {"storage_medium" = "ssd"}, возникнет та же ошибка. Чтобы устранить её, измените параметр properties при создании таблицы в соответствии с конфигурацией либо удалите явное указание SSD/HDD из be.conf.

Указывая тип носителя для путей, можно использовать функцию хранения горячих и холодных данных Doris на уровне разделов: горячие данные будут храниться на SSD, а холодные — автоматически переноситься на HDD.

Обратите внимание: Doris не определяет автоматически фактический тип носителя диска, на котором расположен путь хранения. Пользователь должен явно указать этот тип в конфигурации пути. Например, путь /path/to/data1.SSD указывает на носитель SSD. При этом data1.SSD — фактическое имя каталога. Doris определяет тип носителя по суффиксу .SSD в имени каталога, а не по реальному типу устройства. Таким образом, пользователь может обозначить любой путь как носитель SSD: Doris проверяет только суффикс каталога и не проверяет, соответствует ли ему устройство хранения. Если суффикс не указан, по умолчанию используется HDD.

Иными словами, .HDD и .SSD служат только для обозначения относительной разницы в скорости каталогов хранения: «низкоскоростной» и «высокоскоростной». Они не определяют фактический тип носителя. Поэтому, если пути хранения на узле BE не различаются по типу носителя, указывать суффикс не требуется.

Q8. Не удаётся войти в Web UI при балансировке нагрузки между несколькими FE с помощью Nginx​

В Doris можно развернуть несколько FE. Если для доступа к Web UI используется балансировка нагрузки через Nginx, проблемы с сессиями могут приводить к постоянным запросам на повторный вход. Причина заключается в совместном использовании сессий. Nginx предоставляет централизованное решение для совместного использования сессий. Здесь используется механизм ip_hash в Nginx. Он позволяет с помощью ip_hash направлять запросы с определённого IP-адреса на один и тот же backend, чтобы клиент с этим IP-адресом мог поддерживать стабильную сессию с конкретным backend. Механизм ip_hash задаётся в конфигурации upstream:

upstream  doris.com {
   server    172.22.197.238:8030 weight=3;
   server    172.22.197.239:8030 weight=4;
   server    172.22.197.240:8030 weight=4;
   ip_hash;
}

Полный пример конфигурации Nginx:

user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log;
pid /run/nginx.pid;

# Load dynamic modules. See /usr/share/doc/nginx/README.dynamic.
include /usr/share/nginx/modules/*.conf;

events {
    worker_connections 1024;
}

http {
    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    sendfile            on;
    tcp_nopush          on;
    tcp_nodelay         on;
    keepalive_timeout   65;
    types_hash_max_size 2048;

    include             /etc/nginx/mime.types;
    default_type        application/octet-stream;

    # Load modular configuration files from the /etc/nginx/conf.d directory.
    # See http://nginx.org/en/docs/ngx_core_module.html#include
    # for more information.
    include /etc/nginx/conf.d/*.conf;
    #include /etc/nginx/custom/*.conf;
    upstream  doris.com {
      server    172.22.197.238:8030 weight=3;
      server    172.22.197.239:8030 weight=4;
      server    172.22.197.240:8030 weight=4;
      ip_hash;
    }

    server {
        listen       80;
        server_name  gaia-pro-bigdata-fe02;
        if ($request_uri ~ _load) {
           return 307 http://$host$request_uri ;
        }

        location / {
            proxy_pass http://doris.com;
            proxy_redirect default;
        }
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }
    }
 }

Q9. FE не запускается, а в fe.log постоянно появляется сообщение "wait catalog to be ready. FE type UNKNOWN"​

Обычно у этой проблемы две причины:

  1. Локальный IP-адрес, полученный при текущем запуске FE, отличается от адреса при предыдущем запуске. Обычно это связано с неправильной настройкой priority_network, из-за которой FE выбирает неверный IP-адрес при запуске. Необходимо изменить priority_network и перезапустить FE.

  2. Большинство узлов FE с ролью Follower в кластере не запущены. Например, есть 3 узла Follower, но запущен только один. В этом случае нужно запустить ещё хотя бы один FE, чтобы группа FE, участвующая в выборах, могла избрать Master и начать обслуживание запросов.

Если описанные выше меры не помогли, выполните восстановление по документации по работе с метаданными в официальной документации Doris.

Q10. Lost connection to MySQL server at 'reading initial communication packet', system error: 0​

Если при подключении к Doris через клиент MySQL возникает эта ошибка, обычно версия JDK, использованная для сборки FE, отличается от версии JDK, с которой FE запускается. Обратите внимание: в образе Docker для сборки по умолчанию используется OpenJDK 11. Его можно переключить на OpenJDK 8 с помощью команд. Подробности приведены в документации по сборке.

Q11. recoveryTracker should overlap or follow on disk last VLSN of 4,422,880 recoveryFirst= 4,422,882 UNEXPECTED_STATE_FATAL​

Иногда при перезапуске FE возникает приведённая выше ошибка, обычно только при наличии нескольких узлов Follower. Два значения в сообщении об ошибке отличаются на 2, из-за чего FE не запускается.

Это пока не исправленная ошибка BDB JE. Если вы столкнулись с ней, восстановить метаданные можно только с помощью процедуры аварийного восстановления, описанной в документации по работе с метаданными.

Q12. Несовместимость версий JDK при сборке и установке Doris​

Если вы самостоятельно собираете Doris с помощью Docker, после сборки и установки при запуске FE может возникнуть исключение java.lang.Suchmethoderror: java.nio.ByteBuffer.limit(I)Ljava/nio/ByteBuffer;. Это происходит потому, что в Docker по умолчанию используется JDK 11. Если в среде установки используется JDK 8, необходимо переключить среду JDK в Docker на JDK 8. Инструкции по переключению приведены в документации по сборке.

Q13. При локальном запуске FE или запуске модульных тестов возникает ошибка Cannot find external parser table action_table.dat​

Выполните следующую команду:

cd fe && mvn clean install -DskipTests

Если ошибка сохраняется, выполните вручную следующую команду:

cp fe-core/target/generated-sources/cup/org/apache/doris/analysis/action_table.dat fe-core/target/classes/org/apache/doris/analysis

Q14. После обновления до версии 1.2 BE не запускается из-за NoClassDefFoundError​

примечание

Проблема с зависимостями Java UDF относится к Doris начиная с версии 1.2

Если после обновления при запуске BE возникает следующая ошибка Java NoClassDefFoundError:

Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/doris/udf/JniUtil
Caused by: java.lang.ClassNotFoundException: org.apache.doris.udf.JniUtil

Необходимо скачать с официального сайта пакет зависимостей функций Java UDF apache-doris-java-udf-jar-with-dependencies-1.2.0, поместить его в каталог lib внутри каталога установки BE, а затем перезапустить BE.

Q15. После обновления до версии 1.2 при запуске BE возникает ошибка Failed to initialize JNI​

примечание

Проблема со средой Java относится к Doris начиная с версии 1.2

Если после обновления при запуске BE возникает следующая ошибка Failed to initialize JNI:

Failed to initialize JNI: Failed to find the library libjvm.so.

Необходимо задать переменную окружения JAVA_HOME в системе или переменную JAVA_HOME в be.conf, а затем перезапустить узел BE.

Q16. Docker: backend не запускается​

Возможно, процессор не поддерживает AVX2. Проверьте журналы backend с помощью docker logs -f be. Если процессор не поддерживает AVX2, необходимо использовать образ apache/doris:1.2.2-be-x86_64-noavx2 вместо apache/doris:1.2.2-be-x86_64. Обратите внимание: номер версии образа со временем меняется. Актуальную версию можно найти на Dockerhub.

Report issue
На этой странице