Conceptos erróneos típicos sobre Galera para MySQL

Aunque un nodo de Galera se parece a un servidor MySQL normal, el mecanismo de replicación subyacente es muy diferente. Esto implica algunos cambios en la forma de configurar los nodos de Galera. Estos son algunos de los conceptos erróneos más comunes sobre Galera cuando se usa Percona XtraDB Cluster.

P: ¿Por qué debo habilitar el registro binario que no requiere la replicación de Galera?
A diferencia de la replicación asíncrona regular de MySQL, es cierto que no necesita activar el registro binario para usar la replicación de Galera. Sin embargo, que si alguien tiene un accidente DROP TABLE?

En este caso, la declaración se replicará inmediatamente en todos los nodos. Entonces, su opción principal para recuperar datos perdidos es usar una copia de seguridad. Pero si el registro binario no está habilitado, se perderán todos los cambios en la tabla después de la copia de seguridad.

¿Qué sucede si tiene un esclavo asíncrono que se retrasa intencionalmente? Esta es otra buena opción para recuperar rápidamente los datos perdidos, pero para instalar un esclavo asíncrono, ¡también necesita activar el registro binario!

Entonces no olvides agregar todos tus nodos:

P: Si he establecido innodb_flush_log_at_trx_commit = 2puedo perder datos en algunos casos, ¿verdad?
Para un maestro MySQL regular, se recomienda establecer innodb_flush_log_at_trx_commit = 1 porque esta es la única forma de garantizar que cada transacción ocupada se almacene permanentemente en el disco. El principal inconveniente es que puede ralentizar mucho la escritura porque implica un fsync para cada tarea.

Con Galera, la diferencia es que el compromiso es síncrono: esto significa que una transacción está comprometida con el nodo n. ° 1, ya se ha replicado en todos los demás nodos (aunque no necesariamente se ejecuta en nodos remotos).

Como Galera implementa la durabilidad en el clúster, no es necesario tener una sola durabilidad del servidor y puede usarla de forma segura. innodb_flush_log_at_trx_commit = 2 en todos los nodos.

En realidad, esto no es del todo exacto… Por ejemplo, si todos los nodos pierden energía al mismo tiempo, es posible que pierda algunas transacciones. La probabilidad de tal falla está relacionada con la ubicación de los nodos: con cada nodo en un centro de datos separado, esto es muy poco probable. Pero con 3 nodos que son máquinas virtuales en un solo host físico, podría suceder bien de vez en cuando.

P: La red RTT entre mis servidores es de 100 ms. Sabemos que cada comisión toma al menos el tiempo de una red RTT, entonces, ¿solo puedo esperar ejecutar 10 scripts / s?

Esto necesita alguna aclaración: la confirmación es síncrona porque la transacción completa se replica en todos los nodos cuando se activa. Sin embargo, usted paga el mismo precio ya sea que la transacción tenga un solo estado de cuenta o varios estados de cuenta.

Por lo tanto, si todos sus scripts son transacciones de participación automática, cada script activará un compromiso que requerirá al menos un RTT para completarse. Si RTT es 100ms, eso significa 10 escritos/s.

Pero si sus transacciones tienen 10 escrituras, solo necesita una confirmación cada 10 escrituras: con 10 confirmaciones / s, ahora puede ejecutar. 100 escrituras/s.

Y finalmente, varios subprocesos pueden participar al mismo tiempo, lo que aumenta el rendimiento de escritura. Con 10 subprocesos simultáneos que ejecutan transacciones con 10 declaraciones, lo tiene 1000 escrituras / s.

Por supuesto, esto es solo teoría. En el mundo real, probablemente no obtenga números que estén perfectamente alineados. Puedes ver esta publicación (Compare Percona XtraDB Cluster con la replicación Semi-Sync Cross-WAN) para ver números reales con 1 hilo y 32 hilos.

Conclusión: la latencia de la red es un factor limitante para el rendimiento de escritura, es cierto. Pero esto puede no ser tan malo como podría pensar. Y recuerda la ley de Callaghan: «En un clúster de Galera, RTT no puede cambiar una fila determinada más de una vez».

Quiero escribir en todos los nodos para obtener escalabilidad de escritura. ¿Es eso una buena idea?

Permítanme comenzar diciendo que Galera no puede ser una solución real para escalar: la única razón es que todos los scripts deben aplicarse a todos los nodos.

Pero Galera tiene una forma limitada de escalabilidad de escritura cuando escribe en varios nodos simultáneamente porque:

  • Los conjuntos de escritura se pueden aplicar en paralelo en nodos remotos.
  • Galera usa la replicación basada en filas, por lo que aplicar los eventos replicados puede ser más rápido que realizar la escritura original.

Sin embargo, hay una advertencia al escribir en varios nodos: debido al cierre optimista, las transacciones simultáneas en varios nodos pueden generar conflictos de escritura. En este caso, Galera tendrá que revertir una de las transacciones y depende de la aplicación volver a intentar ejecutar la transacción.

Conclusiones
Galera Replication es una excelente tecnología que puede ayudarlo a resolver los desafíos relacionados con la alta disponibilidad. Pero un conocimiento básico de cómo funciona el desempeño es útil porque puede evitar la frustración o las expectativas poco razonables.

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