Lo hice y lo entendí

El blog de Vicente Navarro
27 ene

Corrupción en MySQL: ERROR 2006 (HY000): MySQL server has gone away

MySQL es una base de datos que cada vez me gusta más. Noto que no llega al nivel de funcionalidades de Oracle pero me da la sensación de que es una base de datos muy seria y potente para ciertos tipos usos. Sun acaba de comprar MySQL, espero que sea para bien de esta base de datos, aunque hagan lo que hagan con ella, el código GPL siempre quedará ahí disponible.

En esta entrada voy a contar un extraño problema de corrupción que he tenido con MySQL y cómo lo he solucionado a mi manera. Yo estoy aún empezando con MySQL y estoy un poco verde, así que seguro que he hecho alguna barbaridad que si alguno de vosotros detecta me encantaría que mencionara en los comentarios.

Yo tengo en /var/lib/mysql/ tres bases de datos, una de WordPress, otra de pruebas de WordPress y otra para MythTV:

# ll
total 20588
drwxr-xr-x  9 mysql mysql     4096 2008-01-27 20:47 ./
drwxr-xr-x 50 root  root      4096 2008-01-27 14:17 ../
-rw-r--r--  1 mysql mysql        0 2008-01-10 10:20 debian-5.0.flag
-rw-rw----  1 mysql mysql  5242880 2008-01-27 20:48 ib_logfile0
-rw-rw----  1 mysql mysql  5242880 2006-12-20 20:42 ib_logfile1
-rw-rw----  1 mysql mysql 10485760 2008-01-27 20:48 ibdata1
drwx------  2 mysql root      4096 2008-01-27 20:47 mysql/
-rw-------  1 mysql mysql        4 2006-12-20 20:42 mysql_upgrade.info
-rw-------  1 mysql mysql        6 2007-02-26 11:40 mysql_upgrade_info
drwx------  2 mysql mysql    12288 2006-12-23 11:22 mythconverg/
drwx------  2 mysql mysql     4096 2007-11-11 21:10 wordpress/
drwx------  2 mysql mysql     4096 2008-01-27 13:20 wordpress_dev/

También está la base de datos principal “mysql” que contiene información que necesita almacenar MySQL, como usuarios, privilegios y cosas así.

Pues bien, hoy he querido entrar a esa base de datos a hacer una consulta sobre los usuarios y he visto que, aunque podía entrar en la base de datos mysql, no podía hacer consultas, ya que me devolvía errores 2006 y 2002:

 # mysql -p
Enter password: 
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 1283
Server version: 5.0.32-Debian_7etch4-log Debian etch distribution
 
Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
 
mysql> use mysql
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
 
Database changed
mysql> show tables;
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
Connection id:    3
Current database: mysql
 
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (111)
ERROR: 
Can't connect to the server

El mysqlcheck también fallaba con el error 2002:

# mysqlcheck --all-databases -p
Enter password: 
mysqlcheck: Got error: 2002: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (111) when selecting the database

Curiosamente, todas las demás bases de datos parece que estaban funcionando sin ningún problema. Había leído que estos problemas en una conexión local podrían significar que el mysqld podría estar muriendo. Lo primero que he hecho ha sido mirar en los ficheros /var/log/mysql.log y /var/log/mysql.err, pero están vacíos, ya que como he comprobado en el /etc/mysql/my.cnf, en Debian el MySQL manda sus mensajes al syslog:

# Both location gets rotated by the cronjob.
# Be aware that this log type is a performance killer.
#log            = /var/log/mysql/mysql.log
#
# Error logging goes to syslog. This is a Debian improvement

Así que mirando en el /var/log/syslog me encuentro con este terrorífico error:

