Réplica de múltiples escritores ha sido un desafío en el ecosistema MySQL durante años antes de la introducción de soluciones verdaderamente dedicadas: primero la replicación Galera (y, por lo tanto, Percona XtradDB Cluster (PXC)) (alrededor de 2011) y luego la replicación grupal (primera AG en 2016).

Ahora, con las dos tecnologías de secuencias de comandos múltiples disponibles, ¿seguimos necesitando la replicación asíncrona tradicional, instalada en una topología de activo a activo? Aparentemente sí, todavía hay casos de uso válidos. Y es posible que lo necesite no solo cuando, por alguna razón, Galera / PXC o GR no sean adecuados, sino también cuando realmente lo use. Por supuesto, el caso más típico es tener un segundo clúster en una ubicación geográfica diferente, como Disaster Rrecuperación. Si también se pregunta por qué lo necesita, solo lea cómo un centro de datos completo podría desaparecer en las noticias hace unas semanas. sobre el incidente de OVH.

Por lo tanto, un sitio DR debe replicarse en línea desde el clúster principal y poder recuperar la carga de trabajo muy rápidamente si es necesario. Pero también se espera que pueda cambiar sin esfuerzo, por lo que muy a menudo se instalan canales de replicación asíncronos en ambas direcciones.

Puede encontrar un muy buen artículo sobre esto aquí: Cómo no hacer que MySQL tenga alta disponibilidad: distribución de nodos geográficos con replicación basada en galería.

Ahora, después de ver repetidos problemas con configuraciones activo-activo cayendo una y otra vez durante años, pensé que todavía había muy pocas advertencias aquí sobre los riesgos, así que decidí agregar una piedra más a la pila.

Antes de continuar, permítanme mencionar este gran seminario web realizado el año pasado por mi colega Sveta. Definitivamente debería investigarlo si está interesado en el tema: ¿Qué tan segura es la configuración Asynchronous Master-Master en MySQL?

Regístrate en Percona Live ONLINE
Un evento virtual sobre bases de datos Open Source

Prueba de falla

Entonces, permítanme demostrar un caso de prueba simple, que puede ser interesante para algunos.

Primero, usamos el grande. dbdeployer herramienta para lanzar dos instancias de MySQL con replicación activo-activo en un solo comando:

Ahora, cree una tabla muy simple con una fila de datos de muestra:

Entonces, en este punto, los dos nodos tienen los mismos datos:

En el siguiente paso, simulamos un ligero retraso en la replicación introduciendo un retraso de un segundo, para que podamos reproducir el problema a voluntad:

Bien, cuando enviamos una actualización, muy cerca en el tiempo, a ambos nodos, donde la misma fila recibe un valor diferente:

Como resultado, ¡los dos nodos tienen valores de columna diferentes!

¿Está rota la replicación?

¿Crees que la replicación ahora está rota y que algunos errores te alertarán sobre la situación? ¡Para nada!

¿O espera que la activación de la función GTID evite que ocurran inconsistencias? Bueno, nos vemos Executed_Gtid_Set en ambos nodos: es lo mismo, pero los nodos tienen datos diferentes.

¿Qué pasa después? Bueno, depende, tal vez la replicación falle algún día con un error si la misma fila se modifica nuevamente, ¡pero también es posible que la inconsistencia se extienda aún más sin que te des cuenta!

¿Lección aprendida?

Espero que este simple ejemplo haya enfatizado la necesidad de un cuidado extra cuando se trata de topologías de replicación primaria múltiple. Pero el remedio suele ser bastante simple:

1 – Asegúrese de permitir que solo un nodo escriba a la vez (super_read_only está aquí para ayudar).

2 – Verifique la consistencia de los datos regularmente con las herramientas apropiadas (antes de replicar MySQL con pt-table-checksum y pt-table-sync).

Percona Distribution for MySQL es la solución MySQL de código abierto más completa, estable, escalable y segura disponible, que proporciona entornos de base de datos de nivel empresarial para sus aplicaciones comerciales más críticas… ¡y es de uso gratuito!

Descarga Percona Distribution para MySQL hoy