porque es una mala opcion

He estado trabajando brevemente con clientes que utilizan anillos de replicación con más de 4 servidores; muchos servidores que aceptan escritura. La idea detrás de este diseño es siempre la misma: tiene múltiples servidores, tiene alta disponibilidad y tiene múltiples nodos de escritura, tiene escalabilidad de escritura. Por desgracia, esto simplemente no es cierto. Este es el por qué.

Alta disponibilidad

Tener múltiples servidores es una condición necesaria para tener alta disponibilidad, pero está lejos de ser suficiente. ¿Qué sucede si, por ejemplo, C desaparece inmediatamente?

anillo 2

  • El anillo de replicación está roto, por lo que las actualizaciones de A y B nunca irán a D. D quedará tan desactualizado rápidamente que ya no se podrá utilizar. ¡Pero espera! A ya no recibirá actualizaciones de B, por lo que A rápidamente quedará inutilizable. Lo mismo para B. Entonces, a menos que sea demasiado rápido para configurar un anillo más pequeño con los nodos restantes, toda la cadena pronto dejará de funcionar.
  • Si un evento de C todavía se está ejecutando en uno de los otros servidores, entrará en un ciclo infinito, solo porque C es el único servidor que puede evitar que un evento provenga originalmente de C por ciclo de ciclo.

En pocas palabras: cada vez que un servidor se cae, todo el sistema se cae. En otras palabras, la disponibilidad es menor que con un solo servidor.

Escalabilidad de escritura

Puede pensar que si puede ejecutar 1000 escrituras/s en un solo servidor, escribir en 4 servidores en paralelo le permitirá ejecutar 4000 escrituras/s en todo el clúster. Sin embargo, la realidad es muy diferente.

Recuerde que TODOS los scripts se ejecutarán en TODOS los servidores. Así que tenemos 2 escenarios separados:

  • Escenario # 1: 1000 scripts / s es el punto donde se encuentra un cuello de botella (por ejemplo, saturación del disco). Entonces nunca podrá manejar la carga adicional que proviene de la replicación. Lo que sucede es simplemente que los servidores se volverán lentos debido a la sobrecarga y nunca podrán ir más allá de la marca de 1000 escritura/s.
  • Escenario #2: Un solo servidor podría manejar 5000 scripts/s. Luego, escribir en todos los servidores le permitirá afirmar verdaderamente que su clúster puede absorber 4000 escrituras/s. Pero debería lograr el mismo resultado ejecutando 4000 escrituras/s en un solo servidor. Esto no tiene nada que ver con la escalabilidad de escritura.

Conclusión: dado que todos los scripts se ejecutan en todos los servidores, escribir en varios nodos no crea mágicamente una capacidad de escritura adicional. Siempre estoy obligado por la habilidad de un solo sirviente.

Otras preocupaciones

Otra preocupación al permitir múltiples escritores es escribir conflictos. MySQL no tiene un mecanismo para detectar o resolver conflictos de escritura.

Tantas cosas «divertidas» pueden suceder cuando la escritura es conflictiva:

  • Errores de clave duplicada que harán que se detenga la replicación. Y no setting auto_increment_increment y auto_increment_offset no puede resolver todas las situaciones posibles en las que pueden ocurrir errores de clave duplicada.
  • Una situación aún más divertida es cuando los escritores en conflicto no generan un error de replicación, sino que crean inconsistencias en los datos ocultos. Como tiene valor = 100 en un campo, A enfrenta valor = valor + 2 y B no valor = valor 2. Puede terminar con un servidor que tiene valor = 202 y otro servidor que tiene valor = 204. ¿Cuál es el valor verdad? imposible de saber

Si está interesado en obtener más información sobre el riesgo de sobrescribir varios nodos mientras usa la replicación MySQL normal, puede consultar este seminario web.

Conclusiones

Un anillo es una de las peores topologías de replicación de MySQL, ya que aumenta drásticamente la complejidad de todas las operaciones en el anillo sin proporcionar ningún beneficio.

Si necesita una solución HA, no es una elección fácil, ya que hay muchas y todas son comerciales, pero un anillo ciertamente no es la opción correcta. Esta publicación puede ayudarlo a encontrar a los candidatos adecuados.

Si necesita escalabilidad de escritura, las opciones son limitadas, pero nuevamente, la replicación de anillo de MySQL no es buena. La pregunta principal que hay que responder es ¿cuánta escritura quieres poder ejecutar? Por ejemplo, si desea una escalabilidad de escritura 10x pero su carga de trabajo actual es de 100 escrituras/s, es fácil: asegúrese de tener un esquema decente, índices decentes y hardware decente. Si desea una escalabilidad de escritura 10x pero ya ha ejecutado 5000 scripts/s, probablemente sea el momento de descubrir la fragmentació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