Jan 27 20:31:27 mysqld[7969]: mysqld got signal 11;
Jan 27 20:31:27 mysqld[7969]: This could be because you hit a bug. It is also possible that this binary
Jan 27 20:31:27 mysqld[7969]: or one of the libraries it was linked against is corrupt, improperly built,
Jan 27 20:31:27 mysqld[7969]: or misconfigured. This error can also be caused by malfunctioning hardware.
Jan 27 20:31:27 mysqld[7969]: We will try our best to scrape up some info that will hopefully help diagnose
Jan 27 20:31:27 mysqld[7969]: the problem, but since we have already crashed, something is definitely wrong
Jan 27 20:31:27 mysqld[7969]: and this may fail.
Jan 27 20:31:27 mysqld[7969]: 
Jan 27 20:31:27 mysqld[7969]: key_buffer_size=16777216
Jan 27 20:31:27 mysqld[7969]: read_buffer_size=131072
Jan 27 20:31:27 mysqld[7969]: max_used_connections=1
Jan 27 20:31:27 mysqld[7969]: max_connections=100
Jan 27 20:31:27 mysqld[7969]: threads_connected=1
Jan 27 20:31:27 mysqld[7969]: It is possible that mysqld could use up to 
Jan 27 20:31:27 mysqld[7969]: key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 233983 K
Jan 27 20:31:27 mysqld[7969]: bytes of memory
Jan 27 20:31:27 mysqld[7969]: Hope that's ok; if not, decrease some variables in the equation.
Jan 27 20:31:27 mysqld[7969]: 
Jan 27 20:31:27 mysqld[7969]: thd=0x8aca400
Jan 27 20:31:27 mysqld[7969]: Attempting backtrace. You can use the following information to find out
Jan 27 20:31:27 mysqld[7969]: where mysqld died. If you see no messages after this, something went
Jan 27 20:31:27 mysqld[7969]: terribly wrong...
Jan 27 20:31:27 mysqld[7969]: Cannot determine thread, fp=0xb3f65218, backtrace may not be correct.
Jan 27 20:31:27 mysqld[7969]: Stack range sanity check OK, backtrace follows:
Jan 27 20:31:27 mysqld[7969]: 0x81c0619
Jan 27 20:31:27 mysqld[7969]: 0x8204148
Jan 27 20:31:27 mysqld[7969]: 0x81fc598
Jan 27 20:31:27 mysqld[7969]: 0x81fdb04
Jan 27 20:31:27 mysqld[7969]: 0x81fe175
Jan 27 20:31:27 mysqld[7969]: 0x81fe327
Jan 27 20:31:27 mysqld[7969]: 0x82a2559
Jan 27 20:31:27 mysqld[7969]: 0x829dbbe
Jan 27 20:31:27 mysqld[7969]: 0x82206eb
Jan 27 20:31:27 mysqld[7969]: 0x82221c0
Jan 27 20:31:27 mysqld[7969]: 0x8222a2e
Jan 27 20:31:27 mysqld[7969]: 0x81d7638
Jan 27 20:31:27 mysqld[7969]: 0x81dbba7
Jan 27 20:31:27 mysqld[7969]: 0x81dc060
Jan 27 20:31:27 mysqld[7969]: 0x81dd328
Jan 27 20:31:27 mysqld[7969]: 0x81ddd34
Jan 27 20:31:27 mysqld[7969]: 0xb7f17240
Jan 27 20:31:27 mysqld[7969]: 0xb7d5249e
Jan 27 20:31:27 mysqld[7969]: New value of fp=(nil) failed sanity check, terminating stack trace!
Jan 27 20:31:27 mysqld[7969]: Please read http://dev.mysql.com/doc/mysql/en/using-stack-trace.html and follow instructions on how to resolve the stack trace. Resolved
Jan 27 20:31:27 mysqld[7969]: stack trace is much more helpful in diagnosing the problem, so please do 
Jan 27 20:31:27 mysqld[7969]: resolve it
Jan 27 20:31:27 mysqld[7969]: Trying to get some variables.
Jan 27 20:31:27 mysqld[7969]: Some pointers may be invalid and cause the dump to abort...
Jan 27 20:31:27 mysqld[7969]: thd->query at 0x8b02ee8 = SHOW TABLE STATUS
Jan 27 20:31:27 mysqld[7969]: thd->thread_id=4
Jan 27 20:31:27 mysqld[7969]: The manual page at http://www.mysql.com/doc/en/Crashing.html contains
Jan 27 20:31:27 mysqld[7969]: information that should help you find out what is causing the crash.
Jan 27 20:31:27 mysqld_safe[7988]: Number of processes running now: 0
Jan 27 20:31:27 mysqld_safe[7990]: restarted
Jan 27 20:31:27 mysqld[7993]: 080127 20:31:27  InnoDB: Started; log sequence number 0 43675
Jan 27 20:31:27 mysqld[7993]: 080127 20:31:27 [Note] Recovering after a crash using /var/log/mysql/mysql-bin
Jan 27 20:31:27 mysqld[7993]: 080127 20:31:27 [Note] Starting crash recovery...
Jan 27 20:31:27 mysqld[7993]: 080127 20:31:27 [Note] Crash recovery finished.
Jan 27 20:31:27 mysqld[7993]: 080127 20:31:27 [ERROR] /usr/sbin/mysqld: Incorrect information in file: './mysql/time_zone.frm'
Jan 27 20:31:27 mysqld[7993]: 080127 20:31:27 [ERROR] /usr/sbin/mysqld: Incorrect information in file: './mysql/time_zone.frm'
Jan 27 20:31:27 mysqld[7993]: 080127 20:31:27 [Warning] Can't open and lock time zone table: Incorrect information in file: './mysql/time_zone.frm' trying to live without them
Jan 27 20:31:27 mysqld[7993]: 080127 20:31:27 [Note] /usr/sbin/mysqld: ready for connections.
Jan 27 20:31:27 mysqld[7993]: Version: '5.0.32-Debian_7etch4-log'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  Debian etch distribution

