Mucha gente cree erroneamente que gracias a la opción innodb-file-per-table te permite, como MyISAM, portar una tabla en binario de un servidor a otro de forma transparente o recuperar el backup de una tabla. El problema viene cuando realmente necesitan hacer uso de ese backup y no funciona como ellos esperaban.

Al contrario que con MyISAM, donde los ficheros de tablas MYD e MYI son independientes del resto y portables, todas las tablas de InnoDB dependen de un tablespace común donde se almacenan las definiciones de las tablas y además depende de los IDs de transacciones entre otras cosas. Por lo que, si restauras un .idb, no recuperarás los datos.

Todo esto se aplica a la versión original de MySQL, la desarrollada por Oracle. Pero Xtrabackup y Percona Server nos permite esquivar esta limitación y trabajar con los ficheros binarios como si se tratasen de tablas MyISAM, moviéndolas y restaurándolas de un servidor a otro. …

Cuando tienes un entorno activo-pasivo o montas un esclavo para las lecturas, el mayor problema que te puedes encontrar al poner los nuevos servidores en producción es que las cachés se encuentren frias (cold cache). Como dichos servidores no han recibido consultas, todas sus cachés, como query cache o innodb_buffer_pool se encuentran vacias y todas las consultas tendrán que ir a disco duro durante los primeros minutos u horas. En esos primeros instantes, el rendimiento de tu backend será pésimo.

Hasta ahora, para evitar en la medida de lo posible ese problema, se lanzaban SELECT contra las tablas que obligasen a leerse todas las filas. Eran consultas muy pesadas que tardaban mucho tiempo en ejecutarse y ralentizaban aún más el rendimiento, pero... no había otra solución. Un ejemplo de está solución se puede leer en el blog de Santi Saez …

Ahora mismo, todos los servidores que compramos son multi-core o multi-cpu. MySQL ha ido solucionando sus problemas de escalabilidad, sobre todo a nivel del engine InnoDB, y la diferencia es clara entre MySQL 5.0 y MySQL 5.5, donde el rendimiento en entornos multicore es cada vez mayor. Pero aún queda un punto por mejorar, la replicación de MySQL.

