Binlog MySQL Replication es una & # 8220; Bag of Hurt & # 8221 ;. ¿Hay alguna buena alternativa?

Question

Honestamente, intenté this left y right y aún así encuentro que mi servidor espejo, configurado como un esclavo de replicación, todavía se queda atrás. La base de usuarios de mi aplicación sigue creciendo y ahora he llegado al punto en el que no puedo seguir " cerrando " para "resincronizar" bases de datos (ni siquiera los fines de semana).

De todos modos, mi pregunta: ¿hay alguna alternativa plausible, asequible para la replicación de binlog? Tengo dos servidores, por lo que no consideraría comprar un tercero para el equilibrio de carga todavía, a menos que sea la única opción.

Saludos,

/ mp

Answer 1

Su maestro se ejecuta en paralelo y su esclavo se ejecuta en serie. Si su maestro puede procesar 1.5 horas de inserciones / actualizaciones / ejecuciones en 1 hora real, su esclavo se retrasará.

Si no puede encontrar formas de mejorar el rendimiento de escritura en su esclavo (más memoria, discos más rápidos, eliminar índices innecesarios), ha alcanzado una limitación en la arquitectura de sus aplicaciones. Eventualmente llegará a un punto en el que no podrá ejecutar los cambios en tiempo real tan rápido como su maestro pueda ejecutarlos en paralelo.

Muchos sitios grandes fragmentan sus bases de datos: considere dividir su maestro + esclavo en múltiples grupos maestro + esclavo. Luego, divida su base de clientes en estos grupos. Cuando un esclavo comienza a quedarse atrás, es hora de agregar otro grupo.

No es barato, pero a menos que pueda encontrar una manera de hacer que la replicación binlog ejecute declaraciones en paralelo, probablemente no encontrará una mejor manera de hacerlo.

Actualización (2017) : MySQL ahora admite hilos paralelos de trabajadores esclavos . Todavía hay muchas variables que harán que un esclavo se quede atrás, pero los esclavos ya no necesitan escribir en orden serial. Elegir preservar el orden de confirmación de los hilos esclavos paralelos es una opción importante para ver si el estado exacto del esclavo en algún momento es crítico.

Answer 2

¿Has probado: 1) SET innodb_flush_log_at_trx_commit = 0 2) SET sync_binlog = 0

Ambos ayudarán a acelerar su Slave con un pequeño nivel de riesgo adicional si tiene una falla en el servidor.

Answer 3

Agregar memoria al esclavo probablemente ayudaría. Pasamos de 32 a 128 megas y el retraso se fue más o menos. Pero no es barato ni será suficiente en todas las situaciones.

Sin embargo, comprar un tercer servidor probablemente no ayude tanto, lo más probable es que obtenga otro esclavo rezagado.