Diferència entre revisions de la pàgina «Storagesis-Memoria tecnica»

De Wiket
Salta a la navegació Salta a la cerca
 
(Hi ha 3 revisions intermèdies del mateix usuari que no es mostren)
Línia 6: Línia 6:
 
[[File:esquema_final.png|frame|none|Esquema final de nuestra infraestructura]]
 
[[File:esquema_final.png|frame|none|Esquema final de nuestra infraestructura]]
  
==Comparativa Maestro - Maestro con Maestro - Esclavo==
+
==Problema Maestro - Maestro con bin-log==
  
{|width="300px" align="center" style="border: 1px solid grey;" cellpadding="0" cellspacing="0"
+
La idea original de nuestro proyecto era implementar una infraestructura maestro - maestro, ya que el HAProxy los utilizamos como balanceador y tener dos bases de datos sincronizadas aumenta el número de peticiones que podemos soportar. Además, en el caso de la caida de una servidor el HAProxy rediccionaria todas las peticiones al servidor activo.
|-
 
|style="border: 1px  solid grey;" cellpadding="0" cellspacing="0" align="center"|Maestro - Maestro
 
|style="border: 1px  solid grey;" cellpadding="0" cellspacing="0" align="center"|Maestro - Esclavo
 
|-
 
|style="border: 1px solid grey;" cellpadding="0" cellspacing="0" align="center"|Fila 2, columna 1
 
|style="border: 1px solid grey;" cellpadding="0" cellspacing="0" align="center"|Fila 2, columna 2
 
|-
 
|}
 
  
==Problema Maestro - Maestro con bin-log==
+
Para la replicación Maestro - Maestro utilizamos el archivo bin-log. Conseguimos implementar esta infraestructura, pero tras utilizarla durante unos días observamos que se desincronizaban al reiniciar el servicio MariaDB. Para poder sincronizar los dos maestros le indicabamos a cada maestro el archivo y la posición del bin-log del otro. Comprobamos que esta configuración era poco consistente, ya que al reiniciar el MariaDB en cualquiera de los dos servidores estos campos podían variar, lo cual detenia la sincronización entre servidores.
 +
 
 +
Tras indagar en el asunto descubrimos que no es recomendable implementar esta infraestructura con MySQL debido a su inconsitencia. Para solventar esto decidimos implementar una arquitectura maestro - esclavo. Esto nos proporciona una sincronización de los datos unidireccional hacia el esclavo. Además, disponemos de alta disponibilidad, ya que en caso de caer el servidor Maestro, promoveriamos el esclavo a Maestro.

Revisió de 19:17, 25 maig 2018


Esquema final

Esquema final de nuestra infraestructura:

Esquema final de nuestra infraestructura

Problema Maestro - Maestro con bin-log

La idea original de nuestro proyecto era implementar una infraestructura maestro - maestro, ya que el HAProxy los utilizamos como balanceador y tener dos bases de datos sincronizadas aumenta el número de peticiones que podemos soportar. Además, en el caso de la caida de una servidor el HAProxy rediccionaria todas las peticiones al servidor activo.

Para la replicación Maestro - Maestro utilizamos el archivo bin-log. Conseguimos implementar esta infraestructura, pero tras utilizarla durante unos días observamos que se desincronizaban al reiniciar el servicio MariaDB. Para poder sincronizar los dos maestros le indicabamos a cada maestro el archivo y la posición del bin-log del otro. Comprobamos que esta configuración era poco consistente, ya que al reiniciar el MariaDB en cualquiera de los dos servidores estos campos podían variar, lo cual detenia la sincronización entre servidores.

Tras indagar en el asunto descubrimos que no es recomendable implementar esta infraestructura con MySQL debido a su inconsitencia. Para solventar esto decidimos implementar una arquitectura maestro - esclavo. Esto nos proporciona una sincronización de los datos unidireccional hacia el esclavo. Además, disponemos de alta disponibilidad, ya que en caso de caer el servidor Maestro, promoveriamos el esclavo a Maestro.