En una replicación MySQL Master/Slave el problema se puede ver claramente. Mientras que en el maestro puedes tener cientos de threads modificando datos en paralelo, estos se escriben de forma ordenada en el binlog mientras que el slave, que solo tiene un thread para aplicar los cambios (SQL Thread), tiene que escribir los cambios uno a uno. De esta forma, el rendimiento que ganamos con la paralelización de las consultas, se pierden al llegar al Slave. Razón por la cual en entornos de alta carga siempre vemos que el esclavo va muy por detrás del Master aplicando los cambios (Seconds Behind …

Si estamos intentando exportar en MySQL una base de datos de gran volúmen, o una base de datos no muy voluminosa, pero con una tabla muy grande en un servidor limitado en cuanto a memoria, es muy probable que nos acabemos por encontrar el siguiente error:

mysqldump: Error 2013: Lost connection to MySQL server during query when dumping table

Este problema se produce porque MySQL carga por defecto la tabla completa antes de exportarla (si es un export de una base de datos completa, lo hace tabla a tabla), y en ocasiones la memoria disponible en el servidor no es suficiente.

La solución es muy simple, es utilizar la opción --quick o -q para que MySQL exporte fila a fila en lugar de meter en buffer toda la tabla y agotar la memoria. Ver documentación.

Ejemplo:

 …

Si estamos intentando exportar en MySQL una base de datos de gran volúmen, o una base de datos no muy voluminosa, pero con una tabla muy grande en un servidor limitado en cuanto a memoria, es muy probable que nos acabemos por encontrar el siguiente error:

mysqldump: Error 2013: Lost connection to MySQL server during query when dumping table

Este problema se produce porque MySQL carga por defecto la tabla completa antes de exportarla (si es un export de una base de datos completa, lo hace tabla a tabla), y en ocasiones la memoria disponible en el servidor no es suficiente.

La solución es muy simple, es utilizar la opción --quick o -q para que MySQL exporte fila a fila en lugar de meter en buffer toda la tabla y agotar la memoria. Ver documentación.

Ejemplo:

 …

En ocasiones es necesario hacer un análisis de que está pasando en un servidor con MySQL, comprobar que queries se están ejecutando, cuanto tardan, donde están los cuellos de botella, etc. Hay diferentes formas de hacerlos:

• A lo pobre: ejecutar SHOW FULL PROCESSLIST cada pocos segundos, identificar a ojo las querys que pueden ser interesantes y luego analizarlas.
• A lo basto: habilitar el log general de MySQL y almacenar todas las querys que se ejecutan. Te llevarás una gran cantidad de IOPS y puede que el fichero termine siendo tan grande que analizarlo sea un infierno.

Como casi siempre, las maatkit vienen a ayudarnos en esta tarea. En esta ocasión, mk-query-digest nos va a permitir analizar la ejecución de querys y generarnos un reporte. Esta utilidad es capaz de coger datos de los logs, pero aquí vamos a utilizar un parámetro que nos …

Las replicaciones necesitan de un chequeo constante en la integridad de los datos. Fallos de disco, corrupción de de logs, mezcla de tablas transaccionales y no transaccionales y otros problemas pueden tumbar la consistencia de nuestros datos. Por lo tanto, podemos tener una replicación funcionando, pero los datos, si no hay una comprobación activa, pueden ser diferentes en las dos máquinas. MySQL no tiene comprobaciones activas de consistencia, por lo que es trabajo nuestro. Para ello, instalamos las herramientas maatkit de Percona:

apt-get install maatkit

Las herramientras que usaremos serán mk-table-checksum y mk-table-sync. El funcionamiento de la herramienta se basa en la replicación en base a sentencias de mysql. mk-table-checksum realiza una comprobación mediante un algoritmo de hashing en las tablas, escribiendo los resultados en la base de datos. Estas sentencias se replicarán en el esclavo y se volverán a …

No es muy común ver que el optimizador del MySQL se equivoque estrepitosamente de plan de ejecución, pero cuando lo hace los resultados pueden ser desastrosos. Por ejemplo, para una JOIN como la siguiente: SELECT ul.id, ul.name, s.body FROM mails as s JOIN users as ul ON s.u_id=ul.id WHERE s.domain_id = 25 ORDER BY mail_id [...]

Just a quick tip:

File: gistfile1.rb
——————

desc "Rake task with arguments and :environment"
task :task_name, [:arg1, :arg2] => :environment do |t, args|
args.with_defaults(:arg1 => "Foo", :arg2 => "Bar")
puts "Hello, #{args.arg1}. Bye, #{args.arg2}."
end

Notes:

• You may omit the #with_defaults call.
• You have to use an Array for your arguments, even if there is only one.

So you will be able to pass arguments to your rake task:

File: gistfile1.txt
——————-

$ rake task_name["Moon","Sun"]
Hello, Moon. Bye, Sun.

Cuando el número de servidores que administras es pequeño, realizar tareas sobre estos no supone un gran problema. Pero cuando se empieza a superar el número de pestañas que entran en el terminal, empiezas a tener un problema. El uso de una administración centralizada te permite tener el control total de las configuraciones, paquetes y servicios que hay en cada servidor desde un punto central, aliviando así la carga de trabajo y manteniendo un entorno lo más homogéneo posible.

Para llevar a cabo esta tarea existen múltiples soluciones en el mundo del Software Libre. Estas semanas he dedicado parte de mi tiempo libre a rellenar esta laguna de conocimientos que tenía como sysadmin y el elegido ha sido Puppet.

Puppet es una herramienta de gestión centralizada de servidores, basado en Ruby y con un lenguaje declarativo muy parecido a este. Existen múltiples módulos para gestionar servicios como Apache, nginx, Postfix, Cron, …