Respuestas a las preguntas más comunes sobre Kudu en EMR.
General
¿Dónde se almacenan los archivos de registro de Kudu?
Los archivos de registro de Kudu se encuentran en /mnt/disk1/log/kudu/@filepath.
¿Qué métodos de particionamiento admite Kudu?
Kudu admite el particionamiento por rango y el particionamiento por hash. Es posible combinar ambos métodos. Para obtener más detalles, consulte Apache Kudu Schema Design.
¿Cómo accedo a la interfaz web de Kudu?
Kudu no está integrado con Knox. En su lugar, cree un túnel SSH para acceder a la interfaz web. Para consultar las instrucciones, revise Create an SSH tunnel to access web UIs of open source components.
¿Dónde encuentro las preguntas frecuentes de la comunidad de Kudu?
Consulte la página de Apache Kudu Troubleshooting.
Errores de inicio
Error NonRecoverableException al conectar el cliente de Kudu
Este error indica que la cantidad de nodos maestros configurados en el cliente no coincide con lo que espera el clúster:
org.apache.kudu.client.NonRecoverableException: Could not connect to a leader master. Client configured with 1 master(s) (192.168.0.10:7051) but cluster indicates it expects 3 master(s) (192.168.0.36:7051,192.168.0.11:7051,192.168.0.10:7051)
Despliegue todos los nodos maestros obligatorios y conecte el cliente de Kudu al nodo maestro principal.
Fallo de inicio de Kudu debido a un defecto en el monitor de Bigboot
Un defecto en Bigboot V3.5.0 impide que Kudu se reinicie después de una falla. El monitor de Bigboot no logra eliminar la información obsoleta del servicio de su base de datos, lo que provoca que los intentos posteriores de reinicio fallen.
Detenga Kudu e inícielo nuevamente de forma directa en la máquina mediante los siguientes comandos.
Ejecute los siguientes comandos en un nodo core o task. Si los ejecuta en un nodo maestro, reemplace kudu-tserver por kudu-master.
/usr/lib/b2monitor-current/bin/monictrl -stop kudu-tserver
/usr/lib/b2monitor-current/bin/monictrl -start kudu-tserver
Ejecute estos comandos directamente en la máquina. Es posible que la consola de EMR no pueda realizar la operación de detención porque el servicio ya finalizó.
Error de sincronización de reloj que impide el inicio de Kudu
Este error ocurre cuando ntpd no puede conectarse al servidor NTP configurado:
Service unavailable: RunTabletServer() failed: Cannot initialize clock: timed out waiting for clock synchronisation: Error reading clock. Clock considered unsynchronized
Los registros también pueden incluir una salida similar a la siguiente:
E1010 10:37:54.165313 29920 system_ntp.cc:104] /sbin/ntptime
------------------------------------------
stdout:
ntp_gettime() returns code 5 (ERROR)
time e6ee0402.2a452c4c Mon, Oct 10 2022 10:37:54.165, (.165118697),
maximum error 16000000 us, estimated error 16000000 us, TAI offset 0
ntp_adjtime() returns code 5 (ERROR)
modes 0x0 (),
offset 0.000 us, frequency 187.830 ppm, interval 1 s,
maximum error 16000000 us, estimated error 16000000 us,
status 0x2041 (PLL,UNSYNC,NANO),
time constant 6, precision 0.001 us, tolerance 500 ppm,
Reinicie el servidor e inténtelo de nuevo.
Errores de ejecución
Error de red: no se puede resolver el nombre de host
Bad status: Network error: Could not obtain a remote proxy to the peer.: unable to resolve address for <hostname>: Name or service not known
Este error ocurre cuando no es posible resolver un nombre de host a una dirección IP. Sin una asignación válida, el par Raft de la tableta de Kudu no identifica a sus pares y finaliza la conexión.
Solución 1: Agregue la asignación de nombre de host a IP en /etc/hosts/@filepath.
Solución 2: Si se liberó el host asociado al nombre de host, agregue una asignación entre el nombre de host y cualquier dirección IP en /etc/hosts/@filepath. No es necesario que la dirección IP sea accesible. Una vez que existe la asignación, el servidor de tabletas de Kudu replica los datos del servidor Raft no disponible hacia un nuevo servidor Raft dentro del grupo Raft.
Error de integridad en la estructura del sistema de archivos
Bad status: I/O error: Failed to load Fs layout: could not verify integrity of files: <directory>, <number> data directories provided, but expected <number>
La cantidad de discos especificada por -fs_data_dirs no coincide con los metadatos registrados por -fs_metadata_dir. Actualice -fs_data_dirs para que la cantidad de discos coincida con lo registrado en -fs_metadata_dir.
Fallo en la creación de hilos (error 11 de pthread_create)
pthread_create failed: Resource temporarily unavailable (error 11)
Revise las siguientes causas en orden.
Límites de proceso insuficientes
Compruebe el límite actual para el máximo de procesos de usuario:
ulimit -a
Si el valor es demasiado bajo, auméntelo al modificar /etc/security/limits.conf/@filepath o al crear /etc/security/limits.d/kudu.conf/@filepath.
Fuga de hilos en el cliente de Kudu V0.8 en despliegues híbridos
En despliegues híbridos, los ejecutores de Spark pueden presentar fugas de hilos al usar el cliente de Kudu V0.8. Este es un problema conocido documentado en KUDU-1453. Actualice al cliente de Kudu V0.9 para resolver el problema.
Fuga de hilos de apagado en Trino
Cuando Trino se cierra, el hilo del hook de apagado se bloquea en el método take de BlockingQueue mientras espera un elemento. Este hilo no se puede interrumpir, por lo que el control de EMR continúa enviando señales SIGTERM y genera nuevos hilos de controlador SIGTERM hasta alcanzar el límite de procesos.
Corrija el problema desde el lado de Trino o fuerce la finalización del proceso con kill -9.
Fuga del pool de hilos del SDK de Jindo
Spark utiliza la clase JindoOssCommitter para trabajos de escritura. Esta clase crea un objeto JindoOssMagicCommitter que genera un pool de hilos llamado oss-committer-pool. Dicho pool de hilos no es estático y nunca se cierra. A medida que se crean nuevos objetos JindoOssMagicCommitter, los pools de hilos se acumulan sin liberarse. Esto es especialmente probable en cargas de trabajo de Spark Streaming o Structured Streaming.
Agregue los siguientes parámetros de Spark como solución alternativa al problema:
spark.sql.hive.outputCommitterClass=org.apache.hadoop.mapreduce.lib.output.FileOutputCommitter
spark.sql.sources.outputCommitterClass=org.apache.hadoop.mapreduce.lib.output.FileOutputCommitter
Identificar el proceso con mayor cantidad de hilos
Utilice el siguiente script threads_monitor.sh/@filepath para identificar qué proceso consume más hilos:
#!/bin/bash
total_threads=0
max_pid=-1
max_threads=-1
for tid in `ls /proc`
do
if [[ $tid != *self && -f /proc/$tid/status ]]; then
num_threads=`cat /proc/$tid/status | grep Threads | awk '{print $NF}'`
((total_threads+=num_threads))
if [[ ${max_pid} -eq -1 || ${max_threads} -lt ${num_threads} ]]; then
max_pid=${tid}
max_threads=${num_threads}
fi
# echo "Thread ${pid}: ${num_threads}"
fi
done
echo "Total threads: ${total_threads}"
echo "Max threads: ${max_threads}, pid is ${max_pid}"
ps -ef | grep ${max_pid} | grep -v grep
Se excedió el límite flexible de memoria
Rejecting Write request: Soft memory limit exceeded
El rendimiento de escritura supera el límite flexible de memoria. Para resolver esto, ajuste uno de los siguientes parámetros:
Configure el parámetro memory_limit_hard_bytes/@parmname para aumentar el tamaño de la memoria. El valor predeterminado es
0, lo que indica que el sistema establece automáticamente el uso máximo de memoria. Puede cambiar el valor a-1. Esto indica que no se impone ningún límite al uso de memoria.Configure el parámetro memory_limit_soft_percentage/@parmname para ajustar el porcentaje de memoria disponible. El valor predeterminado es
80.
Configuración de lista de permitidos de Kudu y actualización de tokens
¿Es obligatorio reiniciar el servicio de Kudu para actualizar un token caducado?
Problema: El token del servicio de Kudu caducó y desea actualizarlo.
Solución: Sí. Debe reiniciar el servicio de Kudu para actualizar el token.
Error: "Unable to open the Kudu table" o "Unable to initialize the Kudu scan node" al consultar tablas de Kudu desde Impala
Problema: Recibe uno de los siguientes errores al usar Impala para consultar tablas de Kudu:
Unable to open the Kudu tableUnable to initialize the Kudu scan node
Causa: Este error suele deberse a un token de Kudu Master caducado, a un fallo al obtener el líder o a un error de autenticación. Este error no está relacionado con las configuraciones de Ranger.
Solución:
Agregue la subred del cliente (por ejemplo,
10.85.0.0/16) a la configuración de la lista de permitidos de Kudu.Reinicie el servicio de Kudu.
Preguntas frecuentes sobre el reinicio de Kudu
La consola se queda cargando al reiniciar el servicio de Kudu
Problema: Al reiniciar el servicio de Kudu, la página de la consola sigue mostrando un indicador de carga.
Solución: Este problema puede ocurrir porque su sesión ha caducado, lo que causa problemas de actualización de la página, o porque el proceso de reinicio del servicio tarda en actualizar el estado. Actualice la página o revise el historial de operaciones.
¿Puedo usar consultas de Impala durante el reinicio del servicio de Kudu?
Problema: Desea saber si es posible consultar datos durante el reinicio del servicio de Kudu.
Solución: Se recomienda no ejecutar consultas durante el reinicio. Aunque el servicio de Impala puede permanecer disponible, las consultas que involucran tablas de Kudu fallarán debido a interrupciones en la conexión.
El servicio muestra un estado anómalo o solicita iniciar manualmente otros servicios después de reiniciar Kudu
Problema: Después de reiniciar el servicio de Kudu, la consola muestra un estado anómalo o le solicita iniciar manualmente otros servicios.
Solución: No se requiere ninguna acción manual. El estado anómalo suele mostrarse porque las comprobaciones de salud detectan que el servicio no se ha iniciado por completo. Si el servicio se recuperó por sí mismo y el nodo Maestro puede ejecutar consultas, el reinicio se completó. No necesita iniciar manualmente otros servicios.