Original post: http://anothermysqldba.blogspot.com/2014/01/can-mysql-replication-catch-up.html
Así que la replicación se ha mejorado recientemente en MySQL 5.6.
Sin embargo, la gente sigue utilizando 5.1 y 5.5 por lo que
algunas de estas mejoras tendrán que esperar para golpear el
mundo real.
Recientemente ayudé a paso en esta dirección con una solución de
replicación de geo-localizada. Una parte del país tenía un
servidor MySQL 5.1 y la otra parte del país tuvo un nuevo
servidor MySQL 5.6 instalado.
Después de lidiar con los problemas de obtener la copia de
seguridad inicial de los datos desde el primario al servidor
secundario (tardó varias horas para decir lo menos), tuve que
decidir podría replicación ponerse al día y mantener el ritmo. El
servidor principal tenía …
Vamos a ver cómo instalar MySQL 5.6 desde código
fuente en CentOS 6 y con
upstart, deshabilitando storage engines
que son poco usados
También están disponibles las instalaciones de MySQL 5.1 en CentOS 5 y de MySQL 5.5 en CentOS 5 y tambien MySQL 5.5 en CentOS 6.
Descargamos el código en /usr/local/src y descomprimimos:
mkdir -p /usr/local/src cd /usr/local/src wget wget http://dev.mysql.com/get/Downloads/MySQL-5.6/mysql-5.6.15.tar.gz tar xzf mysql-5.6.15.tar.gz cd mysql-5.6.15
A continuación podemos aplicar el …
[Lea más]En el caso un MySQL llegue a max_connections, da el error “Too many connections” a todas las nuevas conexiones de usuario. Pero en el caso que se conecte un usuario con el privilegio SUPER, permite una conexión extra.
Dicha conexión extra puede quedar muy fácilmente ocupada por algún script que se conecta al MySQL con dicho privilegio o otro miembro del equipo de administradores. Por lo tanto, resulta útil que pueda ser configurable, por lo que he hecho un patch para ello.
En el código fuente de MySQL podemos ver que el código que necesitamos modificar es el siguiente:
(...) if (connection_count >= max_connections + 1 || …[Lea más]
Al actualizar a MySQL 5.6 veremos que nos aparecerá el siguiente WARNING en el log de MySQL:
[Warning] TIMESTAMP with implicit DEFAULT value is deprecated
Tal y como podemos ver en la documentación de actualizar a MySQL 5.6, se modifica el comportamiento del tipo de datos TIMESTAMP. De momento se mantiene el comportamiento por defecto con el WARNING, pero en la siguiente versión va a desparecer dicho comportamiento. Para quitar el WARNING deberemos añadir la opción explicit_defaults_for_timestamp en el my.cnf.
Mediante dicha opción habilitaremos el nuevo comportamiento de TIMESTAMP
Tags: MySQL
…
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 …
[Lea más]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, …
[Lea más]
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 …