Configuración de Replicación Master Master en Mysql

Dificultad: Fácil
Tiempo de Lectura: 5 minutos

Llego el momento en donde queremos que nuestra aplicación, sistema o blog este 100% disponible y que podamos estar seguros que estará en linea siempre, y es muy común que nos hagamos la siguiente pregunta: ¿Como hago para que mi aplicación este en una plataforma siempre online?

Hoy vamos a responder una las preguntas derivadas de este tema: ¿Como hago para tener mi data MySQL en dos o más servidores de forma redundante?  Ya que esto en teoría me aseguraría que mi aplicación tendrá tanto una copia de las bases de datos como una replicación en vivo de la data y podre colocar mis servidores de aplicación a apuntar a cualquiera de mis servidores MySQL.

Vamos a ver ahora una configuración de replicación master master bajo MySQL en un entorno de pruebas.

Introducción

Una replicación MasterMaster como tal no existe en la configuración de Mysql, sin embargo este motor de base de datos posee la característica de configurar la plataforma de forma MasterSlave, ahora vamos a detallar la diferencia entre las dos formas.

Teoría de configuración Master-Slave (Escritura – Lectura)

Partamos de que tenemos 2 servidores de mysql, bueno esta configuración funcionaria de la siguiente forma, tendremos un servidor como (Master) y otro como (Slave) esta configuración también la podemos llamar (Escritura – Lectura) ya que en un servidor (Master) escribimos nuestros cambios en la base de datos (INSERT, UPDATE, DELETE) y en el otro servidor (Slave) solamente se realizaran consultas (SELECT), esto quiere decir que cuando hacemos una operación de escritura en nuestro servidor Master este a su vez de forma automática y manteniendo la sincronización enviara este cambio al servidor Slave, asi cuando nuestra aplicación realice consulta podemos hacerla a nuestro servidor Slave ya que el mismo estará sincronizado con el servidor Master, esta configuración se utiliza para quitarle carga de procesamiento y de consulta al servidor Master.

Esta configuración en algunos casos nos funciona bien, esto siempre depende de la aplicación si tiene mucho consumo en consultas podemos partir de esta configuración, pero la pregunta seria: ¿Que pasa si un día el servidor Master tiene algún problema, como queda mi aplicación? Bueno si seleccionaste esta configuración tu aplicación solamente podrá realizar consultas al servidor Slave y no podrá procesar mas registros (INSERT,UPDATE y DELETE) hasta que el servidor Master este online. Por esto necesitamos al menos en nuestra plataforma una configuración Master-Master.

Teoría de configuración Master-Master (Escritura –Escritura)

Partamos igual que tenemos 2 servidores de Mysql con la configuración por defecto, en este caso nuestra configuración sera Master-Master que simplemente funcionara de la siguiente manera.

Servidor A sera Slave del Servidor B

De igual forma

Servidor B sera Slave del Servidor A

Con esta configuración podemos observar que si por ejemplo realizamos un INSERT en nuestro Servidor B automaticamente esta data se pasara a nuestro Servidor A de igual forma pasara si hacemos un DELETE en nuestro Servidor A  esta data también sera borrada de nuestro Servidor B  con esto podemos decir que nuestra data estará siempre sincronizada entre nuestros dos servidores sea cual sea el origen de la escritura en nuestro Mysql.

Configuración de Replicación Master Master en Mysql

Partimos nuestro ejemplo con dos servidores

Servidor A (Alfa): 1.1.1.1

Servidor B (Beta): 2.2.2.2

Ahora en nuestros archivos de configuración my.conf debemos colocar la siguiente configuración

Para nuestro servidor Alfa que sera Slave de nuestro servidor Beta

[mysqld]

server-id=1
master-host=2.2.2.2
master-user=demoreplicacion
master-password=replicacioninfra
master-port=3306
log-bin
binlog-do-db=bd_infra
replicate-do-db=bd_infra

Para nuestro servidor Beta que sera Slave de nuestro servidor Alfa

[mysqld]

server-id=2
master-host=1.1.1.1
master-user=demoreplicacion
master-password=replicacioninfra
master-port=3306
log-bin
binlog-do-db=bd_infra
replicate-do-db=bd_infra

Explicación de las variables utilizadas

