Не удалось разместить достаточно реплик: ожидаемый размер равен 1, но можно выбрать только 0 типов хранения - PullRequest
0 голосов
/ 15 октября 2018

Не удалось разместить достаточно реплик: ожидаемый размер равен 1, но можно выбрать только 0 типов хранилища (репликация = 1, выбрано = [], недоступно = [DISK], удалено = [DISK], policy = BlockStoragePolicy

{HOT: 7, storageTypes = [DISK], creationFallbacks = [], replicationFallbacks = [ARCHIVE]}

У нас есть сценарий, в котором записывается несколько файлов hdfs (порядка 500-1000 файлов -не более 10-40 таких файлов, записанных одновременно) - мы не вызываем close сразу для каждого файла для каждой записи - но продолжаем писать до конца, а затем вызываем close.

Кажется, что иногда мы получаемВыше ошибка - и запись не удалась. Мы установили hdfs повторов на 10 - но это, кажется, не помогает.

Мы также увеличили dfs.datanode.handler.count до 200 - что иногда помогало, но не всегдаа) Поможет ли здесь увеличение dfs.datanode.handler.count?даже если 10 записаны одновременно .. б) Что нужно сделать, чтобы мы не получили ошибку на уровне приложения - поскольку такая страница мониторинга hadoop указывает на исправность дисков - но из предупреждающего сообщения казалось, что иногда дискибыли недоступны - org.apache.hadoop.hdfs.server.blockmanagement.BlockPlacementPolicy: не удалось разместить достаточно реплик, все еще нуждающихся в 1 для достижения 1 (unavailableStorages = [DISK], storagePolicy = BlockStoragePolicy

{HOT: 7, storageTypes = [DISK], creationFallbacks = [], replicationFallbacks = [ARCHIVE]}, newBlock = true) Все необходимые типы хранения недоступны: unavailableStorages = [DISK], storagePolicy = BlockStoragePolicy

Предполагая, чтоЭто происходит только тогда, когда мы обнаруживаем сбои на дисках - мы также пытались установить для dfs.client.block.write.replace-datanode-on-fail.enable значение false, чтобы при временных сбоях мы не получали ошибок.Но, похоже, это тоже не поможет.

Есть еще какие-нибудь предложения здесь?

1 Ответ

0 голосов
/ 28 февраля 2019

В моем случае это было исправлено открытием порта брандмауэра 50010 для узлов данных (в Docker)

...