MySQL dual master

Question

Per il mio progetto attuale stiamo pensando di impostare una topologia di replica a doppio master per una configurazione geograficamente separata; un db sulla costa orientale degli Stati Uniti e l'altro db in Giappone. Sono curioso di sapere se qualcuno ha provato questo e quale esperienza c'è stata.

Inoltre, sono curioso di sapere quali sono le mie altre opzioni per risolvere questo problema; stiamo prendendo in considerazione le code dei messaggi.

Grazie!

Answer 1

Solo una nota sugli aspetti tecnici del tuo piano: devi sapere che MySQL non supporta ufficialmente la replica multi-master (solo MySQL Cluster fornisce supporto per la replica sincrona).

Ma esiste almeno un "hack" ciò rende possibile la replica multi-master anche con una normale configurazione di replica MySQL. Per una possibile soluzione, consultare " MySQL Multi-Master Replication " di Patrick Galbraith. Non ho alcuna esperienza con questa configurazione, quindi non oso giudicare quanto sarebbe fattibile questo approccio.

Answer 2

Ci sono molte cose da considerare quando si replicano geograficamente i database. Se lo stai facendo per motivi di prestazioni, assicurati che il tuo modello di replica supporti che i tuoi dati siano "eventualmente coerenti". poiché può richiedere del tempo per portare la replica in corrente in entrambe o in molte posizioni. Se la velocità effettiva o i tempi di risposta tra le posizioni non sono buoni, la replica attiva potrebbe non essere l'opzione migliore.

Answer 3

L'impostazione di mysql come doppio master funziona davvero bene nello scenario giusto fatto correttamente. Ma non sono sicuro che si adatti molto bene al tuo scenario.

Prima di tutto, la doppia configurazione principale in mysql è davvero una configurazione ad anello. Il server A è definito come master di B, mentre B è contemporaneamente definito come master di A, quindi entrambi i server agiscono sia come master che come slave. La replica funziona inviando un registro binario contenente le istruzioni sql che lo slave inserisce quando lo ritiene opportuno, che di solito è subito. Ma se lo stai martellando con inserimenti locali, ci vorrà un po 'per recuperare. Gli inserimenti degli slave sono sequenziali tra l'altro, quindi non otterrai alcun vantaggio da più core ecc.

L'uso primario di dual master mysql è la ridondanza a livello di server con fail-over automatico (spesso usando hearbeat su Linux). Escludendo mysql-cluster (per vari motivi), questo è l'unico failover automatico utilizzabile per mysql. La configurazione per il doppio master di base è facilmente reperibile su google . La roba del battito cardiaco è un po 'più di lavoro. Ma questo non è proprio quello che ti chiedevi, dal momento che si comporta davvero come un singolo server di database.

Se si desidera la configurazione del doppio master perché si desidera sempre scrivere su un database locale (scrivere su entrambi contemporaneamente), è necessario scrivere l'applicazione tenendo presente questo. Non è mai possibile avere valori a incremento automatico nel database e quando si hanno valori univoci, è necessario assicurarsi che le due posizioni non scrivano mai lo stesso valore. Ad esempio, la posizione A potrebbe scrivere numeri univoci dispari e la posizione B potrebbe scrivere anche numeri univoci. Il motivo è che non hai la garanzia che i server siano sincronizzati in qualsiasi momento, quindi se hai inserito una riga univoca in A e quindi una riga univoca sovrapposta in B prima che il secondo server raggiunga, dovrai avere un sistema rotto. E se qualcosa si rompe per la prima volta, l'intero sistema si arresta.

Riassumendo: è possibile, ma dovrai fare molta attenzione se stai costruendo un software aziendale.

Answer 4

A causa dell'architettura uno-a-molti della replica di MySQL, è necessario disporre di un anello di replica con più master: vale a dire, ciascuno si replica dal successivo in un ciclo. Per due, si replicano l'un l'altro. Questo è stato supportato fin dalla v3.23.

In un posto precedente in cui ho lavorato, lo abbiamo fatto con v3.23 con un numero piuttosto elevato di clienti come un modo per fornire esattamente ciò che stai chiedendo. Abbiamo usato i tunnel SSH su Internet per eseguire la replica. Ci è voluto del tempo per renderlo affidabile e diverse volte abbiamo dovuto fare una copia binaria di un database in un altro (fortunatamente, nessuno di loro era superiore a 2 Gb né necessitava di un accesso di 24 ore). Inoltre, la replica in v3 non era quasi stabile come in v4 ma anche in v5, si fermerà solo se rileva qualche tipo di errore.

Per compensare l'inevitabile ritardo di replica, abbiamo ri-strutturato l'applicazione in modo che non si basasse sui campi AUTOINCREMENT (e abbiamo rimosso quell'attributo dalle tabelle). Ciò era ragionevolmente semplice grazie al livello di accesso ai dati che avevamo sviluppato; invece di usare mysql_insert_id () per i nuovi oggetti, ha creato prima il nuovo ID e lo ha inserito insieme al resto della riga. Abbiamo anche implementato gli ID del sito che abbiamo archiviato nella metà superiore dell'ID, poiché erano BIGINT . Ciò significava anche che non dovevamo cambiare l'applicazione quando avevamo un client che voleva il database in tre posizioni. : -)

Non era robusto al 100%. InnoDB stava solo guadagnando visibilità, quindi non potevamo facilmente usare le transazioni, sebbene lo considerassimo. Quindi c'erano condizioni di gara occasionalmente quando due oggetti cercavano di essere creati con lo stesso ID. Ciò significa che uno non è riuscito e abbiamo provato a segnalarlo nell'app. Ma era ancora una parte significativa del lavoro di qualcuno sorvegliare la replica e sistemare le cose quando si è rotto. È importante sottolineare che per risolverlo prima che ci fossimo allontanati troppo dalla sincronizzazione, perché in alcuni casi i database venivano utilizzati in entrambi e sarebbero rapidamente difficili da reintegrare se dovessimo ricostruirne uno.

È stato un buon esercizio far parte, ma non lo rifarei. Non in MySQL.