Recuperarse de la corrupción del sistema de archivos ext2

Recuperarse de la corrupción del sistema de archivos ext2

Tengo una distribución de Linux TinyCore (3.6) en un dispositivo mío, que utiliza disco en módulo o almacenamiento flash compacto.

El sistema de archivos es ext2.

Tengo una pila LAMP en este dispositivo y estoy jugando con una base de datos MySQL que contiene más de 400 tablas (myisam). Las operaciones de escritura ocurren sistemáticamente cada 15 minutos.

Estas tablas son generadas por mi aplicación web, según mis necesidades de configuración.

Ahora bien, sucede que este dispositivo puede apagarse abruptamente, por falta de energía.

Lo que sucede es que, si MySQL está realizando alguna operación de escritura (es decir update, delete, insert), algunos de los datos y los archivos de índice pueden dañarse.

Seguro que no es gran cosa, pero realizar una repair tableoperación no es tan malo; las tablas se reparan y las aplicaciones pueden seguir ejecutándose, incluso si lamentablemente se pierden algunos datos (lo que en mi caso podría ser aceptable).

El problema es que, a menudo, cuando se produce un cierre abrupto, varios archivos de tabla MySQL (FRM o MYI o MYD) están en estado de "Error de entrada/salida" y mi interfaz MySQL informa un "error 5 del motor de almacenamiento" (I/ O error) para esas tablas. Obviamente, las aplicaciones que utilizan la base de datos no pueden ejecutarse correctamente.

En lugar de evitar eventos como esos (que creo que son inevitables hasta cierto punto), me gustaría pensar en algo para recuperarme correcta y posiblemente automáticamente de situaciones de error de E/S de archivos derivadas de los escenarios descritos anteriormente.

¿Algunas ideas?

EDITAR: Desafortunadamente no puedo cambiar a ext3, debo quedarme con ext2, también debido al hecho de que ext3 afectaría en gran medida los ciclos de escritura de la memoria de estado sólido.

Respuesta1

Creo que si estás usando CF, sin posibilidad de usarDM-MultiPathu otras características de mayor disponibilidad, entonces al menos debería montar esos sistemas de archivos con la opción "noatime", para prolongar la vida (donde no dependa de atimes para sus propios scripts, etc.).

Aparte de eso, no parece la plataforma más robusta.

información relacionada