Replica di MySQL su server geograficamente separati

La mia organizzazione ha studiato come distribuire geograficamente i nostri server mantenendo aggiornati i backup e ripartendo idealmente il carico.

La cosa iniziale che ho in mente è Rails su MySQL. Il tasso di scrittura non è troppo elevato (articoli / commenti vengono lasciati a meno di 1 al minuto, sebbene alcuni abbiano allegati multimediali di grandi dimensioni).

Così,

• la replica di MySQL funziona bene su reti geografiche?
• La connessione (o un server slave) in corso significa che è necessario un intervento manuale (quando i due server possono parlare di nuovo tra loro) o il ripristino è automatico?
• Se il master scompare, cosa è necessario per trasformare uno slave in un master? Ci sono script / strumenti standard per aiutare a gestirlo?
• Qualche altro gotchas ecc.?

Usiamo la replica attraverso data center in diversi paesi europei (quindi non sono in tutto il mondo l'uno dall'altro, ma certamente non sono locali) e funziona senza problemi.

La replica verrà riavviata automaticamente, se possibile. Se si verifica un problema con una query (ad esempio un database è presente sul master e non sullo slave e una query lo utilizza), per impostazione predefinita richiederà la correzione manuale (ma è possibile impostarlo per ignorare tali errori). Se i database sono mirror esatti, non è necessario riavviare manualmente la replica.

Se hai due server e il master scompare, quindi per trasformare lo slave in "master", basta interrompere la replica e modificare il codice (per scrivere sul nuovo "master"). Se si dispone di tre o più server e il master scompare, quindi interrompere la replica sugli slave, modificarli per utilizzare il nuovo master e ricominciare. Se non sono esattamente sincronizzati (dipende da quanti dati vengono trasferiti, da quanto sono occupati i server, da quanto è buona la connessione di rete, ecc.), Allora potresti dover fare più lavoro di così. La sezione di replica della documentazione MySQL tratta questo in modo più dettagliato .

Suggerirei di assicurarti di replicare su SSL (ovvero impostare l'utente di replica affinché richieda una connessione SSL).

La replica è cambiata radicalmente in MySQL 5.1. In 5.0 è stata utilizzata solo la replica basata su istruzioni. Ora hai la possibilità di eseguire la replica basata su riga o la replica basata su misto. Ciò influirà notevolmente sulla modalità di replica su una WAN.

Se hai la possibilità di: A) Controllare l'IP (se i tuoi server sono separati geograficamente, questo non è probabile) B) Apporta agili modifiche al DNS Puoi evitare di modificare il codice / configurazione dell'app per cambiare i master. Utilizziamo DNS interno con cache breve e domini .internal falsi. Se abbiamo bisogno di cambiare masterdb.internal per essere un altro server, in 5 secondi la modifica propaga.

All'interno di un singolo data center utilizziamo il controllo dell'IP. Tutti i server DB hanno interfacce virtuali (eth0: 1, eth0: 2, eth0: 3) che non vengono avviati all'avvio. Se uno degli schiavi deve subentrare, basta solo eth0: 2 ed è il padrone. In questo scenario, eth0 è il 'se' che usiamo per sgusciare e così via. Le app si connettono su eth0: 1 che non verrà attivato all'avvio se il mio script rileva che l'IP è stato preso. (wikipedia STONITH) Gli altri if servono a rilevare gli IP dei master che potrebbero dover eseguire il failover.

Non consiglierei di attraversare gli oceani quando si utilizza una replica di MySQL. Ho provato una volta a replicare da un maestro in Europa mentre lo schiavo era in Texas. La replica si è interrotta quasi ogni giorno fino a quando non abbiamo abbandonato questo progetto. Ovviamente può funzionare, ma tende a diventare più fragile quanto maggiore è la distanza tra il padrone e lo schiavo.