Diferència entre revisions de la pàgina «Storagesis-Memoria tecnica»
| (Hi ha 10 revisions intermèdies del mateix usuari que no es mostren) | |||
| Línia 1: | Línia 1: | ||
| − | + | __FORCETOC__ | |
| − | + | ==Esquema final== | |
| − | + | ||
| − | + | Esquema final de nuestra infraestructura: | |
| − | + | [[File:esquema_final.png|frame|none|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. | ||
Revisió de 19:17, 25 maig 2018
Esquema final
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.