Puede ocurrir alguna vez, que recibas el código de error 1548 con el mensaje avisando que no se puede cargar mysql.proc.
Esto puede ocurrir ante una pérdida de datos. Lamentablemente lo viví en carne propia, luego de una caída de tensión a causa de un rayo de tormenta que se produjo cerca de mi domicilio.
En ese caso, lo primero que hay que hacer es reparar el sistema de archivos. Si tu sistema operativo es privativo, tendrás que usar las herramientas que trae el mismo y que la mayoría conoce. No es tema de este post ni de este blog.
En caso de usar GNU/Linux, hay varias formas de reparar utilizando fsck, dependiendo del sistema de archivos que utilices.
En mi caso uso reiserfs y tuve que restaurar el árbol y las hojas (si, los mensajes son bastante divertidos a pesar de la desesperada situación). Capítulo aparte es la situación relacionada con este sistema de archivos y su creador, Hans Reiser, que fue condenado por el asesinato de su esposa en 2008.
El comando usado para recuperar el sistema de archivos fue:
reiserfsck --rebuild-tree --scan-whole-partition
Dejo algunas capturas de pantalla interesantes con mensajes del programa de recuperación, que habla de hojas voladas y otras cuestiones.
Pero vamos a lo que realmente nos interesa. La recuperación de las bases de datos mysql.
Resulta que entre los archivos dañados, estaban mis queridas bases de datos. De la mayoría tengo copia estructural y algunos backups de datos. Pero una me preocupaba en particular y era la que más actualizaciones tiene: la relacionada con mi propio trabajo informático.
Al intentar iniciar el servidor mysql, me encontré que la base de datos mysql que contiene los privilegios estaba dañada. Y sin privilegios, no hay acceso.
Así que antes de iniciar con la recuperación, tuve que buscar una forma de ingresar a los datos aunque más no sea para poder verlos y exportarlos.
Para ello en una terminal y con privilegios de root ejecuté el comando siguiente, que levanta el servidor de bases de datos pero en forma restringida:
mysqld --skip-grant-tables --user=mysql
Por supuesto esto no es óptimo, pero es un primer paso, que me permitió acceder a las maltrechas tablas usando adminer o phpmyadmin.
Aproveché a hacer backup exportando las tablas de cada base de datos.
A partir de allí empezaba el proceso de recuperación.
Lo obvio era usar:
mysqlcheck --all-databases --check-upgrade --auto-repair
mysql < fix_priv_tables
Esto debería solucionar el problema, pero lamentablemente no era así.
Entonces opté por algo más agresivo:
mysql_upgrade -uroot -p --force
Ahí la cosa cambió y al fin empezaron a repararse las bases de datos. Fui tomando nota de las tablas que daban errores. Cada vez que saltaba un error, se caía el frágil servidor mysql, así que lo volvía a levantar con
mysqld --skip-grant-tables --user=mysql
y desde phpMyAdmin borraba la tabla que daba error. Luego otra vez a repasar con mysql_upgrade -uroot -p --force.
Realicé este procedimiento tantas veces como tablas dañadas encontraba en el sistema. Finalmente no dio más errores, reinicié la computadora y no solo tenía el motor de base de datos andando sino que además se restauraron los accesos (obviamente la reparación de la base de datos mysql fue exitosa), y pude restaurar backups de las tablas que borré.
Dejo todo esto escrito por si a alguien le es de utilidad y para mi mismo, por si vuelve a ocurrir un inconveniente similar (espero que no).
