Ошибки при работе с данными

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

Q1. Почему при загрузке данных через Stream Load по публичному адресу FE происходит перенаправление на внутренний IP-адрес?

Если Stream Load подключается к http-порту FE, FE случайным образом выбирает узел BE и выполняет перенаправление http 307. В результате запрос пользователя фактически отправляется на узел BE, назначенный FE. При перенаправлении возвращается IP-адрес BE, то есть адрес во внутренней сети. Поэтому при отправке запроса через публичный IP-адрес FE соединение, скорее всего, установить не удастся: запрос перенаправляется на внутренний сетевой адрес.

Обычно эту проблему решают, обеспечив доступ к внутреннему IP-адресу либо разместив балансировщик нагрузки перед всеми узлами BE. Во втором случае запрос Stream Load отправляется непосредственно балансировщику, который прозрачно передаёт его узлу BE.

Q2. Поддерживает ли Doris изменение имён столбцов?

Начиная с версии 1.2.0, имена столбцов можно изменять, если включён параметр "light_schema_change"="true".

В версиях до 1.2.0 или при отключённом параметре "light_schema_change"="true" изменение имён столбцов не поддерживается. Причины описаны ниже.

Doris поддерживает изменение имени базы данных, имени таблицы, имени раздела, имени материализованного представления (Rollup), а также типа столбца, комментария, значения по умолчанию и других свойств. Однако изменение имён столбцов пока не поддерживается.

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

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

Q3. Поддерживают ли таблицы модели Unique Key создание материализованных представлений?

Нет.

Таблицы модели Unique Key удобны для работы с бизнес-данными. Благодаря удалению дубликатов по первичному ключу они позволяют легко синхронизировать данные с рабочими базами данных, в которых часто происходят изменения. Поэтому при загрузке данных в Doris многие пользователи в первую очередь рассматривают модель Unique Key.

Однако для таблиц модели Unique Key нельзя создавать материализованные представления. Причина в том, что суть материализованного представления заключается в предварительном вычислении данных: при выполнении запроса возвращаются уже рассчитанные результаты, что ускоряет запрос. В материализованном представлении такие результаты обычно представляют собой агрегированные показатели, например sum и count. Если данные изменяются, например при обновлении или удалении, синхронно обновить предварительно вычисленные данные нельзя, поскольку в них уже нет подробной информации об исходных данных. Например, сумма 5 может быть результатом 1+4 или 2+3. Из-за потери подробной информации невозможно определить, как была рассчитана эта сумма, поэтому обеспечить её обновление нельзя.

Q4. tablet writer write failed, tablet_id=27306172, txn_id=28573520, err=-235 or -238

Эта ошибка обычно возникает при загрузке данных. Код ошибки: -235. Он означает, что число версий данных соответствующего tablet превысило максимально допустимое значение (по умолчанию 500, задаётся параметром BE max_tablet_version_num), поэтому дальнейшая запись отклоняется. Например, ошибка в вопросе означает, что число версий данных tablet 27306172 превысило ограничение.

Обычно причина этой ошибки в слишком высокой частоте загрузок: новые версии появляются быстрее, чем выполняется compaction данных на сервере, поэтому версии накапливаются и в итоге превышают ограничение. Сначала выполните инструкцию show tablet 27306172, а затем инструкцию show proc, указанную в результате, чтобы проверить состояние каждой реплики tablet. Поле versionCount в результате показывает число версий. Если у какой-либо реплики слишком много версий, уменьшите частоту загрузок или остановите загрузку и проследите, уменьшается ли число версий. Если после остановки загрузки число версий не уменьшается, перейдите на соответствующий узел BE, откройте журнал be.INFO, найдите записи по идентификатору tablet и ключевому слову compaction и проверьте, выполняется ли compaction штатно. Рекомендации по настройке compaction приведены в статье официального аккаунта ApacheDoris: Практические рекомендации по Doris: настройка Compaction (3)

Ошибка -238 обычно возникает, если объём данных в одном загружаемом пакете слишком велик, из-за чего для одного tablet создаётся слишком много файлов Segment (по умолчанию 200, задаётся параметром BE max_segment_num_per_rowset). Для решения проблемы рекомендуется уменьшить объём данных в одном пакете или соответствующим образом увеличить значение параметра конфигурации BE. Начиная с версии 2.0, можно включить функцию segment compaction, чтобы уменьшить число файлов сегментов, задав enable_segcompaction=true в конфигурации BE.

Q5. tablet 110309738 has few replicas: 1, alive backends: [10003]

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

