Tenemos un grupo de terminales de consumo que tienen instalado Linux, un servidor web local y PostgreSQL. Estamos recibiendo informes de campo de máquinas con problemas y tras una investigación parece que hubo un corte de energía y ahora hay algo mal con el disco.
Asumí que el problema sería que la base de datos se corrompe o que los archivos con cambios recientes se revuelven, pero hay otros informes extraños.
- archivos con los permisos incorrectos
- archivos que se han convertido en directorios (por ejemplo,
index.phpahora es un directorio) - directorios que se han convertido en archivos
- archivos con datos codificados
Hay problemas con la base de datos que se corrompe, pero eso es algo que podría esperar. Lo que me sorprende más son los problemas más básicos del sistema de archivos, por ejemplo, permisos o cambiar un archivo a un directorio. Los problemas también están ocurriendo en archivos que no cambiaron recientemente (por ejemplo, el código y la configuración del software).
¿Es esto "normal" para la corrupción de SSD? Originalmente pensamos que estaba sucediendo en algunos SSD baratos, pero tenemos esto sucediendo en una marca (grado de consumo).
FWIW, no estamos haciendo autofsck en arranque sucio (no sé por qué, soy nuevo). Tenemos UPS instalados en algunos lugares, pero a veces no se hace correctamente, etc. Esto debería repararse, pero incluso entonces las personas pueden apagar el terminal de forma sucia, etc., por lo que no es infalible. El sistema de archivos es ext4.
La pregunta: ¿hay algo que podamos hacer para mitigar el problema a nivel de sistema?
Encontré algunos artículos que se refieren a apagar el caché de hardware o montar la unidad en modo de sincronización, pero no estoy seguro de si eso ayudaría en este caso (corrupción de metadatos y cambios no recientes). También leí una referencia sobre el montaje del sistema de archivos en modo de solo lectura. No podemos hacer eso porque necesitamos escribir, pero podríamos hacer una partición de solo lectura para el código y la configuración si eso fuera de ayuda.
Este es un ejemplo de una unidad sudo hdparm -i /dev/sda1:
Model=KINGSTON RBU-SMS151S364GG, FwRev=S9FM02.5, SerialNo=<deleted>
Config={ Fixed }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=0
BuffType=unknown, BuffSize=unknown, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=125045424
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6
AdvancedPM=yes: disabled (255) WriteCache=enabled
Drive conforms to: Unspecified: ATA/ATAPI-3,4,5,6,7
fuente
WriteCache=enabled. Este es un gran problema. La caché de escritura nunca debe habilitarse en discos duros que tengan una base de datos. Algunos proveedores, HP, por ejemplo, en realidad evitan habilitar el almacenamiento en caché de escritura en el disco duro por esta misma razón.Respuestas:
Cuando de repente pierde energía, los SSD MLC / TLC / QLC tienen dos modos de falla:
La primera condición de falla es obvia: sin protección de energía, se perderán todos los datos que no se encuentren en un almacenamiento estable (es decir: NAND), sino solo en caché volátil (DRAM). Lo mismo sucede con los discos mecánicos clásicos (y eso solo puede causar estragos en el sistema de archivos que no emite fsyncs correctamente).
La segunda condición de falla es un asunto de MLC + SSD: cuando se reprograma el bit de página alta para almacenar nuevos datos, una pérdida inesperada de energía puede destruir / alterar el bit inferior (es decir: datos comprometidos anteriores ) también.
La única solución verdadera y más obvia es integrar un caché DRAM protegido con pérdida de energía (generalmente usando baterías / supercaps), como lo han hecho desde siempre los controladores RAID de alta gama; esto, sin embargo, aumenta el costo / precio de la unidad. Las unidades de consumo generalmente no tienen cachés protegidas contra pérdida de energía; más bien, usan una variedad de soluciones más económicas como:
Volviendo a su pregunta: sus unidades Kingstone son ultra económicas, con un controlador no especificado y básicamente sin especificaciones públicas. No me sorprende que una pérdida repentina de energía corrompiera los datos anteriores. Desafortunadamente, incluso deshabilitar la memoria caché DRAM del disco (con la pérdida de rendimiento masiva que ordena) no resolverá su problema, ya que los datos anteriores (es decir, datos en reposo) pueden, y serán, corrompidos por pérdidas de energía no detectadas. Si se basan en el antiguo controlador Sandforce, se puede esperar incluso un bloque de unidad total en las circunstancias "correctas".
Le sugiero que revise su UPS y, a medio plazo, reemplace estas unidades antiguas.
Una última nota sobre PostgreSQL y otras bases de datos de Linux: no deshabilitarán la memoria caché del disco y no deben detectarse para hacerlo. Por el contrario, emiten fsyncs / FUA periódicos / necesarios para confirmar los datos clave en un almacenamiento estable. Esta es la forma en que se deben hacer las cosas a menos que exista una razón muy convincente (es decir, una unidad que miente sobre ATA FLUSHES / FUA).
EDITAR: si es posible, considere migrar a un sistema de archivos de suma de verificación como ZFS o BTRFS. Por lo menos, considere XFS, que tiene suma de comprobación de diario y, últimamente, incluso suma de comprobación de metadatos. Si se ve obligado a usar EXT4, considere habilitar el auto-fsck al inicio (fsck.ext4 es muy bueno para reparar la corrupción).
fuente
Si. No obtenga SSD súper barato: cualquier cosa fuera del mercado de consumo de gama baja tiene condensadores y protección total contra la pérdida de energía. Amd realmente no cuesta mucho más.
fuente
Lo primero que debe hacer es definir el tiempo de recuperación y los objetivos del punto de recuperación. ¿Cuánto tiempo tiene que recuperar uno de estos terminales y qué punto de datos en el tiempo es aceptable? Quizás dentro de un par de horas necesite ser capaz de recuperarse a la copia de seguridad de la semana pasada.
Pueden ocurrir todo tipo de cosas extrañas a los archivos si se pierden las escrituras en vuelo. La prioridad del sistema de archivos es mantener su propia coherencia de metadatos; es posible que no proporcionen las mismas garantías para sus datos. En otras palabras,
fsckno se garantiza la recuperación de sus datos. Su trabajo es conseguirle un sistema de archivos que se monte.Entonces, poder. Instale, configure y pruebe que UPS apagará el sistema con gracia. Esto permite que los cachés del sistema de archivos y las unidades mismas escriban.
Y, la durabilidad de las escrituras en los discos. Lea el capítulo de confiabilidad de PostgreSQL . Use el
diskchecker.plscript vinculado allí para hacer una prueba de bloqueo y determinar si las SSD mienten si las escrituras llegaron al almacenamiento no volátil. Si hay pérdida, considere reemplazarla con SSD que tengan protección contra pérdida de energía.Editar: agregó detalles de que la caché de escritura estaba habilitada. Puede intentar deshabilitar eso:
hdparm -W0 /dev/sdao el comando apropiado para una matriz de hardware. Referencia: guía de administración de almacenamiento RHEL .Las barreras de escritura del sistema de archivos imponen un orden de confirmaciones de diario. No es una garantía de que los datos estarán intactos, pero es más seguro para el sistema de archivos con un caché volátil. Aunque es el valor predeterminado, agregar la opción de montaje "barrera" claramente documenta que usted valora la consistencia sobre el rendimiento.
Finalmente, la última línea de defensa. Realice una prueba de restauración para asegurarse de que puede llevar su aplicación y base de datos al momento deseado. Esto es útil para todo tipo de pérdida de datos, no solo fallas de energía.
fuente