Las líneas que me han parecido más útiles del error son:

[ERROR] /usr/sbin/mysqld: Incorrect information in file: './mysql/time_zone.frm'
[Warning] Can't open and lock time zone table: Incorrect information in file: './mysql/time_zone.frm' trying to live without them

Los ficheros /var/log/mysql/mysql/time_zone.*:

# ll /var/lib/mysql/mysql/time_zone.*                                                                                                                    
-rw-rw---- 1 mysql mysql    0 2007-11-19 18:22 /var/lib/mysql/mysql/time_zone.MYD
-rw-rw---- 1 mysql mysql 1024 2007-11-19 18:22 /var/lib/mysql/mysql/time_zone.MYI
-rw-rw---- 1 mysql mysql 8636 2007-11-19 18:22 /var/lib/mysql/mysql/time_zone.frm

son los que corresponden a la tabla time_zone de la base de datos mysql. Parece que a pesar de que son sólo algunos bytes estaba corrupta. Aunque otros ficheros de tablas del directorio tienen fecha reciente, éstos son de hace muchos meses. ¿Llevaría tanto tiempo mal y no me había dado cuenta?

El comando mysql_install_db es el que se usa tras instalar el software de MySQL para inicializar los directorios creando las tablas del sistema (base de datos mysql). En las distribuciones, esto ya lo hacen normalmente los scripts de instalación del paquete. Este comando no sobreescribe los ficheros MYD, MYI y frm de tablas ya existentes, así que he pensado en volver a ejecutar ese comando tras parar el mysqld (/etc/init.d/mysql stop) y eliminar los ficheros time_zone.*. El resultado es que se han creado nuevos ficheros time_zone.*, pero al arrancar, un error más monstruoso aún que el anterior:

Jan 27 20:42:46 mysqld_safe[8278]: started
Jan 27 20:42:46 mysqld[8281]: 080127 20:42:46  InnoDB: Started; log sequence number 0 43675
Jan 27 20:42:46 mysqld[8281]: 080127 20:42:46 [Note] /usr/sbin/mysqld: ready for connections.
Jan 27 20:42:46 mysqld[8281]: Version: '5.0.32-Debian_7etch4-log'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  Debian etch distribution
Jan 27 20:42:47 /etc/mysql/debian-start[8315]: Upgrading MySQL tables if necessary.
Jan 27 20:42:48 mysqld[8281]: mysqld got signal 11;
Jan 27 20:42:48 mysqld[8281]: This could be because you hit a bug. It is also possible that this binary
Jan 27 20:42:48 mysqld[8281]: or one of the libraries it was linked against is corrupt, improperly built,
Jan 27 20:42:48 mysqld[8281]: or misconfigured. This error can also be caused by malfunctioning hardware.
Jan 27 20:42:48 mysqld[8281]: We will try our best to scrape up some info that will hopefully help diagnose
Jan 27 20:42:48 mysqld[8281]: the problem, but since we have already crashed, something is definitely wrong
Jan 27 20:42:48 mysqld[8281]: and this may fail.
Jan 27 20:42:48 mysqld[8281]: 
Jan 27 20:42:48 mysqld[8281]: key_buffer_size=16777216
Jan 27 20:42:48 mysqld[8281]: read_buffer_size=131072
Jan 27 20:42:48 mysqld[8281]: max_used_connections=1
Jan 27 20:42:48 mysqld[8281]: max_connections=100
Jan 27 20:42:48 mysqld[8281]: threads_connected=1
Jan 27 20:42:48 mysqld[8281]: It is possible that mysqld could use up to 
Jan 27 20:42:48 mysqld[8281]: key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 233983 K
Jan 27 20:42:48 mysqld[8281]: bytes of memory
Jan 27 20:42:48 mysqld[8281]: Hope that's ok; if not, decrease some variables in the equation.
Jan 27 20:42:48 mysqld[8281]: 
Jan 27 20:42:48 mysqld[8281]: thd=0x8aca400
Jan 27 20:42:48 mysqld[8281]: Attempting backtrace. You can use the following information to find out
Jan 27 20:42:48 mysqld[8281]: where mysqld died. If you see no messages after this, something went
Jan 27 20:42:48 mysqld[8281]: terribly wrong...
Jan 27 20:42:48 mysqld[8281]: Cannot determine thread, fp=0xb3f39b38, backtrace may not be correct.
Jan 27 20:42:48 mysqld[8281]: Stack range sanity check OK, backtrace follows:
Jan 27 20:42:48 mysqld[8281]: 0x81c0619
Jan 27 20:42:48 mysqld[8281]: 0x8204148
Jan 27 20:42:48 mysqld[8281]: 0x81fc598
Jan 27 20:42:48 mysqld[8281]: 0x81fdb04
Jan 27 20:42:48 mysqld[8281]: 0x81fde9a
Jan 27 20:42:48 mysqld[8281]: 0x829467d
Jan 27 20:42:48 mysqld[8281]: 0x81d8359
Jan 27 20:42:48 mysqld[8281]: 0x81dbba7
Jan 27 20:42:48 mysqld[8281]: 0x81dc060
Jan 27 20:42:48 mysqld[8281]: 0x81dd328
Jan 27 20:42:48 mysqld[8281]: 0x81ddd34
Jan 27 20:42:48 mysqld[8281]: 0xb7eec240
Jan 27 20:42:48 mysqld[8281]: 0xb7d2749e
Jan 27 20:42:48 mysqld[8281]: New value of fp=(nil) failed sanity check, terminating stack trace!
Jan 27 20:42:48 mysqld[8281]: Please read http://dev.mysql.com/doc/mysql/en/using-stack-trace.html and follow instructions on how to resolve the stack trace. R
esolved
Jan 27 20:42:48 mysqld[8281]: stack trace is much more helpful in diagnosing the problem, so please do 
Jan 27 20:42:48 mysqld[8281]: resolve it
Jan 27 20:42:48 mysqld[8281]: Trying to get some variables.
Jan 27 20:42:48 mysqld[8281]: Some pointers may be invalid and cause the dump to abort...
Jan 27 20:42:48 mysqld[8281]: thd->query at 0x8b03090 = ALTER TABLE proc MODIFY name char(64) DEFAULT '' NOT NULL,
Jan 27 20:42:48 mysqld[8281]:                  MODIFY specific_name char(64) DEFAULT '' NOT NULL,
Jan 27 20:42:48 mysqld[8281]:                  MODIFY sql_data_access
Jan 27 20:42:48 mysqld[8281]:                         enum('CONTAINS_SQL',
Jan 27 20:42:48 mysqld[8281]:                              'NO_SQL',
Jan 27 20:42:48 mysqld[8281]:                              'READS_SQL_DATA',
Jan 27 20:42:48 mysqld[8281]:                              'MODIFIES_SQL_DATA'
Jan 27 20:42:48 mysqld[8281]:                             ) DEFAULT 'CONTAINS_SQL' NOT NULL,
Jan 27 20:42:48 mysqld[8281]:                  MODIFY body longblob DEFAULT '' NOT NULL,
Jan 27 20:42:48 mysqld[8281]:                  MODIFY sql_mode
Jan 27 20:42:48 mysqld[8281]:                         set('REAL_AS_FLOAT',
Jan 27 20:42:48 mysqld[8281]:                             'PIPES_AS_CONCAT',
Jan 27 20:42:48 mysqld[8281]:                             'ANSI_QUOTES',
Jan 27 20:42:48 mysqld[8281]:                             'IGNORE_SPACE',
Jan 27 20:42:48 mysqld[8281]:                             'NOT_USED',
Jan 27 20:42:48 mysqld[8281]:                             'ONLY_FULL_GROUP_BY',
Jan 27 20:42:48 mysqld[8281]:                             'NO_UNSIGNED_SUBTRACTION',
Jan 27 20:42:48 mysqld[8281]:                             'NO_DIR_IN_CREATE',
Jan 27 20:42:48 mysqld[8281]:                             'POSTGRESQL',
Jan 27 20:42:48 mysqld[8281]:                             'ORACLE',
Jan 27 20:42:48 mysqld[8281]:                             'MSSQL',
Jan 27 20:42:48 mysqld[8281]:                             'DB2'
Jan 27 20:42:48 mysqld[8281]: thd->thread_id=4
Jan 27 20:42:48 mysqld[8281]: The manual page at http://www.mysql.com/doc/en/Crashing.html contains
Jan 27 20:42:48 mysqld[8281]: information that should help you find out what is causing the crash.
Jan 27 20:42:48 /etc/mysql/debian-start[8318]: ERROR 2013 (HY000) at line 516: Lost connection to MySQL server during query
Jan 27 20:42:48 /etc/mysql/debian-start[8318]: ERROR 2006 (HY000) at line 560: MySQL server has gone away
Jan 27 20:42:48 /etc/mysql/debian-start[8318]: ERROR 2006 (HY000) at line 562: MySQL server has gone away
Jan 27 20:42:48 /etc/mysql/debian-start[8318]: ERROR 2006 (HY000) at line 573: MySQL server has gone away
Jan 27 20:42:48 /etc/mysql/debian-start[8328]: Checking for crashed MySQL tables.
Jan 27 20:42:48 mysqld_safe[8331]: Number of processes running now: 0
Jan 27 20:42:48 mysqld_safe[8333]: restarted
Jan 27 20:42:48 mysqld[8336]: 080127 20:42:48  InnoDB: Started; log sequence number 0 43675
Jan 27 20:42:48 mysqld[8336]: 080127 20:42:48 [Note] Recovering after a crash using /var/log/mysql/mysql-bin
Jan 27 20:42:48 mysqld[8336]: 080127 20:42:48 [Note] Starting crash recovery...
Jan 27 20:42:48 mysqld[8336]: 080127 20:42:48 [Note] Crash recovery finished.
Jan 27 20:42:48 mysqld[8336]: 080127 20:42:48 [Note] /usr/sbin/mysqld: ready for connections.
Jan 27 20:42:48 mysqld[8336]: Version: '5.0.32-Debian_7etch4-log'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  Debian etch distribution
Jan 27 20:42:48 /etc/mysql/debian-start[8356]: WARNING: mysqlcheck has found corrupt tables
Jan 27 20:42:48 /etc/mysql/debian-start[8356]: /usr/bin/mysqlcheck: Got error: 2002: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld
.sock' (2) when trying to connect
Jan 27 20:42:48 /etc/mysql/debian-start[8356]: 
Jan 27 20:42:48 /etc/mysql/debian-start[8356]:  Improperly closed tables are also reported if clients are accessing
Jan 27 20:42:48 /etc/mysql/debian-start[8356]:  the tables *now*. A list of current connections is below.
Jan 27 20:42:48 /etc/mysql/debian-start[8356]:

Así que me decido a recrear por completo las tablas del sistema. Para ello, vuelvo a parar el mysqld, muevo el directorio /var/lib/mysql/mysql/ a otro sitio y ejecuto el mysql_install_db de nuevo:

# mysql_install_db --verbose                                                                                                                  
Installing all prepared tables
Preparing db table
Preparing host table
Preparing user table
Preparing func table
Preparing tables_priv table
Preparing columns_priv table
Preparing procs_priv table
Preparing help_topic table
Preparing help_category table
Preparing help_keyword table
Preparing help_relation table
Preparing time_zone_name table
Preparing time_zone table
Preparing time_zone_transition table
Preparing time_zone_transition_type table
Preparing time_zone_leap_second table
Fill help tables
 
To start mysqld at boot time you have to copy support-files/mysql.server
to the right place for your system
 
PLEASE REMEMBER TO SET A PASSWORD FOR THE MySQL root USER !
To do so, start the server, then issue the following commands:
/usr/bin/mysqladmin -u root password 'new-password'
/usr/bin/mysqladmin -u root -h telemaco password 'new-password'
See the manual for more instructions.
 
You can start the MySQL daemon with:
cd /usr ; /usr/bin/mysqld_safe &
 
You can test the MySQL daemon with the benchmarks in the 'sql-bench' directory:
cd sql-bench ; perl run-all-tests
 
Please report any problems with the /usr/bin/mysqlbug script!
 
The latest information about MySQL is available on the web at

http://www.mysql.com

Support MySQL by buying support/licenses at http://shop.mysql.com

Intento arrancar el servidor (/etc/init.d/mysql start) y, como ahora he perdido toda la información de usuarios y permisos de la base de datos, me encuentro con los siguientes errores por la falta del usuario debian-sys-maint que usa Debian para su mantenimiento de MySQL:

# /etc/init.d/mysql start
Starting MySQL database server: mysqld.
Checking for corrupt, not cleanly closed and upgrade needing tables..
/usr/bin/mysqladmin: connect to server at 'localhost' failed
error: 'Access denied for user 'debian-sys-maint'@'localhost' (using password: YES)'
/usr/bin/mysqladmin: connect to server at 'localhost' failed
error: 'Access denied for user 'debian-sys-maint'@'localhost' (using password: YES)'

Debido a la ausencia de ese usuario, no es posible hacer un “/etc/init.d/mysql stop” para parar el proceso, así que tenemos que hacerlo manualmente:

 # ps -ef | grep mysql
root      8501     1  0 20:47 pts/0    00:00:00 /bin/sh /usr/bin/mysqld_safe
mysql     8538  8501  1 20:47 pts/0    00:00:00 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --pid-file=/var/run/mysqld/mysqld.pid --skip-external-locking --port=3306 --socket=/var/run/mysqld/mysqld.sock
root      8539  8501  0 20:47 pts/0    00:00:00 logger -p daemon.err -t mysqld_safe -i -t mysqld
root      8598  7931  0 20:48 pts/0    00:00:00 grep mysql

# kill 8538

# ps -ef |grep mysql
root      8603  7931  0 20:48 pts/0    00:00:00 grep mysql

El usuario debian-sys-maint se crea en el script de postinstall del paquete mysql-server-5.0. Podemos consultar detenidamente qué hace examinando el fichero /var/lib/dpkg/info/mysql-server-5.0.postinst. En cualquier caso, para que se vuelva a ejecutar el script y se regenere el usuario podemos, simplemente, reinstalar el paquete:

# apt-get --reinstall install mysql-server-5.0                                                                                                           
Reading package lists... Done
Building dependency tree... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded.
Need to get 0B/25.2MB of archives.
After unpacking 0B of additional disk space will be used.
Do you want to continue [Y/n]? 
Preconfiguring packages ...
(Reading database ... 77144 files and directories currently installed.)
Preparing to replace mysql-server-5.0 5.0.32-7etch4 (using .../mysql-server-5.0_5.0.32-7etch4_i386.deb) ...
Stopping MySQL database server: mysqld.
Stopping MySQL database server: mysqld.
Unpacking replacement mysql-server-5.0 ...
Setting up mysql-server-5.0 (5.0.32-7etch4) ...
Stopping MySQL database server: mysqld.
Starting MySQL database server: mysqld.
Checking for corrupt, not cleanly closed and upgrade needing tables..

Y ya tenemos la base de datos del sistema consistente, pero hemos perdido toda la información de usuarios y privilegios. Así que pongámonos manos a la obra para arreglarla.

Lo primero que miro antes de nada es que puedo consultar cosas en la base de datos mysql y ver qué hay en la dichosa tabla que estaba corrupta. Para mi sorpresa, ¡está vacía!:

mysql> use mysql
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
 
Database changed
mysql> show tables;
+---------------------------+
| Tables_in_mysql           |
+---------------------------+
| columns_priv              | 
| db                        | 
| func                      | 
| help_category             | 
| help_keyword              | 
| help_relation             | 
| help_topic                | 
| host                      | 
| proc                      | 
| procs_priv                | 
| tables_priv               | 
| time_zone                 | 
| time_zone_leap_second     | 
| time_zone_name            | 
| time_zone_transition      | 
| time_zone_transition_type | 
| user                      | 
+---------------------------+
17 rows in set (0.00 sec)

mysql> desc time_zone;
+------------------+------------------+------+-----+---------+----------------+
| Field            | Type             | Null | Key | Default | Extra          |
+------------------+------------------+------+-----+---------+----------------+
| Time_zone_id     | int(10) unsigned | NO   | PRI | NULL    | auto_increment | 
| Use_leap_seconds | enum('Y','N')    | NO   |     | N       |                | 
+------------------+------------------+------+-----+---------+----------------+
2 rows in set (0.01 sec)
 
mysql> select * from time_zone;
Empty set (0.00 sec)

A continuación, el siguiente paso es ponerle contraseña al usuario root:

mysql> SET PASSWORD FOR 'root'@'localhost' = PASSWORD('XXXXXX');
mysql> SET PASSWORD FOR 'root'@'nombreordenador' = PASSWORD('XXXXXX');

algo que también podría haber hecho con el comando mysqladmin:

/usr/bin/mysqladmin -u root password 'new-password'
/usr/bin/mysqladmin -u root -h nombreordenador password 'new-password'

También tengo que crear usuario para la base de datos de WordPress y darle todos los privilegios para sus bases de datos asociadas:

mysql> create user "wordpress"@"localhost" identified by 'XYZABC';                                                                                
Query OK, 0 rows affected (0.00 sec)

mysql> grant all privileges on wordpress.* to "wordpress"@"localhost";
Query OK, 0 rows affected (0.09 sec)
 
mysql> grant all privileges on wordpress_dev.* to "wordpress"@"localhost";                                                                                              
Query OK, 0 rows affected (0.01 sec)

Y, finalmente, crear el usuario de la base de datos del MythTV, tal y como muestra el mc.sql de MythTV:

GRANT ALL ON mythconverg.* TO mythtv@localhost IDENTIFIED BY "mythtv";
FLUSH PRIVILEGES;
GRANT CREATE TEMPORARY TABLES ON mythconverg.* TO mythtv@localhost IDENTIFIED BY "mythtv";
FLUSH PRIVILEGES;

¡Y ya vuelvo a tener todo arreglado!

Ahora tengo que repasar mi política de backups de MySQL, ya que aunque ha sido poco trabajo recuperar la configuración, si hubiera tenido cientos de usuarios no hubiera podido hacer esto tan alegremente. Yo hago backups frecuentes de las bases de datos individuales con mysqldump , pero no estaba guardado las tablas del sistema.

Yo normalmente guardaba un export con las opciones --add-drop-table y la --no-create-db y otro sin ella:

mysqldump -pXXXXXX --extended-insert --databases wordpress > wp_nuevadb.bak 
mysqldump -pXXXXXX --extended-insert --no-create-db --add-drop-table --databases wordpress > wp.bak

pero ahora me plantearé hacerlo con la opción --all-databases (que en realidad es la de por defecto) y/o hacer backups en frío. El mysqlhotcopy no es una opción porque yo uso InnoDB y no MyISAM.

Y para acabar, dejo la pregunta clave abierta. ¿Cómo hubierais intentado salir vosotros de esta situación sin borrar y recrear todas las tablas del sistema sino sólo recreando la tabla time_zone? Seguro que hay alguna forma de hacerlo… (Gracias por adelantado a todas las sugerencias)

:wq

Entradas relacionadas

10 Comentarios a “Corrupción en MySQL: ERROR 2006 (HY000): MySQL server has gone away”

  • RuBiCK dice:

    Muy interesante y contructivo :)

    Sin duda alguna mysql es una muy buena apuesta dado que es gratuito y bastante robusto, sin llegar a entornos corportativos, aunque le faltaría muy poquito o nada con el cluster de mysql…

  • @RuBiCK Pues sí, yo lo veo muy capacitado para muchos entornos profesionales, sin llegar, eso sí, a la categoría que puede tener Oracle, claro.

    Gracias por tu comentario :-)

  • abaca dice:

    ¡guau! ¡esto es mejor que el metalink! me lo apunto para cuando a cacharrear con el mysql

  • Oink! dice:

    ¿¡Qué dices!? ¡No sólo es mejor que el Metalink! ¡Es incluso mejor que el KMine y el Saw! ;-) (¿se llama “saw” el nuevo, no? :D )

  • @abaca, @Oink! Lo que tengo que aguantar… ;-) .

    ¡Muchas gracias por la visita!

  • evi galvez dice:

    Error
    consulta SQL:
    SHOW STORAGE ENGINES
    MySQL ha dicho:
    #2006 – MySQL server has gone away. yo instale esta version appserv-win32-2.5.7, pero al crear la base de datos en mysql m marca el error anterior y tambien este #2003 – El servidor no está respondiendo; he buscado ayuda en la web y no puedo resolver mi problema entro asi http://localhost/phpMyAdmin hasta aki todo bien el problema es cuando se crea la base de datos con las tablas.
    m puedes ayudar para ver cual es mi problema o en donde le tengo que modificar xk ya modifique en config.inc.php escribiendo la ruta de phpmyadmin y escribien el passwor del root pero aun asi no resuelvo mi problema enviame tus comentarios k de mucho me serviran

  • Alvaro Gamboa dice:

    Pana me sirvio muchisimo gracias tenia tremendo problema y ya lo solucione muchas gracias excelente

  • clean75 dice:

    Pos la verdad….

    A mi la solución me parece ultracomplicada. Si copias el time_zone de otro server que funcione ya te vale.

    Pero bueno. SI haces un drop de la table (que suele estar vacía) y un create tb te sirve. Realmente yo tube el mismo problema e hice un drop y un create y todo sin problemas…

    Lo dejo aquí para que lo probéis antes porque de esta manera no tendríais que parar el mysql …

    Un saludo

  • @clean75 Pues gracias por tus sugerencias. La verdad es que cuando me peleé con esto, no tenía mucha experiencia con MySQL y salí del problema como pude, y aquí me lo dejé apuntado para futura referencia…

  • clean75 dice:

    De nada
    Saludos

Tema LHYLE09, creado por Vicente Navarro