server-id : este es un identificador entero para ayudar a identificar el servidor (debe ser único en la comunidad de la replicación)
master-host : especifica la ip / nombre de host del servidor MySQL como maestro para el servidor actual
master-user : especifica el usuario que se utiliza para hacer la conexión con el maestro
master-password : es la contraseña del usuario
master-port : especifica en qué puerto está escuchando el maestro
log-bin : necesario para iniciar el proceso de registro binario
binlog-do-db : especifica la qué bases de datos activa para la replicación (sólo aquellas bases de datos estarán en el registro binario)
replicate-do-db : base de datos que debe ser replicada por el servidor como esclavo.

Reiniciamos nuestro servicio de Mysql para que se tomen los cambios en la configuración.

Ahora nos conectamos a las base de datos y damos los privilegios a los usuarios

Nos conectamos a mysql por consola con nuestro usuario root en ambos servidores «mysql -p» y hacemos los siguientes pasos.

En el servidor Alfa

mysql> grant replication slave, replication client on *.* to demoreplicacion@"2.2.2.2" identified by "replicacioninfra";
Query OK, 0 rows affected (0.00 sec)

En el servidor Beta

mysql> grant replication slave, replication client on *.* to demoreplicacion@"1.1.1.1" identified by "replicacioninfra";
Query OK, 0 rows affected (0.00 sec)

Ahora ya entre los servidores pueden conectarse para poder hacer los procesos de sincronización de data.

Todavia adentro de mysql es recomendabla manejar los siguientes comandos

1. Saber el estatus de nuestro slave en cada servidor

 show slave status\G

2. Detener nuestro servidor esclavo

 slave stop;

3. Iniciar nuestro servidor esclavo

 slave start;

4. Modificar la cantidad de saltos de errores para nuestro esclavo.

 set global SQL_SLAVE_SKIP_COUNTER = 1;

Prueba de sincronización de la base de datos bd_infra

En esta parte es donde es importante saber que debemos iniciar en los dos servidores con la misma data o sea en pocas palabras por ejemplo con nuestra bd_infra que este vacía coloquemos el caso, entonces que en nuestros 2 servidores esta base de datos este creada pero vacía, esto es algo que no nos explican cuando entramos en este mundo de la replicación parece algo simple pero puede ser que nos los saltemos al momento de iniciar el proceso de sincronización, más de una vez haciendo esta configuración con bases de datos ya con data pasa esto, lo importante y la recomendación que damos es cumplir los siguientes pasos.

1. Iniciar análisis de nuestra base de datos con los slave detenidos.

 slave stop;

2. Por ejemplo si es con una base de datos vacía, crear la base de datos en nuestros servidores y luego iniciar el proceso del slave, con esto nos aseguramos que se cumpla perfecto la sincronización en nuestros servidores.

 slave start;

3. Si quieres hacer la replicación con una base de datos con información la idea es la misma copiar en el segundo servidor la data que se encuentra en el primer servidor vía dump, esto teniendo en cuenta siempre el paso 1.

4. Luego de esto podemos iniciar nuestro slave en nuestros 2 servidores.

 slave start;

5. Es importante que al iniciar nuestro slave en ambos servidores conocer el status del mismo.

 show slave status\G

Debemos buscar que estas variables esten en Yes, esto significa que nuestro replicación esta activa y esta esperando cualquier cambio para poder sincronizarla con el otro servidor.

Slave_IO_Running: Yes
Slave_SQL_Running: Yes

6. Luego podemos crear una tabla de prueba en el servidor Alfa en la base de datos bd_infra y ver que se replica al momento en nuestro servidor Beta, siempre luego de cualquier cambio debemos asegurarnos de nuestro paso 5 este correcto.

7. Si no funciona la replicación que hacemos, lo importante en este caso es verificar el paso 5 y seguramente alguna de estas variables estara en No y por esta razon no esta sincronizando, lo bueno del show slave status es que nos muestra un log de errores que nos indica en que fallo, estos errores se deben solventar manualmente o colocando la siguiente variable en nuestro mysql

set global SQL_SLAVE_SKIP_COUNTER = 1;

Esto lo que hace es saltar un error a la vez, a veces hemos colocado este valor en 100 para que salte 100 errores pero lo mejor es cumplir el paso 1 y 3 para asegurarnos que la data este en nuestros 2 servidores. Y eso es todo, ya en este punto deberíamos tener nuestros servidores MySQL en replicación master-master.

Si deseas puedes dejarnos un comentario de que te parecio el paso a paso y como te fue en la configuración, recuerda que esta configuración la puedes realizar sin problemas en cualquiera de nuestros Servidores Dedicados o  Cloud VPS.

¿Te resultó útil el artículo? Compártelo con tus colegas:


Un Comentario

  1. albert 26/07/2016