Ошибка при запуске Hadoop после остановки работающего (и работающего) экземпляра ранее, потому что Datanode сообщает, что каталог заблокирован

У меня есть кластер под управлением Hadoop 1.2.1 с Giraph поверх. Сервер работает нормально, но когда я его останавливаю, я не могу запустить его снова. В журнале datanode появляется следующая ошибка: ERROR org.apache.hadoop.hdfs.server.datanode.DataNode: java.io.IOException: невозможно заблокировать хранилище / pathToFolder / data / datanode. Каталог уже заблокирован.

Я пробовал много решений, которые нашел в Интернете:

  1. Проверка разрешений папок.
  2. Проверка одинаковых версий файла VERSION для namenode и datanode.
  3. Проверка файлов конфигурации (core-site, hdfs-site, mapred-site, master, slave, ...)
  4. Удаление / изменение папок данных namenode и datanode
  5. Удаление временных файлов hadoop

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

2020-06-24 11:23:46,624 INFO org.apache.hadoop.hdfs.server.datanode.DataNode: STARTUP_MSG:
/********************
STARTUP_MSG: Starting DataNode
STARTUP_MSG:   host = XXXX
STARTUP_MSG:   args = []
STARTUP_MSG:   version = 1.2.1
STARTUP_MSG:   build = https://svn.apache.org/repos/asf/hadoop/common/branches/branch-1.2 -r 1503152; compiled by 'mattf' on Mon Jul 22 15:23:09 PDT 2013
STARTUP_MSG:   java = 1.8.0_212
********************/
2020-06-24 11:23:46,719 INFO org.apache.hadoop.metrics2.impl.MetricsConfig: loaded properties from hadoop-metrics2.properties
2020-06-24 11:23:46,725 INFO org.apache.hadoop.metrics2.impl.MetricsSourceAdapter: MBean for source MetricsSystem,sub=Stats registered.
2020-06-24 11:23:46,726 INFO org.apache.hadoop.metrics2.impl.MetricsSystemImpl: Scheduled snapshot period at 10 second(s).
2020-06-24 11:23:46,726 INFO org.apache.hadoop.metrics2.impl.MetricsSystemImpl: DataNode metrics system started
2020-06-24 11:23:46,791 INFO org.apache.hadoop.metrics2.impl.MetricsSourceAdapter: MBean for source ugi registered.
2020-06-24 11:23:46,794 WARN org.apache.hadoop.metrics2.impl.MetricsSystemImpl: Source name ugi already exists!
2020-06-24 11:23:46,903 INFO org.apache.hadoop.hdfs.server.common.Storage: Cannot lock storage /users/lahdak/rojas/AppHadoop/data/datanode. The directory is already locked.
2020-06-24 11:23:47,004 ERROR org.apache.hadoop.hdfs.server.datanode.DataNode: java.io.IOException: Cannot lock storage /users/lahdak/rojas/AppHadoop/data/datanode. The directory is already locked.
        at org.apache.hadoop.hdfs.server.common.Storage$StorageDirectory.lock(Storage.java:599)
        at org.apache.hadoop.hdfs.server.common.Storage$StorageDirectory.analyzeStorage(Storage.java:452)
        at org.apache.hadoop.hdfs.server.datanode.DataStorage.recoverTransitionRead(DataStorage.java:111)
        at org.apache.hadoop.hdfs.server.datanode.DataNode.startDataNode(DataNode.java:414)
        at org.apache.hadoop.hdfs.server.datanode.DataNode.<init>(DataNode.java:321)
        at org.apache.hadoop.hdfs.server.datanode.DataNode.makeInstance(DataNode.java:1712)
        at org.apache.hadoop.hdfs.server.datanode.DataNode.instantiateDataNode(DataNode.java:1651)
        at org.apache.hadoop.hdfs.server.datanode.DataNode.createDataNode(DataNode.java:1669)
        at org.apache.hadoop.hdfs.server.datanode.DataNode.secureMain(DataNode.java:1795)
        at org.apache.hadoop.hdfs.server.datanode.DataNode.main(DataNode.java:1812)

2020-06-24 11:23:47,004 INFO org.apache.hadoop.hdfs.server.datanode.DataNode: SHUTDOWN_MSG:
/********************
SHUTDOWN_MSG: Shutting down DataNode at XXXX
********************/

hadoop hdfs datanode
person ricks1337    schedule 24.06.2020    source источник
comment
Сколько лет этому кластеру? Giraph больше не поддерживается, AFAIK и JanusGraph + HBase / Cassandra - это новые вещи. В любом случае данные datanode никогда не должны храниться в каталоге пользователя, если только это не пользователь, предназначенный для запуска службы datanode.   -  person OneCricketeer    schedule 26.06.2020

Ответы (1)


arrow_upward
0
arrow_downward

До сих пор не удалось избавиться от проблемы (Datanode не закрывается правильно), но я нашел обходной путь к ситуации. Я использовал lsof +D /path, чтобы обнаружить активные процессы и убить их. Странно то, что этот процесс был невидим для команд top и jps.

person ricks1337    schedule 29.06.2020