Sentido de los niveles de consistencia de replicación del grupo MySQL

Desde el lanzamiento inicial, una de las mayores quejas que he tenido sobre Group Replication es que le ha permitido leer datos «obsoletos» y no había manera de prevenir o incluso saber que había leído datos «obsoletos». Era una gran limitación. Afortunadamente, Oráculo funciones lanzadas para controlar los niveles de consistencia, y fue hace exactamente un año! No sé ustedes, pero personalmente me ha confundido el nombre group_replication_consistency = ‘DESPUÉS’ o ‘COMIENZO’.

Así que ahora quiero tratar de darle sentido y compartir mi comprensión (incluso si es un año después).

Configurar:

Comenzaremos con el valor predeterminado group_replication_consistency = ‘EVENTUAL’ y trabajaremos desde allí. Entonces, consideremos una tabla muy simple:

Con más de 10 millones de archivos:

| + ———- +

Y haremos una acción muy sencilla.

:

segundo

  • )
  • Aquí hay algunas cosas a tener en cuenta:

En el Nodo 1, la transacción tardó 1 minuto y 20 segundos en ejecutarse

En el Nodo 2 obtuvimos el resultado de inmediato, pero esencialmente obtuvimos una lectura «estable» en la que los datos ya estaban actualizados, pero teníamos una versión anterior.

¿Cómo podemos obtener mejores resultados? group_replication_consistency = ‘PRIMA’; Veamos el nivel de consistencia «PRINCE».

Dice que una transacción en el Nodo 2 esperará hasta que la transacción previamente comprometida en el Nodo 1 también se comprometa en el Nodo 2.

:

segundo

  • )
  • Así que hay algunos cambios notables:
  • La transacción en el Nodo 2 devolvió el resultado correcto ahora.

Pero ahora tardó 1 min 11 seg en volver (en lugar de 0 seg como en el caso anterior). Básicamente, la transacción esperó a que la transacción del Nodo 1 se aplicara al Nodo 2

El tiempo de ejecución en el Nodo 1 no ha cambiado.

Este modo nos permitió hacer exactamente lo que queríamos: evitar lecturas obsoletas. ¡Gran resultado! Entonces, ¿qué pasa con group_replication_consistency = ‘DESPUÉS’?

group_replication_consistency = ‘DESPUÉS’;

:

segundo

)

Aquí la situación es diferente. Ahora el tiempo de ejecución en el Nodo 1 se ha duplicado, ya que la transacción espera estar ocupada en todos los nodos y después del Nodo 2 la ejecución es inmediata.

  • Este modo siempre evita lecturas «obsoletas», pero en este caso, hemos cambiado el tiempo de espera del Nodo 2 al Nodo 1, y así es como podemos ver la diferencia entre los modos de consistencia «PRI» y «AFTER». replicación de grupos.
  • Los dos modos proporcionan una vista coherente, pero:

En modo «PRINCE»: se bloquearán los lectores de los nodos secundarios, esperando el momento en que se disponga de la vista coherente, y

En el modo «DESPUÉS», los escritores están bloqueados hasta que los otros nodos obtengan una vista coherente. Entonces, ¿qué camino elegir? En realidad, creo que es bueno tener una opción aquí. Puedes elegir, si lo deseas, configurar el tiempo de espera para tus lectores o escritores; la decisión depende de cómo esté diseñada su aplicación.

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