Come risincronizzare il Master MySQL DB con le modifiche Slave DB se il Master non è in linea?

MySQL Server 1 funziona come Master.
MySQL Server 2 funziona come Slave.

Con entrambi i DB online, sono in "perfetta sincronizzazione". Se Slave non è in linea, non c'è problema se Master è ancora in linea; torneranno sincronizzati una volta che lo Slave è di nuovo online.

Oltre alla configurazione del server, ho reindirizzato la connessione (con codice JSP) per lo Slave DB se il Master non è in linea (ho testato ovviamente con /etc/init.d/mysqld stop).

Quando il Master torna online, esiste un metodo automatico per sincronizzare il Master con gli aggiornamenti Slave?

Un buon modo per realizzare qualcosa di tale natura è impostare la replica master-master o la replica circolare. Questo non deve essere confuso con MultiMaster Replciation.

L'impostazione della replica circolare è estremamente semplice se è stata impostata la replica master-slave. Ecco cosa devi fare per configurarlo.

Per questo esempio, supponiamo che la replica Master-Slave sia attiva ma si verificheranno dei tempi di inattività (1-2 minuti):

Passaggio 1) Aggiungi questa riga a /etc/my.cnf sul Master.

log-schiavi aggiornamenti

Passaggio 2) Aggiungi questa riga a /etc/my.cnf sullo Slave:

log-bin = mysql-bin (o ha tutto ciò che il master ha per questo) log-slave-updates

ATTENZIONE: ecco il breve momento di inattività !!!

Passaggio 3) Sullo slave, riavvia il servizio mysql

Ciò attiverà i registri binari sullo Slave

Passaggio 4) Sul Master, servizio mysql stop

Passaggio 5) Utilizzare rsync per copiare la cartella / var / lib / mysql dello Slave sul Master.

ATTENZIONE: ecco il momento più lungo di downtime !!!

Passaggio 6) Sullo slave, servizio mysql stop

Passaggio 7) Sullo slave, scoprire l'ultimo registro binario

Passaggio 8) Sullo slave, individuare la dimensione del file dell'ultimo registro binario

Passaggio 9) Utilizzare rsync per copiare la cartella / var / lib / mysql dello Slave sul Master. Questa dovrebbe essere una copia più veloce.

Step 10) Sul Master, modifica la
Linea 2 di master.info con l'ultimo registro binario dello Slave.
Riga 3 di master.info con la dimensione del file dell'ultimo registro binario dello Slave.
Riga 4 di master.info con l'IP dello slave.
La riga 5 è l'ID utente dell'utente di replica (NON TOCCARE) La
riga 6 è la password dell'utente di replica (NON TOCCARE)

Passaggio 11) Elimina tutti i registri binari e il file indice dei registri binari del Master.

Passaggio 12) Su Slave, avviare il servizio mysql, attendere 15 secondi

Passaggio 13) Sul Master, avviare mysql di servizio

Passaggio 14) Sul Master, eseguire STOP SLAVE; MOSTRA STATO MASTER;

Passaggio 15) Sullo slave, eseguire CHANGE MASTER TO MASTER_HOST = 'IP dello slave', MASTER_USER = 'userid dell'utente di replica da Step10', MASTER_PASSWORD = 'password dell'utente di replica da Step10', MASTER_LOG_FILE = 'registro binario da Step14', MASTER_LOG_POS = LogPos dal passaggio 14.

Passaggio 16) Sullo slave, avviare START SLAVE;

Step 17) Sul Master, esegui START SLAVE;

Ho eseguito passaggi simili a questo per un'altra domanda StackExchange a cui ho risposto .

Provaci !!!

Non con la replica asincrona che è ciò che offre MySQL. Hai appena colpito il proverbiale chiodo del perché la replica MySQL "out of the box" (pre 5.5) non è una soluzione ad alta disponibilità in sé e per sé. Le cose migliorano leggermente con 5.5 con replica semi-sincrona (http://dev.mysql.com/doc/refman/5.5/en/replication-semisync.html) ma a costo di tempi di transazione più lenti mentre il master attende il ack da schiavo.

Se accettare la possibilità di perdita di dati quando il master si arresta non è un'opzione, direi che un'impostazione più sofisticata rispetto al semplice master / slave è in ordine.

La replica da master a master è stata considerata più un problema che un vantaggio da molte persone famose di MySQL (anche MySQL AB stesso non lo consiglia più come soluzione ad alta disponibilità). Quindi, penso che usare la configurazione DRBD per mantenere sincronizzati il ​​master attivo e lo slave passivo usando copie a livello di blocco sia ciò di cui hai effettivamente bisogno qui.

IMHO, Prima di tutto, in una configurazione non multi-master (master / slave), il tuo slave non dovrebbe mai scrivere. Lo slave my.cnf deve essere configurato e il server deve essere avviato con:

# Flag to not take writes from network
read-only

Successivamente, per curare il problema di un master fuori sincrono con uno slave scrivibile che esegue accidentalmente delle scritture, è necessario diff diffondere i dati su entrambi gli host. Se non ci sono collisioni chiave, dovresti promuovere il tuo precedente host slave a master e re-immagine del tuo vecchio master come host slave che si replica dal nuovo master. (potrebbero esserci / probabilmente ci sono problemi di dati qui)

Infine, se questo scenario di interruzione / downtime è persino una possibilità futura , prenditi il ​​tempo necessario per impostare entrambi gli host come multi-master (log-bin, ID server, offset, ecc.). Ciò ti aiuterà a mitigare in qualche modo interruzioni e tempi di inattività.

Se devi eseguire master / slave , almeno ottieni alcuni punti bonus per separare le connessioni utente di lettura e scrittura nella tua ACL e nelle tue applicazioni.