Hacer esto simplemente coloca la unidad en el arreglo sin hacer nada con él, es decir, es un miembro del arreglo pero no está activo en él. Por defecto, esto lo convierte en un repuesto:
sudo mdadm /dev/md0 --add /dev/sdb1
Si tiene una de repuesto, puede hacerla crecer forzando el número de unidades activas para que crezca la matriz. Con 3 unidades y 2 se espera que sean activo, necesitaría aumentar el conteo activo a 3.
mdadm --grow /dev/md0 --raid-devices=3
El controlador de matriz RAID notará que le falta una unidad y luego buscará una de repuesto. Al encontrar el repuesto, lo integrará en la matriz como una unidad activa. Abra una terminal de repuesto y deje que se ejecute esta línea de comando bastante tosca, para controlar el progreso de la resincronización. Asegúrese de escribirlo como una línea o use el carácter de salto de línea (\), y una vez que finalice la reconstrucción, simplemente escriba Ctrl-C en la terminal.
while true; do sleep 60; clear; sudo mdadm --detail /dev/md0; echo; cat /proc/mdstat; done
Su matriz ahora tendrá dos unidades activas que están sincronizadas, pero debido a que no hay 3 unidades, no estará 100 % limpia. Quite la unidad fallida, luego cambie el tamaño de la matriz. Tenga en cuenta que el --grow bandera es un nombre un poco inapropiado - puede significar cualquiera crecer o encogerse:
sudo mdadm /dev/md0 --fail /dev/{failed drive}
sudo mdadm /dev/md0 --remove /dev/{failed drive}
sudo mdadm --grow /dev/md0 --raid-devices=2
Con respecto a los errores, un problema de enlace con la unidad (es decir, el puerto PATA/SATA, el cable o el conector de la unidad) no es suficiente para desencadenar una conmutación por error de un repuesto dinámico, ya que el kernel generalmente cambiará a usar el otro "bueno". unidad mientras restablece el enlace a la unidad "incorrecta". Lo sé porque ejecuto una matriz de 3 unidades, 2 activas, 1 de repuesto, y una de las unidades recientemente decidió vomitar un poco en los registros. Cuando probé todas las unidades de la matriz, las 3 pasaron la versión "larga" de la prueba SMART, por lo que no es un problema con los platos, los componentes mecánicos o el controlador integrado, lo que deja un cable de enlace escamoso o un mal puerto SATA. Quizás esto es lo que estás viendo. Intente cambiar la unidad a un puerto de placa base diferente o use un cable diferente y vea si mejora.
Un seguimiento:completé mi expansión del espejo a 3 unidades, fallé y eliminé la unidad escamosa de la matriz md, cambié en caliente el cable por uno nuevo (la placa base lo admite) y volví a agregar la unidad. Al volver a agregar, inmediatamente comenzó una resincronización de la unidad. Hasta ahora, no ha aparecido ni un solo error en el registro a pesar de que la unidad se usa mucho. Entonces, sí, los cables de la unidad pueden volverse escamosos.
Tuve exactamente el mismo problema y, en mi caso, descubrí que el disco RAID activo sufrió errores de lectura durante la sincronización. Por lo tanto, el nuevo disco se sincronizó con éxito y, por lo tanto, se mantuvo marcado como repuesto.
Es posible que desee verificar su /var/log/messages y otros registros del sistema en busca de errores. Además, también podría ser una buena idea verificar el estado SMART de su disco:
1) Ejecute la prueba breve:
"smartctl -t corto /dev/sda"
2) Mostrar los resultados de la prueba:
"smartctl -l autoprueba /dev/sda"
En mi caso, esto devolvió algo como esto:
===INICIO DE LA SECCIÓN DE LECTURA DE DATOS INTELIGENTES ===
Número de revisión 1 de la estructura del registro de autodiagnóstico SMART
Num Test_Description Estado Restante LifeTime(horas) LBA_of_first_error
1 Extendido fuera de línea Completado:error de lectura 90 % 7564 27134728
2 Corto sin conexión completado:error de lectura 90 % 7467 1408449701
Tuve que iniciar una distribución en vivo y copiar manualmente los datos del disco defectuoso al nuevo (actualmente "de repuesto").
Tuve exactamente el mismo problema y siempre pensé que mi segundo disco, que quería volver a agregar a la matriz, tenía errores. Pero era mi disco original el que tenía errores de lectura.
Podrías comprobarlo con smartctl -t short /dev/sdX y ver los resultados unos minutos más tarde con smartctl -l selftest /dev/sdX . Para mí se veía así:
=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Short offline Completed: read failure 20% 25151 734566647
Traté de arreglarlos con este manual. Eso fue divertido :-). Sé que ha revisado ambos discos en busca de errores, pero creo que su problema es que el disco que todavía está en la matriz md tiene errores de lectura, por lo que falla la adición de un segundo disco.
Actualizar
Debe ejecutar adicionalmente un smartctl -a /dev/sdX Si ve Current_Pending_Sector> 0 algo está mal
197 Current_Pending_Sector 0x0012 098 098 000 Old_age Siempre - 69
Para mí, definitivamente fue el problema que eliminé un disco de la incursión solo para probar y no se pudo volver a sincronizar debido a fallas de lectura. La sincronización abortó a la mitad del camino. Cuando revisé mi disco que todavía estaba en la matriz raid, smartctl reportó problemas.
Pude arreglarlos con el manual de arriba y vi reducido el número de sectores pendientes. Pero hubo muchos y es un procedimiento largo y aburrido, así que usé mi copia de seguridad y restauré los datos en un servidor diferente.
Como no tuvo la oportunidad de usar SMART, supongo que su autocomprobación no mostró esos sectores rotos.
Para mí es una lección aprendida:revise sus discos antes de quitar uno de su arreglo.