MySQL InnoDB Cluster de un vistazo Parte 1: replicación de grupos

Desde MySQL 5.7 tenemos un nuevo jugador en el campo, Clúster MySQL InnoDB. Esta es una solución de alta disponibilidad de Oracle que se puede instalar fácilmente en MySQL para lograr una alta disponibilidad con capacidades multimaestro y conmutación por error automática.

Esta solución consta de 3 componentes: InnoDB Group Replication, MySQL Router y MySQL Shell, puede ver cómo interactúan estos componentes en este gráfico:

En esta serie de tres publicaciones de blog, cubriremos cada uno de estos componentes para tener una idea de lo que proporciona esta herramienta y cómo puede ayudar con las decisiones arquitectónicas.

replicación de grupo

Esta es la verdadera solución de Alta Disponibilidad, y hace un tiempo escribí una breve reseña de ella cuando aún estaba en su etapa de laboratorio. Ha mejorado mucho desde entonces.

Esta solución se basa en un complemento que debe instalarse (no se instala de forma predeterminada) y funciona sobre la replicación integrada. Luego se basa en registros binarios y registros de retransmisión para aplicar scripts a los miembros del clúster.

El concepto principal de este nuevo tipo de replicación es que todos los miembros de un clúster (es decir, cada nodo) se consideran iguales. Esto significa que no hay maestro-esclavo (donde los esclavos siguen al maestro) sino miembros que aplican transacciones basadas en un algoritmo de consenso. Este algoritmo obliga a todos los miembros de un clúster a comprometerse o rechazar una transacción en particular siguiendo las decisiones tomadas por cada miembro individual.

En términos prácticos, esto significa que cada miembro del clúster tiene que decidir si se puede realizar una transacción (es decir, sin conflicto) o se debe devolver, pero todos los demás miembros siguen esta decisión. En otras palabras, la transacción se compromete o pospone según la mayoría de los miembros en un estado consistente.

Para lograr esto, existe un servicio que muestra una vista del estado del clúster que indica qué miembros componen el clúster y el estado actual de cada uno de ellos. Además, la replicación de grupos requiere GTID y replicación basada en filas (o
binlog_formato=PÓNGASE EN FILA ) para distribuir cada script con cambios de fila entre los miembros. Esto se hace a través de registros binarios y registros de retransmisión, pero antes de que cada transacción se envíe a registros binarios/de retransmisión, la mayoría de los miembros del clúster debe reconocerla, en otras palabras, por consenso. Este proceso es síncrono, a diferencia de la replicación heredada. Después de replicar una transacción, contamos con un proceso de certificación para comprometer la transacción y así hacerla sostenible.

Aquí aparece un nuevo concepto, el proceso de certificación, que es el proceso que confirma si se puede aplicar/confirmar un script de escritura (es decir, se puede realizar un cambio de cola sin conflictos) después de que se completa la replicación de la transacción.

Básicamente, este proceso consiste en inspeccionar los conjuntos de escritura para ver si hay algún conflicto (es decir, la misma fila actualizada de transacciones simultáneas). Basado en un orden establecido en el conjunto de escritura, el conflicto se resuelve con «victorias del primer autor», mientras que el segundo se devuelve al autor. Finalmente, la transacción se envía a registros binarios/de retransmisión y se activa.

Funciones de solución

Algunas otras características proporcionadas por esta solución son:

  • Modos primarios únicos o primarios múltiples lo que significa que el clúster puede operar con un solo escritor y múltiples lectores (configuración recomendada y predeterminada); o con múltiples escritores donde todos los nodos pueden aceptar transacciones de escritura. Este último es a costa de una penalización de desempeño por resolución de conflicto.
  • detección automática de fallas, donde un mecanismo interno puede detectar un nodo fallido (es decir, un bloqueo, problemas de red, etc.) y decide excluirlo automáticamente del clúster. Además, si un miembro no puede comunicarse con el clúster y se aísla, no puede aceptar transacciones. Esto garantiza que los datos del clúster no se vean afectados por esta situación.
  • Tolerancia a los defectos. Esta es la estrategia que utiliza el clúster para dar soporte a los miembros fallidos. Como se describió anteriormente, esto se basa en la mayoría. Un clúster necesita al menos tres miembros para soportar una falla de un nodo porque los otros dos miembros mantienen la mayoría. Cuanto mayor sea la cantidad de nodos, mayor será la cantidad de nodos fallidos que admite el clúster. El número máximo de miembros (nodos) en un clúster actualmente está limitado a 7. Si tiene siete miembros, la mayoría está protegida por cuatro o más miembros activos. En otras palabras, un grupo de siete admitirá hasta tres nodos fallidos.

No cubriremos los aspectos de instalación y configuración ahora. Esto probablemente vendrá con una nueva serie de blogs donde podemos cubrir no solo la implementación sino también los casos de uso, etc.

En la próxima publicación hablaremos sobre el siguiente componente del clúster: MySQL Router, así que estad atentos.

Author: Ing. Luis

A lo largo de conocer Windows y otros sistemas operativos me eh encontrado con diversos tipos de error, ahora brindo soluciones según mi experiencia-

Deja un comentario