A partir del mysql 5, es posible replicar servidores de bases de datos MySql, algo que no mucha gente usa por el hecho que no siempre se dispone del acceso a la administración de más de un servidor.
Esta serie de posts tiene como objetivos:
1) Dar a conocer esta extraordinaria funcionalidad de MySql
2) Comentar mi experiencia en un proyecto que utiliza 5 servidores de mysql replicados en diferentes ubicaciones geográficas.
3) Retomar este tipo de post didáctico que hace mucho abandoné por falta de tiempo.
Ver primero la parte 1: “Introducción a la replicación“
O ver la parte 2: “Caso práctico de replicación de bases de datos”
Soluciones a los problemas comunes de la replicación
Como ya les habÃa comentado en los post anteriores de esta serie, el proyecto en el que trabajo utiliza 5 servidores de MySql replicados. Dos de esos servidores se encuentran alojados en Argentina y tres en Estados Unidos.
La replicación entre ellos es constante y caudalosa, sin embargo ésta suele fallar por diferentes motivos inherentes a los datos y a la estructura de ls bases de datos.
A continuación listaré un conjunto de fallas comunes que suelen tener las replicaciones y sus respectivas soluciones que hemos probado con éxito.
Por lo general, para corroborar el estado de una replicación, conviene realizar un chequeo en el servidor esclavo con el siguiente comando en la consola mysql:
SHOW SLAVE STATUS \G;
Esta acción mostrará un listado de parámetros que nos indican en que estado se encuentra la replicación; a continuación les comentaré brevemente los más importantes e indicativos de posibles problemas.
Slave_IO_State: Indica el estado del esclavo
Master_Log_File: Indica el archivo del del master que esta siendo leÃdo
Read_Master_Log_Pos: Indica la ultima posición que el esclavo ya leyó del master
Relay_Log_File: Indica el archivo de log propio que el esclavo esta executando
Relay_Log_Pos: Indica la posición del log propio que el esclavo esta ejecutando
Relay_Master_Log_File: Indica el log del master que el esclavo esta ejecutando
Slave_IO_Running: Indica si esta conectado al servidor master
Skip_Counter: Indica si se ha salteado alguna posición
Exec_Master_Log_Pos: Indica la posición del log del maestro que esta siendo ejecutada
Seconds_Behind_Master: Parámetro de tiempo en que tardará el esclavo en llegar hasta la ultima posición del ultimo log del Master
Los primeros parametros que suelo fijarnme son el “Slave_IO_Running” ya que si está en “No”, es porque no está conectado con el master y el “seconds_behind_master” ya que si esta conectado lo ideal serÃa que tenga 0 segundos. Si no es cero, por lo gral ejecuto el show slave status \G; varias veces con cierto intevalo de tiempo para ver si se incrementa.
En caso que se incremente significa que el master guarda más resultados de lo que el slave está leyendo, entonces nos fijamos en el número del parámetro “Exec_Master_Log_Pos” Si no se mueve despues de un cierto tiempo, hay un problema.
Problemas comunes conocidos:
La consulta que el slave está ejecutando está trabada o tarda demasiado. Para esto por lo general sugiero parar la replicación del slave: “STOP SLAVE;” y adelantar posiciones en el los ejecutando: “SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 10;” (10 son las posiciones que nuestro log avanzará). Pueden probar de a uno si quieren, en mi caso que el sistema procesa más de 600,000 inserts por dÃa no es demasiado problema un salto de 10 registros. Una vez avanzado, hay que iniciar nuevamente el slave: “START SLAVE;”
Una de nuestras tablas MyIsam esta dañada: Para esto se deberá parar la replicación: “STOP SLAVE;” y ejecutar desde consola de MySQL el comando “REPAIR TABLE nombredetabla;”. Si esto no lo solucionó, se puede hacer desde afuera del motro mysql con el comando “myisamchk –safe-recover nombredetabla.MYI” (repito: fuera de mysql, en el shel de linux y dentro de la carpeta de los archivos binarios de los datos de mysql)
Muchas veces se requiere hacer consultas grandes que sólo queremos hacerlo en el master pero no queremos que se replique, casos muy comunes de este tipo son el OPTIMIZE o el REPAIR ambas consultas quedarÃan logueadas y pasarÃan al esclavo trabando considerablemente el flujo de la información. Para solucionar esto sólo hay que agregar: NO_WRITE_TO_BINLOG inmediatamente despues del comando. EJ: “OPTIMIZE NO_WRITE_TO_BINLOG TABLES nombredetabla;”
Espero que esta serie de posts pueda serles de utilidad algún dÃa. La replicación hasta 4 servidores de MySql, como ya mensioné en el primer post, es la forma de escalabilidad más económica que puede tener un sistema a nivel de bases de datos. Además puede ser de gran utilidad poara mantener backups sincronizados de forma permanente.
Creo haber cumplido con todos los objetivos propuestos y creo también que fue una buena forma de retomar con este blog un tanto olvidado.
13 Comentarios
juan
Febrero 11th, 2008 at 12:57 pm
Hola, si no dispongo accesos al my.ini del servidor(internet) no puedo hacer replica de ninguna manera?
Existe alguna otra forma de replicar la bd de local a una en un servidor web?
Gracias!
Lucas
Febrero 11th, 2008 at 1:03 pm
Juan, si, existe, pero ya no serÃa replicación mysql, sólo serÃa un backup o una sincronización automátizada. Para windows el MySql YOG te puede servir; para linux, habrÃa que programar un crontab para ejecutar un mysql dump y que luego ejecute el dump en la base destino.
Saludos
juan
Febrero 11th, 2008 at 1:59 pm
Muchas gracias Lucas, voy a revisar el mysql yog!
juan
Febrero 11th, 2008 at 5:12 pm
HOla, otra vez… he trasteado el Sql yog y lo tengo configurado para la sincronizacion con la BD del servidor, pero… sabes si se puede sincronizar automaticamente sin necesidad de darle a ningun boton?
Te explico: En mi trabajo, la chica de la oficina trabaja con la Bd EN LOCAL, Y ME GUSTARIA SUPERVISAR EL TRABAJO de esa BD pero sin necesidad de darle a ningun boton…
Muchas gracias!
Yacatl
Marzo 14th, 2008 at 5:32 pm
Amigo, me parece bastante interesante tu nota y espero me ayudara mucho en mi proxima tarea. Nosotros vendemos online y por telefono a diferentes paises y nuestra DB es muy grande. La idea es tener 3 servidores (1 mater,2 slaves) de tal forma que los 3 esten ingresando ordenes de manera local y cada determinado momento los salves manden la informacion de sus ordenes al master, de tal manera que si el master se cae, los slaves puedan cada uno seguir guardando sus ordenes sin problema, en cuanto el master se levante nuevamente los datos de las ordenes de los slaves se envien y las ordenes no dejen de procesarse. Es esto posible con la replicación? Cabe senalar que solamente necesitaria tener unas cuentas tablas del sistema en los servidores slave, y no la DB completa. Muchas gracias!
Lucas Zallio
Marzo 14th, 2008 at 5:57 pm
Estimado Yacatl:
Teniendo en cuenta que el que recibe la información siempre es el “esclavo” (que hace lo que el master le ordena) a lo que le llamas master deberÃa ser slave. Y lamentablemente no se pueden tener dos master dándole instrucciones a un slave ya que no sabrÃa a quien responder.
Lo que te sugerirÃa hacer es:
1) Guardar todos los datos en un solo server y replicar hacia un servidor esclavo, si el esclavo se cae todo se sigue guardando igual y cuando el esclavo vuelve, el master le pasa todos los datos.
2) Tener dos servidores que guarden, pero se configuran de tal forma que el master1 solo replique la base X y el master2 replique la base de datos Y. El slave recibe las dos sin problemas de que las instrucciones se mezclen.
Espero haber sido de ayuda. Saludos
Ruben
Marzo 15th, 2008 at 8:59 am
Amigo como se configuraria para que en 1 solo server la bdA actualize a la bdB
Christian
Mayo 6th, 2008 at 1:24 pm
Hola Lucas, necesito un poco de tu ayuda, mira estoy realizando un sistema de facturacion para la empresa donde trabajo, tenemos un servidor principal y servidores terminales, pero lo que queremos es que haya actualizacion de lado a lado, por cuestion de facturas, y de de ingresos a los inventarios de cada agencia, como puedo hacer esto si lo que hasta ahora propones es muy util pero es solo de un lado a otro
Lucas Zallio
Mayo 6th, 2008 at 1:54 pm
Christian, es posible hacerlo de lado a lado, es decir cada uno es el master del otro. Sólo hay que tener cuidado que lo que se replique en uno no se vuelva a replicar en el otro. Lo único prohibido es que un server no puede tener dos masters distintos al mismo tiempo.
Diego Toala
Diciembre 8th, 2008 at 7:42 pm
Hola , te felicito estan muy bien tus artÃculos, tengo una duda , estoy probando localmente la replicación, utilizando dos servicios mysql corriendo en mi maquina; uno corriendo en el puerto 3306 y el otro en el 3307, todo funciona , a pesar de que SLAVE_IO_RUNNING me aparece que NO corre, la replicación de datos funciona con inserciones, modificaciones y actualizaciones.
Yo quiero que la replicación solo sea con las inserciones, si yo modifico o elimino algún dato en el maestro, este no se refleje en el esclavo.
Sabes algún modo?
Saludos.
Alfonso
Marzo 12th, 2009 at 4:55 pm
Se puede replicar la informacion de varios equipos cadauno con una base de datos a un solo equipo?
esto es, tendo 4 pc’s cada una con una base de datos las cuales estan ingresando transacciones, todas las bases tiene las mismas tablas y quiero concentrarlas en un servidor que tenga la informacion de las 4 bases
Lucas Zallio
Marzo 12th, 2009 at 5:00 pm
Hola Alfonso. No con este feature de MySql. Básicamente un servidor no puede tener más de un master.
Alfonso
Marzo 12th, 2009 at 9:47 pm
Si tengo las 4 pc’s con una base de datos cada una, y me interesa replicar una sola tabla de cada una de las pc’s,
en el server puedo crear 4 bases de datos (una para cada pc) y hacer la replica y despues crear una vista con las cuatro tablas replicadas?