Duplicación maestra dual de MySQL: ¿es seguro este escenario?

Question

Actualmente tengo una replicación maestra dual de MySQL (A < -> B) configurada y todo parece funcionar a la perfección. Me basé en las ideas básicas de here y here.

El servidor A es mi servidor web (un VPS). La interacción del usuario con la aplicación conduce a actualizaciones de varios campos en la tabla X (que se replican en el servidor B). El servidor B es el levantador de pesas, donde se realizan todos los grandes cálculos. Un trabajo cron en el servidor B agrega regularmente filas a la tabla X (que se replican en el servidor A).

Así que el servidor A puede actualizar (pero nunca agregar) las filas, y el servidor B puede agregar filas. El servidor B también puede actualizar campos en X, pero solo después de el usuario ya no tiene la capacidad de actualizar esa fila.

¿Qué tipos de desastres potenciales puedo esperar con este escenario si voy a la producción con él? ¿O esto parece correcto? Lo pregunto principalmente porque ignoro si cualquier operación simultánea en la tabla (desde la copia A o la copia B) puede causar problemas o si solo son operaciones en la misma fila que se pone peluda.

Answer 1

La duplicación maestra doble es complicada si intenta escribir en la misma base de datos en ambos maestros.

Uno de los mayores puntos de contención (y alta presión sanguínea) es el use of autoincrement keys.

Mientras recuerde establecer auto_increment_increment y auto_increment_offset, puede buscar los datos que desee y recuperar los ID autoincorporados.

Solo tiene que recordar esta regla: si lee una identificación del servidorX, debe buscar los datos necesarios del servidorX utilizando la misma identificación.

Aquí hay una gracia salvadora para usar la duplicación maestra dual.

Suponga que tiene

• dos bases de datos (DB1 y DB2)
• dos servidores de base de datos (Servera y ServerB)

Si usted impone las siguientes restricciones

• todo escribe de db1 al servidor A
• todo escribe de db2 al servidor B

, entonces no es necesario configurar auto_increment_increment y auto_increment_offset.

Espero que mi respuesta aclare lo bueno, lo malo y lo feo de usar la replicación maestra dual.

• Here is a pictorial example of 4 masters using auto increment settings
• Nice article from Percona on this subject

Answer 2

La replicación Master-master puede ser muy difícil, ¿está seguro de que esta es la mejor solución para usted? Por lo general, se utiliza para fines de equilibrio de carga (por ejemplo, conexión de rutina a los servidores de base de datos) y, a veces, cuando se desea evitar el efecto de latencia de replicación. Un gran problema conocido es el problema de autoincremento que supuestamente se resuelve utilizando diferentes compensaciones y valores incrementales.

Creo que debería modificar su configuración a un maestro-esclavo simple haciendo A el maestro y B el esclavo, a menos que esté equivocado acerca de los requisitos de su sistema.

Answer 3

Recomiendo encarecidamente buscar en una herramienta que lo administre. La replicación de múltiples maestros puede ser muy problemática si las cosas van mal.

Sugeriría algo como Percona XtraDB Cluster. He estado siguiendo este proyecto, y se ve muy bien. Definitivamente creo que será un cambio de juego en el mundo de MySQL. Sin embargo, todavía está en beta.

Answer 4

Creo que se puede depender Percona XtraDB Cluster Feature 2: Multi-Master replication que la replicación normal MySQL

Prometen los ss:

por Multi-Ma ster me refiero a la capacidad de escribir en cualquier nodo de tu clúster y no te preocupes porque eventualmente saldrás de la situación de sincronización, como suele suceder con la replicación regular de MySQL si escribes imprudentemente al servidor incorrecto.

Con Cluster puede escribir en cualquier nodo, y el Cluster garantiza la coherencia de las escrituras. Es decir, la escritura está comprometida en todos los nodos o no está comprometida en absoluto.

Las dos consecuencias importantes de la arquitectura Muti-master.

Primero: podemos tener varios aplicadores trabajando en paralelo. Esto nos da una verdadera replicación paralela. El esclavo puede tener muchos subprocesos paralelos, y puede sintonizarlo mediante la variable wsrep_slave_threads

