Toda migración acaba obteniendo una cierta complejidad si queremos minimizar el tiempo de corte y poder garantizar haya una “vuelta atrás” en caso de problemas. Vamos a ver una forma de migrar un MySQL master de un disco de una cabina a otro disco de otra cabina minimizando el tiempo de corte gracias a un slave que transformamos en master y volvemos a transformar en slave.

Suponiendo que tenemos un MySQL con un slave y queremos migrar de un disco en una cabina antigua a otro disco de una cabina nueva: Mientras se traspasan los datos podemos usar el slave como master y cuando acabe podemos sincronizar los dos MySQL y volver a dejar el MySQL con su rol habitual.

La hora de ruta sería la siguiente:

Previo a la intervención:

• Apagar procesos batch …

Un MySQL puede estar compilado para soportar varios STORAGE ENGINES, vamos a ver de los que disponemos y sus características:

El comando para ver el tipo de tablas que podemos usar en el MySQL es con SHOW STORAGE ENGINES o SHOW ENGINES:

mysql> show engines;
+------------+---------+----------------------------------------------------------------+--------------+------+------------+
| Engine     | Support | Comment                                                        | Transactions | XA   | Savepoints |
+------------+---------+----------------------------------------------------------------+--------------+------+------------+
| ndbcluster | YES     | Clustered, fault-tolerant tables                               | YES          | NO   | NO         |
| MRG_MYISAM | YES     | Collection of identical MyISAM tables                          | NO           | NO   | NO …

En ciertas bases de datos dónde el tiempo de recuperación de una tabla es crítico podemos mantener un conjunto de snapshots online (penalizando el rendimiento del disco) con el fin de disponer de puntos de recuperación muy cercanos al estado actual. Vamos a ver como configurarlo usando mylvmbackup

Primero lo descargamos:

cd /usr/local/src
wget http://www.lenzg.net/mylvmbackup/mylvmbackup-0.13.tar.gz
tar xzf mylvmbackup-0.13.tar.gz 

E instalamos normalmente:

cd mylvmbackup-0.13
make prefix=/usr/local/ install

A continuación deberemos indicar en el fichero de configuración (/etc/mylvmbackup.conf) los datos para acceder al MySQL:

[mysql]
user=root
password=passwdroot
host=localhost
port=3306
socket=/tmp/mysql.sock
mycnf=/etc/my.cnf

En la secciones siguientes definimos el LVM que contiene el datadir del …

Al ver que un site se queda frito durante un minuto pero cuando entramos ya no queda ningún thread en el MySQL debemos investigar los logs.

Si no existen errores en el log del daemon, para investigar el site bloqueado podemos ver que hay en el log de slow queries. Suponiendo el siguiente:

(...)
# Time: 120228 21:00:04
# User@Host: systemadmin[systemadmin] @ localhost []
# Query_time: 1.459100  Lock_time: 0.000034 Rows_sent: 0  Rows_examined: 0
SET timestamp=1330441204;
REPLACE INTO `sesiones` VALUES('ffff21568da68d024dead5b49b680000', '1234', '');
# User@Host: systemadmin[systemadmin] @ localhost []
# Query_time: 1.385580  Lock_time: 0.000032 Rows_sent: 0  Rows_examined: 0
SET timestamp=1330441204;
REPLACE INTO `sesiones` VALUES('fffffb70a60660f3d7deade5ca8d0000', '4321', '');
# Time: 120228 21:00:59
# User@Host: systemadmin[systemadmin] @ localhost []
# Query_time: …

Tal y como podemos encontrar en el manual del MySQL, el uso de LIMIT en queries que modifican tablas es inseguro en modo STATEMENT (por defecto). Si lo hacemos nos encontraremos en el log mensajes similares a:

120123 19:06:01 [Warning] Unsafe statement written to the binary log using statement format since BINLOG_FORMAT = STATEMENT. The statement is unsafe because it uses a LIMIT clause. This is unsafe because the set of rows included cannot be predicted. Statement: DELETE FROM casas
                WHERE DATEDIFF(NOW(), casa_date) > 31 limit 1000

