Instalando MySQL 5.6 me encontré con el siguiente error:

# /usr/local/mysql/scripts/mysql_install_db --user=mysql --datadir=/var/mysql
FATAL ERROR: Could not find my-default.cnf

If you compiled from source, you need to run 'make install' to
copy the software into the correct location ready for operation.

If you are using a binary release, you must either be at the top
level of the extracted archive, or pass the --basedir option
pointing to that location.

Si hacemos un strace al proceso podemos ver:

stat64("./bin/my_print_defaults", 0x93500c4) = -1 ENOENT (No such file or directory)

Por lo tanto, lo que le pasa es que no esta encontrando binarios que necesita para la ejecución del script. Para solucionarlo simplemente deberemos indicar dónde esta instalado el MySQL mediante la …

En bases de datos MySQL con mucha actividad o que tratan con datos muy grandes sobre tablas InnoDB nos podemos encontrar con mensajes simulares a:

110221  1:28:31  InnoDB: ERROR: the age of the last checkpoint is 9433961,
InnoDB: which exceeds the log group capacity 9433498.
InnoDB: If you are using big BLOB or TEXT rows, you must set the
InnoDB: combined size of log files at least 10 times bigger than the
InnoDB: largest such row.

El mensaje se refiere el redo log, son los ficheros llamados ib_logfile0 y ib_logfile1 que podemos encontrar en el datadir del MySQL. En estos ficheros se almacenan los cambios sobre tablas InnoDB para que, en caso de un crash de MySQL se ejecuten para completar las transacciones.

La variable que controla el tamaño de dichos ficheros es innodb_log_file_size, …

Originally posted: http://anothermysqldba.blogspot.com/2014/01/hard-work-that-goes-unnoticed.html

Me tomé un momento hoy y ser informado uno de mis distribuciones de Linux. En esta distribución resulta que tengo Percona 5.6 instalado como la base de datos MySQL. He mencionado antes cómo puede configurar su elección de MySQL a través de un repositorio Yum .

Mi punto aquí es, sin embargo, ¿cómo alguna vez las gracias a estas personas por todo el trabajo que hacen?

Muchos de estos repositorios están a cargo de las …

Original post: http://anothermysqldba.blogspot.com/2014/01/a-mysql-dba-looks-at-postgresql-part3.html

Así que recientemente he publicado: Un DBA MySQL mira PostgreSQL y parte 2: MySQL a PostgreSQL .

Este post va a explorar la migración …

Original post: http://anothermysqldba.blogspot.com/2014/01/a-mysql-dba-looks-at-postgresql-part2.html

Así que recientemente he publicado: Un DBA MySQL mira PostgreSQL

Este post va a explorar la migración de MySQL a  …

Original post: http://anothermysqldba.blogspot.com/2013/12/a-mysql-dba-looks-at-postgresql.html

Así que este es un viaje del / a MySQL DBA mirar en PostgreSQL . No es un ataque sólo observaciones y ejemplos. 

El uso de  …

Allá por Septiembre 2013 ya os conté mis problemas con MySQL 5.7.2 y mi imposibilidad de instalarlo debido a que me saltaba el error 1053. Aunque invertí mucho tiempo en intentar resolver el problema, no lo conseguí, y dejé pasar el tiempo. Hace unas semanas un amigo me pidió un instalable de MySQL, y le …

Continuar leyendo »

The post Solución al error 1053 de #MySQL 5.7.2 appeared first on Manejando datos.

MySQL provee muchos tipos de logs. Tenemos el log binario, el log general y el log de queries lentas. Son muy útiles y necesarios tanto para analizar un problema o montar una replicación pero hay que tener cuidado con el tamaño que pueden llegar a alcanzar. Para los logs binarios existe una serie de parámetros que nos permite limitar su tamaño e ir rotándolos eliminando los antiguos, cosa que no hay para los otros dos tipos de log.

Un cliente me contactó porque al desactivar el log general MySQL se quedaba parado durante varios minutos no aceptando más consultas y causando por lo tanto caída del servicio. Lo primero que te viene a la cabeza es... "¿Cómo cojones desactivar un log puede tirar un servidor abajo?" ?

Las razones son dos principalmente:

1- Debido a la forma en la que MySQL cierra el fichero.
2- Por el rendimiento del almacenamiento.

Para entender mejor el primer punto debemos analizar …

Actualizando un MySQL de la versión 5.1 a la versión 5.5 empezaron a salir errores como el siguiente:

InnoDB: Warning: a long semaphore wait:
--Thread 139816751400704 has waited at trx0trx.c line 754 for 241.00 seconds the semaphore:
Mutex at 0x1770d48 created file srv0srv.c line 1024, lock var 1
waiters flag 1

Causando que se queden colgadas las queries y por lo tanto colapsando el servidor MySQL.

La única forma de recuperar el MySQL era matando el proceso. Buscando el problema, encontré en los foros de MySQL que mediante la opción –skip-innodb_adaptive_hash_index se soluciona, pero no hay feedback al respecto. Aparentemente, dejando ya más de un mes de margen parece que efectivamente ha solucionado el problema.

Tags: …

Original post: http://anothermysqldba.blogspot.com/2013/11/a-strategy-from-community.html

Hemos visto las noticias sobre MariaDB reemplazar MySQL en Fedora, SUSE y Red Hat.

Mientras que Oracle no estaría contento con este tipo de noticias, la comunidad de código abierto compatible con el enfoque en una solución de código "más" abierta a ser implementado en Linux.

Lo interesante que todos podamos sobre el aspecto es que, la decisión o estrategia para pasar a MariaDB de MySQL fue probable es que no acaba de hacer por la alta dirección en Red Hat. Esto es mucho más probable que sea un movimiento de la comunidad de código abierto de Red Hat que evalúa y escucharon.

Considere esto, echar un vistazo atrás en casa de Jackie Yeaney ( …