Posts Tagged ‘maestro esclavo

31
Ene
09

Temporary tables y replicación a esclavos

El título de esta entrada debería ser más bien «Cómo perder tus servidores esclavos haciendo el tonto» y ahora veremos porqué.

Supongamos que estamos haciendo tareas de mantenimiento en la base de datos, supongamos que tenemos que hacer un UPDATE sobre algunas filas de determinada tabla (area mismo). Con la particularidad de que determinar sobre qué filas tenemos que hacer el UPDATE no lo podemos hacer con una única query y decidimos hacer uso de las temporary tables o tablas temporales de MySQL. Las tablas temporales son tablas MyISAM que sólo perduran durante sesión en la que estamos conectados (si nos desconectamos y conectamos de nuevo, hemos perdido la tabla), lo que las hace especialmente útiles para estas tareas de mantenimiento.

Así que creamos la tabla:

mysql> CREATE TEMPORARY TABLE idsChungos (id integer primary key);
Query OK, 0 rows affected (0.00 sec)
mysql>

Y ahora vamos insertando los ids de las filas que queremos tocar:

mysql> INSERT INTO idsChungos VALUES (SELECT id FROM area WHERE …);

mysql> INSERT INTO idsChungos VALUES (SELECT id FROM area WHERE …);

mysql> INSERT INTO idsChungos VALUES (SELECT id FROM area WHERE …);

Justo en este ejemplo no se ve la necesidad de utilizar una tabla para almacenar los ids, pero no podemos usar una subquery sobre la misma tabla sobre la que vamos a hacer el UPDATE (aplica también para DELETEs).

Y ahora que ya tenemos los ids:

mysql> UPDATE area SET boundaries = NULL WHERE id IN (SELECT id FROM idsChungos);
Query OK, 7263475 rows affected (0.00 sec)
mysql>

Y nos ha ido todo a la perfección, salvo porque 30 segundos después empiezan a saltar las alarmas de servidores MySQL esclavos perdidos. En ese momento es cuando dices: aaaahhhhh y te pegas una palmadita en la frente: las tablas temporales NO se replican a los servidores esclavos. Cuando el esclavo intenta hacer el último UPDATE dice: «la tabla area no sé ni lo que es» y se para la replicación. Pensándolo dos minutos, tiene todo el sentido del mundo.

Un diez oye, pero había que aprenderlo de alguna manera. Menos mal que podemos recuperar los esclavos en caliente.

Anuncios
07
Oct
08

Recuperando un servidor esclavo de MySQL en caliente

A veces, shit happens… lo sabemos todos. Y pasa en todos los lados y en el momento más inoportuno. Hoy he descubierto que podía recuperar un esclavo de MySQL en caliente porque utilizamos un engine transaccional (InnoDB).

maestro$ mysqldump --single-transaction --databases db1 db2 --master-data=1 -u root -R -p > /tmp/dump.sql

scp de rigor a la máquina destino, stop slave, carga, start slave:

maestro$ scp /tmp/dump.sql esclavo:/tmp
esclavo$ echo “stop slave;” | mysql -u root -p
Enter password:
esclavo$ mysql -u root -p < /tmp/dump
esclavo$ echo “start slave;” | mysql -u root -p

La iluminación ha venido por parte de High Performance MySQL: Optimization, Backups, Replication, and More, un hayquetener donde los haya y libro que recomiendo prácticamente a cualquiera que se tenga que pelear con este servidor de base de datos.

En el libro, además, usan pipes:

maestro$ mysqldump --single-transaction --databases db1 db2 --master-data=1 -u root -R -p | mysql -u root -h esclavo -p