HDFS dice que el archivo aún está abierto, pero se ha matado al proceso de escritura

Question

Soy nuevo en hadoop y he pasado las últimas dos horas tratando de encontrar este problema en Google, pero no pude encontrar nada que me ayudara. Mi problema es que HDFS dice que el archivo aún está abierto, a pesar de que el proceso de escritura está muerto hace mucho tiempo. Esto hace que sea imposible leer desde el archivo.

Ejecuté fsck en el directorio e informa que todo está en buen estado. Sin embargo cuando corro "hdfs Hadoop fsck fs: // hadoop/logs/prima/directory_containing_file -openforwrite" Me

Status: CORRUPT 
Total size: 222506775716 B 
Total dirs: 0 
Total files: 630 
Total blocks (validated): 3642 (avg. block size 61094666 B) 
    ******************************** 
    CORRUPT FILES: 1 
    MISSING BLOCKS: 1 
    MISSING SIZE:  30366208 B 
    ******************************** 
Minimally replicated blocks: 3641 (99.97254 %) 
Over-replicated blocks: 0 (0.0 %) 
Under-replicated blocks: 0 (0.0 %) 
Mis-replicated blocks:  0 (0.0 %) 
Default replication factor: 2 
Average block replication: 2.9991763 
Corrupt blocks:  0 
Missing replicas:  0 (0.0 %) 
Number of data-nodes:  23 
Number of racks:  1 

Haciendo el comando fsck de nuevo en el archivo que es openforwrite consigo

.Status: HEALTHY 
Total size: 793208051 B 
Total dirs: 0 
Total files: 1 
Total blocks (validated): 12 (avg. block size 66100670 B) 
Minimally replicated blocks: 12 (100.0 %) 
Over-replicated blocks: 0 (0.0 %) 
Under-replicated blocks: 0 (0.0 %) 
Mis-replicated blocks:  0 (0.0 %) 
Default replication factor: 2 
Average block replication: 3.0 
Corrupt blocks:  0 
Missing replicas:  0 (0.0 %) 
Number of data-nodes:  23 
Number of racks:  1 

¿Alguien tiene alguna idea de lo que está pasando y cómo puedo solucionarlo?

Answer 1

Me di cuenta de que los bloques parecen estar perdidos porque el servidor namenode no estaba disponible temporalmente, lo que corrompe el sistema de archivos de ese archivo. Parecía que la parte del archivo sin los bloques faltantes aún podía leerse/copiarse. Algo más de información sobre el control de la corrupción en hdfs está disponible en https://twiki.grid.iu.edu/bin/view/Storage/HadoopRecovery (espejo: http://www.webcitation.org/5xMTitU0r)

Editar: Parece que este problema se debe a un problema con Scribe (o más específicamente la DFSClient utilizado por Escribano) que cuelga al intentar escribir a HDFS. Reparamos manualmente el origen de nuestro clúster hadoop con HADOOP-6099 y HDFS-278, reconstruimos los binarios y reiniciamos el clúster con la nueva versión. No ha habido problemas en los dos meses que llevamos usando la nueva versión.