Maestro dual de MySQL

Question

Para mi proyecto actual, estamos pensando en configurar una topología de duplicación maestra dual para una configuración separada geográficamente; uno db en la costa este de los EE. UU. y el otro DB en Japón. Tengo curiosidad si alguien ha intentado esto y qué experiencia ha habido.

Además, tengo curiosidad por saber cuáles son mis otras opciones para resolver este problema; estamos considerando colas de mensajes.

Gracias!

Answer 1

Solo una nota sobre los aspectos técnicos de su plan: Debe saber que MySQL does not officially support replicación multimaestro (solo MySQL Cluster brinda soporte para la replicación sincrónica).

Pero existe al menos un "truco" que hace posible la replicación de varios maestros incluso con una configuración de replicación de MySQL normal. Por favor, consulte "MySQL Multi-Master Replication" de Patrick Galbraith para una posible solución. No tengo ninguna experiencia con esta configuración, así que no me atrevo a juzgar sobre cuán factible sería este enfoque.

Answer 2

Hay varias cosas que considerar al replicar geográficamente las bases de datos. Si está haciendo esto por motivos de rendimiento, asegúrese de que su modelo de replicación admita que sus datos sean "finalmente consistentes", ya que puede llevar tiempo llevar la replicación actual a ambas o a muchas ubicaciones. Si su rendimiento o los tiempos de respuesta entre ubicaciones no son buenos, la replicación activa puede no ser la mejor opción.

Answer 3

Debido a la arquitectura de uno a muchos de la replicación de MySQL, debe tener un anillo de replicación con múltiples maestros: es decir, cada réplica del siguiente en un bucle. Para dos, se replican el uno al otro. Esto ha sido soportado desde la v3.23.

En un lugar anterior en el que trabajé, lo hicimos con v3.23 con bastantes clientes como una forma de proporcionar exactamente lo que está pidiendo. Usamos túneles SSH a través de Internet para hacer la replicación. Nos llevó algo de tiempo conseguir que fuera confiable y varias veces tuvimos que hacer una copia binaria de una base de datos a otra (afortunadamente, ninguna de ellas tenía más de 2 GB ni un acceso de 24 horas). Además, la replicación en v3 no fue tan estable como en v4, pero incluso en v5, simplemente se detendrá si detecta algún tipo de error.

Para acomodar el inevitable retraso de replicación, reestructuramos la aplicación para que no se basara en los campos AUTOINCREMENT (y eliminamos ese atributo de las tablas). Esto fue razonablemente sencillo debido a la capa de acceso a datos que habíamos desarrollado; en lugar de usar mysql_insert_id() para objetos nuevos, primero creó la nueva ID y la insertó junto con el resto de la fila. También implementamos identificaciones de sitios que almacenamos en la mitad superior de la ID porque eran BIGINT s. Esto también significaba que no teníamos que cambiar la aplicación cuando teníamos un cliente que quería la base de datos en tres ubicaciones. :-)

No era 100% robusto. InnoDB estaba ganando algo de visibilidad por lo que no podíamos usar transacciones fácilmente, aunque lo consideramos. Entonces, ocasionalmente, había condiciones de carrera cuando dos objetos intentaban crearse con la misma ID. Esto significó una falla y tratamos de informar eso en la aplicación. Pero todavía era una parte importante del trabajo de alguien vigilar la replicación y arreglar las cosas cuando se rompió. Es importante que lo solucionemos antes de que nos desincronicemos demasiado, porque en algunos casos las bases de datos se estaban usando en los ambos sitios y se volverían difíciles de volver a integrar rápidamente si tuviéramos que reconstruir uno.

Ha sido un buen ejercicio para ser parte de, pero no volvería a hacerlo. No en MySQL

Answer 4

Configurar mysql como maestro dual realmente funciona bien en el escenario correcto hecho correctamente. Pero no estoy seguro de que encaje muy bien en su escenario.

En primer lugar, la configuración dual master en mysql es realmente una configuración de anillo. El servidor A se define como maestro de B, mientras que B se define al mismo tiempo como el maestro de A, por lo que ambos servidores actúan como maestro y esclavo. La replicación funciona enviando un registro binario que contiene las sentencias sql que el esclavo inserta cuando lo considera apropiado, lo que generalmente ocurre de inmediato. Pero si lo estás martillando con inserciones locales, tomará un tiempo para ponerse al día. Las inserciones de esclavos son secuenciales por cierto, por lo que no obtendrá ningún beneficio de múltiples núcleos, etc.

El uso principal de dual master mysql es tener redundancia en el nivel del servidor con conmutación por error automática (a menudo usando hearbeat en linux). Excluyendo mysql-cluster (por varias razones), esta es la única failover automática utilizable para mysql. La configuración para maestro dual básico se encuentra fácilmente en google. Los latidos son un poco más de trabajo. Pero esto no es realmente lo que preguntabas, ya que esto realmente se comporta como un único servidor de base de datos.

Si desea la configuración maestra dual porque siempre desea escribir en una base de datos local (escríbalas a las dos al mismo tiempo), tendrá que escribir su aplicación teniendo esto en cuenta. Nunca puede tener valores de incremento automático en la base de datos, y cuando tiene valores únicos, debe asegurarse de que las dos ubicaciones nunca escriban el mismo valor. Por ejemplo, la ubicación A podría escribir números únicos impares y la ubicación B podría escribir incluso números únicos. La razón es que no se garantiza que los servidores estén sincronizados en un momento dado, por lo que si ha insertado una fila única en A y luego una fila única superpuesta en B antes de que el segundo servidor alcance la tener un sistema roto Y si algo se rompe por primera vez, todo el sistema se detiene.

Para resumir: es posible, pero tendrá que inclinarse muy cuidadosamente si está construyendo un software empresarial además de esto.