MySQL: hacer un “snapshot” del máster
Antiguo y abandonado blog de Ricardo Galli :-(
Wednesday 3/10/2007
MySQL: hacer un “snapshot” del máster
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:
El comando
LOAD DATA FROM MASTERdesde la réplica no está recomendado.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.
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
mysqlhotcopyy 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
--noindicesindica que no copie los índices, ellos pueden ser luego regenerados con elmysqlcheck -rq.La opción
--record-log_poses 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/mysqly/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/meneameen el servidor correspondiente y:
Detener el
slavesi está en marcha:
slave stop;Mejor es detener también el mysql.
Regenerar los índices con
mysqlcheck -qr /var/lib/mysql/meneame/*.MYIPoner el propietario adecuado: para Debian,
chown -R mysql.mysql /var/lib/mysql/meneametambién es mejor poner los permisos adecuados:
chmod 0660 /var/lib/mysql/meneame/*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;Arrancar el slave:
SLAVE STARTYa está, con el comando sql
show slave statusdeberí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
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
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
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
#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
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
> 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
).
Comment by gallir — Wednesday 3/10/2007 @ 21:04
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
> 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
#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
> ¿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
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
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 tontoComment by Bor — Thursday 4/10/2007 @ 9:40
Y alguien lo ha probado vía drbd, si funciona correctamente?
Comment by KaMpA — Friday 5/10/2007 @ 18:23
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
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.
- Meta:
Powered by WordPress