Esto se debe a que aunque existan los mismos registros:

master> select * from fib;
+------+-------+
| id   | valor |
+------+-------+
|    6 |     8 |
|    7 |    13 |
|    8 |    21 |
|    9 |    34 |
+------+-------+
4 rows in set …

Mediante SHOW OPEN TABLES podemos ver las tablas que están actualmente abiertas en la table cache y si esta en uso o si tiene threads a la espera a que otro libere el bloqueo.

Si ejecutamos simplemente SHOW OPEN TABLES veremos por todas las bases de datos las tablas que están abiertas y si están en uso mediante la columna In_use:

mysql> show open tables;
+-------------+--------------------------------------------------------+--------+-------------+
| Database    | Table                                                  | In_use | Name_locked |
+-------------+--------------------------------------------------------+--------+-------------+
| xxxxxx_utf8 | tmp_systemadmin.es                                     |      0 |           0 |
(...)

La columna Name_locked se usa para ciertas operaciones como los DROPs. Para ver las …

Vamos a ver como instalar MySQL Cluster y sus características. No se trata de una solución de alta disponibilidad para el típico MySQL (con tablas MyISAM o InnoDB) sino que se trata de un storage engine transaccional con sus propias características: ndb

El MySQL Cluster ndb ofrece una base de datos sin nada compartido con tres tipos de nodos diferenciados:

• Nodo de gestión (ndb_mgmd): Permite la gestión del resto de nodos del cluster, arrancar y apagar nodos o hacer backups. Aunque se deba arrancar el primero puede fallar sin afectar al funcionamiento del cluster.
• Nodo de datos (ndbd o ndbmtd): Almacena los datos los trata
• Nodo SQL: Nodo a través del cual …

He visto algunas formas de hacer snapshots de MySQL que no deben hacerse así. Vamos a ver un ejemplo.

Me han pasado scripts como el siguiente:

/usr/sbin/xfs_freeze -f /var/mysql
/usr/bin/ec2-create-snapshot -K $KEY -C $CERT vol-1111ff11 --description "SnapMysql"
/usr/sbin/xfs_freeze -u /var/mysql

En este caso se hace un snapshot de un EBS habiendo congelado previamente el sistema de ficheros, en este caso xfs. Si bien el snapshot tendrá los datos consistentes del sistema de ficheros, los datos que tenga el MySQL en memoria se perderán. Para hacer backups mediante snapshots de MySQL con XFS lo podemos hacer mediante mylvmbackup.

En el caso que sea xfs deberemos indicar que es dicho sistema de ficheros mediante xfs=1: …

Mediante SHOW INNODB STATUS podemos obtener ver los contadores de InnoDB, valores varios, estadísticas y las transacciones. Algunos de dichos valores nos puede interesar guardar un histórico para hacer un gráfico o ver su evolución. Mediante la opción innodb-status-file podemos simplificar el script de optención de datos.

Mediante la opción –innodb-status-file indicamos al MySQL que escriba en el datadir el estado de InnoDB. El fichero en cuestión se llamará innodb_status.<PID%gt; por lo que el script deberá buscar primero el PID del mysqld para poder encontrar el fichero.

De esta forma nos ahorramos tener que acceder al MySQL para hacer un SHOW INNODB STATUS y varios …

Al ejecutar una query en un MySQL contra una tabla con el engine InnoDB nos podemos encontrar con el error:

ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

La variable innodb_lock_wait_timeout permite definir el tiempo va a esperar una query a obterner un lock, por lo que podemos minimizar este error aumentando este timeout a costa de asumir que las queries pueden tener esta tiempo el thread bloqueado a la espera. Dependiendo del entorno quizá nos interesa incluso bajarlo para evitar que las queries se queden esperando (por ejemplo en entorno web). Vamos a ver como investigar este problema viendo las transacciones implicadas en un problema de este tipo.

Primero vamos a ver como ver las transacciones de InnoDB. Para ello primero vamos a desactivar el …