Сначала проверьте с помощью команды show backends, не остановился ли узел BE. Например, поле isAlive имеет значение false или LastStartTime содержит недавнее время (что указывает на недавний перезапуск). Если BE остановился, перейдите на соответствующий узел и проверьте журнал be.out. При аварийном завершении BE в be.out обычно выводится трассировка стека исключения, которая помогает найти причину проблемы. Если в be.out нет трассировки стека, выполните команду Linux dmesg -T, чтобы проверить, не завершила ли система процесс из-за OOM.

Если все узлы BE работают, выполните инструкцию show tablet 110309738, а затем инструкцию show proc, указанную в результате, чтобы проверить состояние каждой реплики tablet и продолжить диагностику.

Q6. disk xxxxx on backend xxx exceed limit usage

Обычно эта ошибка возникает при операциях Import, Alter и других. Она означает, что использование соответствующего диска на BE превысило порог (по умолчанию 95%). В этом случае сначала выполните команду show backends. Поле MaxDiskUsedPct показывает процент использования самого заполненного диска на соответствующем BE. Если значение превышает 95%, возникает эта ошибка.

Перейдите на соответствующий узел BE и проверьте использование места в каталоге данных. Каталоги trash и snapshot можно очистить вручную, чтобы освободить место. Если каталог данных занимает много места, рассмотрите возможность удаления части данных. Подробности см. в разделе Управление дисковым пространством.

Q7. При загрузке большого пакета данных через Stream Load из программы на Java может возникнуть ошибка Broken Pipe.

Помимо Broken Pipe, могут возникать и другие необычные ошибки.

Обычно это происходит после включения httpv2. Сервис httpv2 представляет собой http-сервис, реализованный на spring boot, и использует tomcat в качестве встроенного контейнера по умолчанию. Однако, по всей видимости, tomcat некорректно обрабатывает перенаправления 307, поэтому позже встроенный контейнер заменили на jetty. Кроме того, в программе на java необходимо использовать apache http client версии новее 4.5.13. В предыдущих версиях также были проблемы с обработкой перенаправлений.

Проблему можно решить двумя способами:

1. Отключить httpv2

   Добавьте enable_http_server_v2=false в fe.conf и перезапустите FE. При этом новая версия пользовательского интерфейса и некоторые новые интерфейсы на базе httpv2 станут недоступны. (Обычные операции загрузки и выполнения запросов не затрагиваются.)

2. Обновить Doris

   В Doris 0.15 и более поздних версиях эта проблема исправлена.

Q8. При загрузке данных и выполнении запросов возникает ошибка -214

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

failed to initialize storage reader. tablet=63416.1050661139.aa4d304e7a7aff9c-f0fa7579928c85a0, res=-214, backend=192.168.100.10

Ошибка -214 означает, что у соответствующего tablet отсутствует версия данных. Например, приведённая выше ошибка указывает на отсутствие версии данных в реплике tablet 63416 на BE с адресом 192.168.100.10. (Могут встречаться и другие подобные коды ошибок; для их проверки и исправления можно использовать описанные ниже способы.)

Примечание к версии (4.0.8)

Начиная с версии 4.0.8, к ошибкам на этапе сканирования больше не добавляется единый префикс failed to initialize storage reader. Сохраняется исходное сообщение об ошибке, к которому добавляется только . tablet=... backend=....

Инициализация модуля чтения также включает немедленное чтение первой строки с вычислением выражений, переданных для выполнения на нижний уровень. Поэтому по этому пути поступают и ошибки данных, и ошибки выражений, а старый префикс создавал впечатление, что это сбои уровня хранения. При диагностике -214 ориентируйтесь на код ошибки и сведения tablet= / backend=, а не на совпадение с текстом префикса.

Обычно, если данные хранятся в нескольких репликах, система автоматически восстанавливает проблемные реплики. Для диагностики выполните следующие действия:

Сначала проверьте состояние каждой реплики соответствующего tablet, выполнив инструкцию show tablet 63416, а затем инструкцию show proc xxx, указанную в результате. Как правило, следует обращать внимание на данные в столбце Version.

В норме значение Version должно быть одинаковым для всех реплик tablet и совпадать с VisibleVersion соответствующего раздела.

Версию соответствующего раздела можно посмотреть с помощью show partitions from tblx (раздел, к которому относится tablet, можно определить с помощью инструкции show tablet).

Кроме того, можно перейти по URL из столбца CompactionStatus в результате инструкции show proc (просто откройте его в браузере), чтобы получить более подробные сведения о версиях и определить, какие из них отсутствуют.

