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
RuBiCK dijo:
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…
Super Coco dijo:
@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 dijo:
¡guau! ¡esto es mejor que el metalink! me lo apunto para cuando a cacharrear con el mysql
Oink! dijo:
¿¡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)
Super Coco dijo:
@abaca, @Oink! Lo que tengo que aguantar…
.
¡Muchas gracias por la visita!
evi galvez dijo:
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 dijo:
Pana me sirvio muchisimo gracias tenia tremendo problema y ya lo solucione muchas gracias excelente
clean75 dijo:
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
Super Coco dijo:
@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 dijo:
De nada
Saludos