Retraso de replicación de Master-Master MySQL

He configurado dos serveres MySQL ( MySQL-1 , MySQL-2 ) en replicación master-master en el mismo datacenter usando una connection de backend local con las siguientes opciones:

 innodb_flush_log_at_trx_commit=1 sync_binlog=1 

Utilizamos un equilibrador de carga para networkingondear las requestes de MySQL de un lado a otro igualmente entre los dos serveres MySQL. Esto funciona muy bien, pero me preocupa el retraso de replicación. Por ejemplo, si el usuario A inserta una fila en MySQL-1, entonces el usuario A selecciona desde MySQL-2, es posible que los datos no hayan sido replicados satisfactoriamente.

Básicamente, mi pregunta es, ¿cuánto retraso debe esperarse (milisegundos, segundos)? ¿Son más sus opciones de MySQL para establecer para prevenir / networkingucir el retraso?

3 Solutions collect form web for “Retraso de replicación de Master-Master MySQL”

Esto depende del performance de los serveres, que está relacionado con cuántas consultas tiene que procesar cada server, cuán grandes son sus tablas y así sucesivamente. El uso de dicha solución de replicación debe ser síncrono, lo que definitivamente impone algún retraso durante las transactions. Esto es simplemente porque cada transacción no debe considerarse completamente comprometida a less que se haga en ambos nodos.

Creo que una opción más segura es equilibrar las requestes basadas en la IP de origen del cliente (si esto es soportado / posible). En este caso, todas las requestes procedentes del mismo cliente serán reenviadas al mismo server DB.

He encontrado exactamente este problema con un maestro -> configuration de muchos esclavos. Era incluso peor que su situación porque las lecturas se garantizaron venir del esclavo más bien que tener una ocasión 50/50.

Cada vez que un usuario escribió a la database (como un post en el foro o haciendo clic en un button "como") obtendría una networkingirección HTTP a la página que debería mostrar su post, pero nunca lo hizo. El time de ida y vuelta del redirect y la request de seguimiento fue menor que el retraso de replicación.

Viendo el retraso con SHOW SLAVE STATUS demostró que casi siempre estaba por debajo de un segundo. Sin embargo, se hizo más alto que eso ocasionalmente. Dado que la replicación SQL es de subprocess único, una consulta lenta de 10 segundos provocará un retraso de 10 segundos en la replicación.

La solución para nosotros terminó siendo modificar todas nuestras páginas "recién publicadas" para leer siempre desde el maestro en lugar de un esclavo. En su caso, asegurarse de que cada server web sabe qué database de la request anterior sólo escribió a será difícil.

Una solución mejor podría ser pegar datos recientemente escritos en una instancia de memcached. Incluso si los datos de memcached tienen un time de expiración de 10 segundos, debería ser suficiente para cubrir el retraso de replicación.

El retraso depende de:

  1. el número de operaciones de escritura (insert y actualizar)
  2. hardware (velocidad del disco y CPU)
  3. carga del server (selección)

Es imposible calcular el retraso antes. Puedo sugerir que realice algunas testings intensivas (para usted) con operaciones de lectura y escritura de simultaneidad.

  • ¿Cuál es la manera más fácil de mover mysql de la caja de linux uno mi cuadro local de Vista?
  • mk-table-sync en un escenario maestro-esclavo: Cambios no replicados en el esclavo
  • configuration mysql master-slave con replicación sincrónica
  • MySQL, comparación de replicación de Postgresql
  • Esclavo de MySQL fuera de sincronización con el maestro
  • Prueba de la replicación / synchronization de bases de datos MySQL
  • Migración de serveres maestro-esclavo de database MySQL a 2 nuevos serveres, consejos o sugerencias?
  • Magento> Slave se rompe cuando un producto se agrega desde el master
  • Restablecimiento de la replicación esclava de MySQL sin tiempo de inactividad principal (utilizando MyISAM)
  • mySQL 'Stop Slave' en el reinicio del server
  • MAMP MySql Master esclavo de replicación en la máquina local
  • Replicación MySQL y priorización UPDATE
  • Redundante FreeRADIUS + MySQL
  • El linux y los temas del servidor de Windows, como ubuntu, centos, apache, nginx, debian y consejos de red.