Segundo: Puede haber un pequeño período de tiempo cuando el esclavo no está sincronizado desde el maestro. Esto sucede porque el maestro puede aplicar el evento más rápido que un esclavo. Y si lees del esclavo, puedes leer datos, que aún no han cambiado. Puedes ver eso desde el diagrama. Sin embargo, puede cambiar este comportamiento utilizando la variable wsrep_causal_reads = ON. En este caso, la lectura del esclavo esperará hasta que se aplique el evento (esto aumentará el tiempo de respuesta de la lectura. Esta brecha entre el esclavo y el maestro es la razón por la cual esta replicación se llama "virtually synchronous replication", no real "synchronous replication"

El comportamiento descrito de COMMIT también tiene la segunda implicación grave Si ejecuta transacciones de escritura en dos nodos diferentes, el clúster usará un modelo de bloqueo optimista. Eso significa que una transacción no controlará posibles conflictos de bloqueo durante consultas individuales, sino más bien en la etapa de COMPROMISO. Y puede obtener una respuesta de ERROR en COMMIT.Estoy destacando esto, ya que esta es una de las incompatibilidades con InnoDB regular, que puede experimentar. En InnoDB generalmente los errores DEADLOCK y LOCK TIMEOUT suceden en respuesta a una consulta particular, pero no en COMMIT. Bueno, si sigues una buena práctica, sigues revisando el código de errores después de la consulta "COMPROMISO", pero vi muchas aplicaciones que no lo hacen.

So, if you plan to use Multi-Master capabilities of XtraDB Cluster, and run write transactions on several nodes, you may need to make sure you handle response on “COMMIT” query. 

You can find it here along with pictorial expln

Answer 5

Desde mi más amplia experiencia en este tema que se puede decir que lo lamentarás escrito a más de un maestro algún día. Puede ser pronto, puede que no sea por un largo tiempo, pero sucederá. Tendrás dos servidores que tienen datos correctos y algunos datos incorrectos, y elegirás uno como fuente autorizada y arrojarás el otro (probablemente sin saber realmente lo que estás tirando) o podrás reconciliar los dos. . No importa cómo lo diseñe, no puede eliminar la posibilidad de que esto suceda, por lo que es una certeza matemática que sucederá algún día.

Percona (mi jefe) ha manejado probablemente varios cientos de casos de recuperación después de hacer lo que estás tratando. Algunos toman horas, otros tardan semanas, uno con el que ayudé tomó unos meses, y eso con excelentes herramientas para ayudar.

utilizar una tecnología de replicación diferente o encontrar una forma diferente de hacer lo que quiere hacer. MMM no ayudará: traerá una catástrofe antes. No puede hacer esto con la replicación estándar de MySQL, con o sin herramientas externas. Necesita una tecnología de replicación de reemplazo como Continuent Tungsten o Percona XtraDB Cluster.

A menudo es más fácil simplemente resolver la necesidad real de alguna otra manera y renunciar a las escrituras con varios maestros, si desea utilizar la replicación de MySQL vainilla.

Answer 6

y gracias por compartir mi artículo cúmulo maestro-maestro de MySQL. Como Rolando aclaró, esta configuración no es adecuada para la mayoría del entorno de producción debido a la limitación del soporte de autoincrement.

La forma más adecuada para obtener un clúster MySQL está utilizando NDB, que requieren al menos 4 servidores (2 gestión y 2 nodos de datos).

He escrito un artículo detallado para obtener esta corriendo en dos servidores únicos, lo cual es muy similar a mi artículo anterior, pero utilizando en su lugar NDB.

http://www.hbyconsultancy.com/blog/mysql-cluster-ndb-up-and-running-7-4-and-6-3-on-ubuntu-server-trusty-14-04.html

en cuenta que siempre recomiendo para analizar sus necesidades y encontrar la solución más adecuada, no sólo tiene que buscar soluciones disponibles y tratar de averiguar si encajan con sus necesidades o no.

-Hatem