Если автоматическое восстановление долго не происходит, выполните инструкцию show proc "/cluster_balance", чтобы посмотреть, какие задачи восстановления и планирования tablet сейчас выполняет система. Восстановление может занимать много времени из-за большого числа tablet, ожидающих планирования. Следите за записями в pending_tablets и running_tablets.

Кроме того, с помощью инструкции admin repair можно указать таблицу или раздел, которые следует восстановить в первую очередь. Подробности см. в help admin repair;

Если восстановление по-прежнему не удаётся и существует несколько реплик, используйте команду admin set replica status, чтобы принудительно вывести проблемную реплику из эксплуатации. Подробности см. в примере установки статуса реплики bad в help admin set replica status. (После установки статуса bad обращения к реплике прекращаются. Позже она будет автоматически восстановлена. Перед выполнением этой операции убедитесь, что остальные реплики исправны.)

Q9. Not connected to 192.168.100.1:8060 yet, server_id=384

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

Это ошибка RPC, у которой обычно две возможные причины: 1. Соответствующий узел BE остановился. 2. Перегрузка rpc или другие ошибки.

Если узел BE остановился, необходимо выяснить конкретную причину остановки. Здесь рассматривается только перегрузка rpc.

Один из возможных случаев: OVERCROWDED. Это означает, что на стороне отправителя rpc накопился большой объём неотправленных данных, превысивший порог. С этим связаны два параметра BE:

1. brpc_socket_max_unwritten_bytes: значение по умолчанию составляет 1GB. Если объём неотправленных данных превышает это значение, возникает ошибка. Значение можно скорректировать, чтобы избежать ошибок OVERCROWDED. (Однако это устраняет лишь симптомы: сама перегрузка сохраняется.)
2. tablet_writer_ignore_eovercrowded: по умолчанию false. При значении true Doris игнорирует ошибки OVERCROWDED во время загрузки. Этот параметр главным образом позволяет избежать сбоев загрузки и повысить её стабильность.

Во втором случае размер пакета rpc превышает max_body_size. Такая проблема может возникнуть, если запрос содержит очень большой объект типа String или bitmap. Её можно обойти, изменив следующие параметры BE:

brpc_max_body_size：default 3GB.

Q10. [ Broker load ] org.apache.thrift.transport.TTransportException: java.net.SocketException: Broken pipe

org.apache.thrift.transport.TTransportException: java.net.SocketException: Broken pipe при загрузке.

Причина может заключаться в том, что при загрузке данных из внешнего хранилища (например, HDFS) в каталоге находится слишком много файлов и получение их списка занимает слишком много времени. По умолчанию Broker RPC Timeout составляет 10 секунд; в таком случае это время ожидания нужно соответствующим образом скорректировать.

Измените файл конфигурации fe.conf, добавив следующие параметры:

broker_timeout_ms = 10000
##The default here is 10 seconds, you need to increase this parameter appropriately

После добавления параметров необходимо перезапустить службу FE.

Q11. [ Routine load ] ReasonOfStateChanged: ErrorReason{code=errCode = 104, msg='be 10004 abort task with reason: fetch failed due to requested offset not available on the broker: Broker: Offset out of range'}

Причина этой проблемы в том, что по умолчанию политика очистки Kafka предусматривает хранение данных в течение 7 дней. Если задача Routine Load по какой-либо причине была приостановлена и долго не возобновлялась, к моменту её возобновления Kafka может уже удалить данные, соответствующие смещению чтения, сохранённому Routine Load. В таком случае возникает эта ошибка.

Проблему можно решить с помощью alter routine load:

Посмотрите минимальное доступное смещение Kafka, измените смещение командой ALTER ROUTINE LOAD и возобновите задачу.

ALTER ROUTINE LOAD FOR db.tb
FROM kafka
(
 "kafka_partitions" = "0",
 "kafka_offsets" = "xxx",
 "property.group.id" = "xxx"
);

Q12. ERROR 1105 (HY000): errCode = 2, detailMessage = (192.168.90.91)[CANCELLED][INTERNAL_ERROR]error setting certificate verify locations: CAfile: /etc/ssl/certs/ca-certificates.crt CApath: none

yum install -y ca-certificates
ln -s /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt /etc/ssl/certs/ca-certificates.crt

Q13. create partition failed. partition numbers will exceed limit variable max_auto_partition_num

Чтобы предотвратить случайное создание слишком большого числа разделов при загрузке данных в таблицы с автоматическим разбиением на разделы, параметр конфигурации FE max_auto_partition_num ограничивает максимальное число разделов, создаваемых автоматически для таких таблиц. Если действительно нужно создать больше разделов, измените этот параметр на узле FE Master.