Galera Cluster para MariaDB y MySQL

 

Las funciones más avanzadas del mundo y los beneficios nunca vistos 

  • Verdadero Multi-master,  Cluster Activo-Activo  Lectura y escritura en cualquier nodo en cualquier momento. 
  • Replicacion Síncrona  No hay retraso en los "Slaves" (esclavos), no se pierden datos en el bloqueo del nodo.
  • Completamente acoplados Todos los nodos tienen el mismo estado. No se permiten datos divergentes entre nodos. 
  • "Multi-threaded Slave" (Esclavo Multi-Proceso) Para un mejor rendimiento. Para cualquier carga de trabajo.
  • Sin operaciones de "Failover" "Master-Slave" , sin uso de VIP.
  • "Hot Standby" Sin tiempo de inactividad durante el "failover" (puesto que no existe "failover").
  • Aprovisionamiento Automático de Nodos No es necesario realizar una copia de seguridad manual de la base de datos y copiarla en el nuevo nodo.
  • Soporta InnoDB.
  • Transparente para las Aplicaciones No se requieren (o cambios mínimos) en la aplicación.
  • No es necesaria división entre Lectura y Escritura.
  • Fácil de usar e implementar. 

Implementaciones en "Cloud" con Galera Cluster

Un beneficio adicional de Galera Cluster es un buen soporte en la nube. El aprovisionamiento automático de nodos hace que las operaciones de "sacale-out" y "sacale-in" sean sencillas. Se ha demostrado que Galera Cluster tiene un rendimiento extremadamente bueno en la nube, como cuando se usan múltiples instancias de nodos pequeños, en múltiples centros de datos, por ejemplo, zonas de AWS, o incluso en "Wider Area Networks". 

  •  Protocolo de Red Optimized . Paquetes intercambiados a través de WAN solo en el momento de confirmación de la transacción
  • Replicacion con reconocimiento de la Topología. La transacción se envía a cada centro de datos solo una vez
  • Cifrado de Tráfico
  • Detection e inhabilitación automática de Nodos no dignos de confianza

Más información acerca de Replicación

Replicación de Galera 

  • La replicación de Galera se produce en el momento de confirmación de la transacción, transmitiendo el conjunto de escrituras de transacciones al clúster para ser aplicado
  • El cliente se conecta directamente al SGBD y experimenta un comportamiento cercano al SGBD nativo
  • wsrep API (API de replicación de conjunto de escritura), define la interfaz entre la replicación de Galera y el SGBD

Mas Información sobre  WSREP API

Replicación Síncrona versus Asíncrona

La diferencia básica entre la replicación síncrona y asíncrona es que "síncrono" garantiza que si ocurrieron cambios en un nodo del clúster, ocurrieron en otros nodos de forma "síncrona". "Asíncrono" no garantiza el retraso entre la aplicación de cambios en el nodo "maestro" y la propagación de cambios a los nodos "esclavos". El retraso puede ser corto o largo, es cuestión de suerte. Esto también implica que si el nodo maestro falla, algunos de los últimos cambios pueden perderse.

Teóricamente  la replication síncrona  tiene algunas ventajas sobre la asíncrona: 

  • Siempre está en alta disponibilidad (no hay pérdida de datos cuando uno de los nodos falla y las réplicas de datos son siempre consistentes)
  • Las transacciones se pueden ejecutar en todos los nodos en paralelo..
  • Puede garantizar la causalidad en todo el clúster (SELECT S emitido después de la transacción T siempre verá los efectos de la transacción, incluso si se ejecuta en otro nodo)

Sin embargo, en la práctica, la replicación síncrona de la base de datos se implementó tradicionalmente a través del llamado "compromiso de 2 fases" o bloqueo distribuido que resultó ser muy lento. El bajo rendimiento y la complejidad de la implementación de la replicación síncrona condujeron a una situación en la que la replicación asíncrona sigue siendo el medio dominante para la escalabilidad y disponibilidad del rendimiento de la base de datos. Las bases de datos de código abierto ampliamente adoptadas como MySQL o PostgreSQL ofrecen solo una solución de replicación asíncrona. 

Más información sobre Replicación Síncrona vs. Asíncrona 

Método de replicación basado en certificación

La idea principal en la replicación basada en la certificación es que una transacción se ejecuta convencionalmente hasta llegar al punto de confirmación, suponiendo que no haya conflicto. Esto se llama ejecución optimista.

Cuando el cliente emite un comando COMMIT, pero antes de que ocurra la confirmación real, todos los cambios realizados en la base de datos por la transacción y las claves primarias de las filas modificadas se recopilan en un conjunto de escritura. La base de datos luego envía este conjunto de escritura a los demás nodos.

El conjunto de escritura se somete a una prueba de certificación determinista, utilizando las claves principales. Esto se realiza en cada nodo del clúster, incluido el nodo que origina el conjunto de escritura. Determina si el nodo puede aplicar o no el conjunto de escritura.

Si la prueba de certificación falla, el nodo descarta el conjunto de escritura y el clúster "rolls back" (revierte) la transacción original. Si la prueba tiene éxito, la transacción se confirma y el conjunto de escritura se aplica al resto del clúster.

Más información sobre  Replicación Basada en Certificacion

Varios investigadores sugirieron un enfoque alternativo para la replicación síncrona de bases de datos utilizando la comunicación grupal y las técnicas de pedido de transacciones (por ejemplo, Database State Machine Approach and Don’t Be Lazy, Be Consistent) y las implementaciones de prototipos han demostrado ser muy prometedoras. Combinamos nuestra experiencia en la replicación de bases de datos síncronas y las últimas investigaciones en el campo para crear "Galera Replication Toolkit".

Galera replication es una solución de replicación síncrona altamente transparente y escalable para "Clusters" de aplicaciones para lograr una alta disponibilidad y un rendimiento mejorado. Los "Clusters" basados ​​en Galera son:

  • Altamente disponibles
  • Muy transparentes
  • Altamente escalable (se puede alcanzar una escalabilidad casi lineal dependiendo de la aplicación)
    application)

Biblioteca de  Replicación Genérica

La funcionalidad de replicación de Galera se implementa como una biblioteca compartida y se puede vincular con cualquier sistema de procesamiento de transacciones, que implementa los "wsrep API hooks". La biblioteca de replicación Galera es una pila de protocolos que proporciona funcionalidad para preparar, replicar y aplicar conjuntos de escritura de transacciones. Consiste en:

  • wsrep API especifica la interfase – responsibilidades para SGBD y el proveedor de replicación
  • wsrep hooks es la integración wsrep en el motor del SGBD.
  • El proveedor de Galera implementa la API wsrep para la Librería de Galera
  • La capa de certification  se encarga de preparar conjuntos de escritura y realizar la certificación
  • replicación gestiona el protocolo de replicación y proporciona capacidades completas de pedido 
  • El "framework" GCS  proporciona arquitectura de plugin para sistemas de comunicación grupal
  • se pueden adaptar muchas implementaciones de gcs, hemos experimentado con  "Spread"  y  con nuestras implementaciones internas: vsbes y gemini