Rafael Peláez

Rafael Peláez

Rafa  //  My Google Profile

 
Nov 18 / 7:03am

MySQL: hacer un “snapshot” del máster

by Rafa

Antiguo y abandonado blog de Ricardo Galli :-(

Wednesday 3/10/2007

MySQL: hacer un “snapshot” del máster

Filed under: Mis hacks, Trucos — gallir @ 16:23

Es una chorrada y bien conocida, aunque a mí me costó averiguar cuál es la solución más rápida y fiable –¿soy sólo yo el lento o también ocurre lo mismo a otros?–, así que aquí va por si a alguien le sirve.

MySQL funciona muy bien para mantener réplicas (slaves) de un servidor maestro (master), pero a veces hay algunos problemas:

  1. El comando LOAD DATA FROM MASTER desde la réplica no está recomendado.

  2. La base de datos es muy grande y toma mucho tiempo hacer el “mysqldump”, es mucho más rápido hacerlo con los mysqlhotcopy que sólo copia los ficheros.

  3. Antes de hacer el mysqldump (si se hace) hay que obtener el estado del “binlog” del servidor para indicarlo en la réplica.

La mejor opción es hacer copia de los ficheros de la base de datos con el mysqlhotcopy y además indicarle que grabe en una tabla el estado del “binlog”. Con esto tendremos una copia rápida de la base de datos en “producción” que nos servirá para iniciar fácilmente una nueva réplica y/o reparar una que haya perdido el sincronismo o coherencia con el máster (suele suceder).

Para ello primero hay que crear esa tabla (está documentado en perldoc mysqlhotcopy).

CREATE TABLE log_pos (
                 host            varchar(60) NOT null,
                 time_stamp      timestamp(14) NOT NULL,
                 log_file        varchar(32) default NULL,
                 log_pos         int(11)     default NULL,
                 master_host     varchar(60) NULL,
                 master_log_file varchar(32) NULL,
                 master_log_pos  int NULL,

                 PRIMARY KEY  (host)
               );

Yo creé esa tabla en la base de datos mysql del Menéame. Así para el Menéame tengo el siguiente comando que se ejecuta cada madrugada:

mysqlhotcopy -q --flushlog --noindices --record_log_pos=mysql.log_pos  
                    --addtodest  mysql meneame /backups/hotcopy/

El comando anterior sólo tarda unos 6-10 segundos para copiar todos los datos de la base de datos, sin los índices y ocupando sólo 800 MB (el .sql comprimido si se usase mysqldump ocupa 1.5 GB).

La opción --noindices indica que no copie los índices, ellos pueden ser luego regenerados con el mysqlcheck -rq.

La opción --record-log_pos es para indicar la base de datos y tabla dónde guardar la información del log del máster, es la que servirá para sincronizar las réplicas (en este caso le indico que copie las dos base de datos, mysql y meneame).

Los ficheros de backup se copiarán a /backups/hotcopy/mysql y /backups/hotcopy/meneame. En la tabla se guardarán datos como los siguientes:

| host             | time_stamp          | log_file         | log_pos | ...
+------------------+---------------------+------------------+---------+
| db.meneame.net   | 2007-10-03 11:01:37 | mysql-bin.000634 |      98 |

Para [re] iniciar una réplica sólo hay que copiar esos ficheros a [por ejemplo] /var/lib/mysql/meneame en el servidor correspondiente y:

  1. Detener el slave si está en marcha:

    slave stop;

  2. Mejor es detener también el mysql.

  3. Regenerar los índices con

    mysqlcheck -qr /var/lib/mysql/meneame/*.MYI

  4. Poner el propietario adecuado: para Debian,

    chown -R mysql.mysql /var/lib/mysql/meneame

    también es mejor poner los permisos adecuados:

    chmod 0660 /var/lib/mysql/meneame/*

  5. Arrancar el mysql e indicar el estado del máster (uso el ejemplo anterior):

    CHANGE MASTER TO MASTER_HOST='tu.master.com', MASTER_USER='tu_usuario', MASTER_PASSWORD='tu_password', MASTER_LOG_FILE='mysql-bin.000634', MASTER_LOG_POS=98;

  6. Arrancar el slave:

    SLAVE START

Ya está, con el comando sql show slave status deberías ver como se sincroniza.

Creo que esta opción es la mejor porque además que la copia es rápida, si la haces cada día tienes siempre una “imagen” lista para ser usada para recuperar o iniciar cualquier otro slave sin necesidad de detener la base de datos en producción.

Nota: si harás réplicas de un máster tendrás que habilitar la “conexión a la red”, así que no te olvides de poner las iptables, definir qué direcciones IP pueden conectarse al puerto del mysql y poner claves a los usuarios habilitados para replicar. Sino podrías tener una importante fuga de datos ;-)

-->

15 Comments

  1. Interesante, esta es una de esas tareas que tienen mil caminos para llegar a la misma solución. Esta es “bonita”, yo soy mas bruto y tiro más de tar :)

    Comment by Bor — Wednesday 3/10/2007 @ 17:28

  2. Yo como el comentario anterior también tiro de tar para crear las replicaciones, principalmente porque mysqlhotcopy no soporta tablas innodb qué son las que yo utilizo. Además para no tener que detener el master, creo los slaves a partir de un slave ya configurado.

    Lo que no entiendo es para que quieres hacer una imagen de la base de datos todos los días si ya tienes 2 o 3 servidores esclavos preparados para sustituir al master en cualquier momento.

    Comment by Borja — Wednesday 3/10/2007 @ 18:25

  3. Debe ser que los borjas somos muy brutos, exactamente lo mismo, tar de otra replica, scp y edicion de archivos para ajustarlos al nuevo hostname. :)

    Comment by Bor — Wednesday 3/10/2007 @ 20:34

  4. #1, #2, #3, ¿pero sóis cuidadosos de hacer el lock de lectura, y el “flush” de las tablas antes de hacer el tar o la copia? (el mysqlhotcopy hace todo eso).

    Comment by gallir — Wednesday 3/10/2007 @ 20:41

  5. Parando el mysql no hay problema:)

    En respuesta a #2, a pesar de tener varias replicas, viene bien hacer un dump, o hotcopy o lo que sea, yo saco una copia todos los dias del datacenter, hay que pensar en el peor de los casos y no vaya a ser que explote el centro de datos :)

    Comment by Bor — Wednesday 3/10/2007 @ 20:49

  6. > Parando el mysql no hay problema:)

    Ya, pero te imaginas parar así un sistema en producción. En el menéame me mandarían a la mierda enseguida y se escribiría en blogs que el sistema peta (como debería :roll: ).

    Comment by gallir — Wednesday 3/10/2007 @ 21:04

  7. Hombre! Pues claro, implementa un balanceo de querys como dios manda y problema resuelto :)
    Realmente tenemos una replica que no es consultada desde producción que es la que usamos para esto.

    Comment by Bor — Wednesday 3/10/2007 @ 21:12

  8. > Hombre! Pues claro, implementa un balanceo de querys como dios manda y problema resuelto :)

    Pero tenemos un sólo servidor para todo (mysql+apache/php), y espero que dure. La administración de diferentes servidores no me divierte demasiado, si es KISS extremo, pero me gusta más :-)

    Comment by gallir — Wednesday 3/10/2007 @ 21:22

  9. #5 En mi caso los servidores están distribuidos en diferentes zonas geográficas, de ahí que no viera la utilidad del dump :)

    #8 ¿Tienes dos servidores MySql en el mismo servidor?
    Es una solución que me he planteado en alguna ocasión para hacer un balanceo de carga y tener mayor tolerancia a errores en casos de recursos limitados, ¿funciona bien? ¿mejora el rendimiento?

    Aprovecho para recomendar un blog qué he descubierto hace poco http://www.mysqlperformanceblog.com/

    Comment by Borja — Wednesday 3/10/2007 @ 22:52

  10. > ¿Tienes dos servidores MySql en el mismo servidor?

    No, qué va. Tenemos otro servidor, en otro lugar, haciendo de réplica por si ocurre algún desastre en el proveedor actual. Además la usamos para hacer las consultas más complejas que bloquearían al principal (por el lock a toda las tablas que aplica el MyISAM).

    Sobre el mysqlperfomanceblog.com, lo sigo desde casi sus inicios. Los tíos son unos cracks (al menos uno de ellos trabajaba en mysql.com).

    Comment by gallir — Wednesday 3/10/2007 @ 22:58

  11. Para hacer un mysqldump cuando no se puede usar hotcopy (innodb) yo uso un servidor slave, paro (slave stop) y hago el dump. Para asegurar que ambos servidores están bien sincronizados existe mysqltoolkit. Bueno, la verdad es que las copias fuera del datacenter las hago así.

    No me digáis que no es seguro eso, que me da algo :)

    Comment by Fernando Serer — Thursday 4/10/2007 @ 9:36

  12. Ya que comentaris de buenos blogs sobre mysql, tb conozco ese desde los principios, hay otro que es tb genial, el del xaprb.
    http://www.xaprb.com/blog/
    Para vosotros que usais replicación tienen especial interes unos scripts con los que comprobar feacientemente que los datos de las replicas son identicos a los del master(via checksum), vamos, que un admin no se ha equivocado y se la liado a tirar updates ahi a lo tonto :) Tiene bastantes utilidades curiosas y muy utiles.

    Comment by Bor — Thursday 4/10/2007 @ 9:40

  13. Y alguien lo ha probado vía drbd, si funciona correctamente?

    Comment by KaMpA — Friday 5/10/2007 @ 18:23

  14. La verdad que es el mejor metodo para hacer backups en mysql, via slave.

    Utilizando innodb no hace falta regenerar los indices porque por si mismo los genera la lanzar el servidor, ademas aporta bloqueo por columna y esto facilita a la hora de hacer el dump. Aunque quiza sea más lento de acceso, ¿porque una solucion mixta de engines en tablas?

    Tambien, utlimamente en el planet de mysql (www.planetmysql.com) se ha estado hablando de mysqlpdump ( http://www.fr3nd.net/projects/mysqlpdump/ ) y conociendo la programador no tengo ninguna duda que tiene muy buena pinta.

    Comment by dani — Friday 5/10/2007 @ 23:42

  15. Yo para “replicar” los datos lo que suelo hacer es “on-the-fly” enviar un tar.gz de todo (es decir, código + caché -esto viene a ser importante, sin los modulos cache puedo tirarme unas dos horitas más para poner todo arriba- + mysql). Lo que si es que miedo me da como algo pete :-)

    Comment by xeon — Saturday 6/10/2007 @ 19:40

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

Powered by WordPress

via mnm.uib.es