Crea uno slave MySQL da un altro slave, ma puntalo sul master


8

Problema

Ho una configurazione di replica MySQL tra 2 server, master ( A ) e slave ( B ). Devo aggiungere un nuovo slave al mix ( C ). Voglio che questo slave ottenga i suoi aggiornamenti direttamente dal master, non voglio la replica a catena dallo slave. Tuttavia, il master è "caldo", di solito uso Xtrabackup per creare un backup completo del master, ma questo lo bloccherà per ben 10 minuti, poiché il database ha una dimensione di circa 20 GB.

Possibile soluzione

FLUSH TABLES CON READ LOCK sullo slave B , utilizzare SHOW SLAVE STATUS su B , annotare binlog e posizionare. Quindi eseguire il backup del database con Xtrabackup, inviare il backup a C e utilizzarlo per creare lo slave e impostare la replica in modo che punti ad A con la posizione binlog che ho appena annotato.

Domanda

C'è un modo migliore che non mi richiede di bloccare B per così tanto tempo? O qualcosa che è più facilmente automatizzato?

Risposte:


20

Ehi, conosco un metodo pazzo per creare uno slave senza aumentare alcuna operazione di master (ServerA) o slave (ServerB)

Passaggio 1) Configurare un nuovo server (ServerC)

Passaggio 2) Su ServerC, installa MySQL (stessa versione di ServerB)

Passaggio 3) Su ServerC, servizio mysql stop

Passaggio 4) Copia /etc/my.cnf da ServerB a ServerC

Passaggio 5) Su ServerC, modificare server_id su un valore diverso da ServerA e ServerB

Passaggio 6) rsync / var / lib / mysql su ServerB su ServerC

Passaggio 7) Al termine di rsync, eseguire "STOP SLAVE;" su ServerB

Passaggio 8) rsync / var / lib / mysql su ServerB su ServerC

Passaggio 9) Su ServerB, eseguire "START SLAVE;"

Passaggio 10) Su ServerC, avviare mysql di servizio

Passaggio 11) Su ServerC, eseguire "START SLAVE;" (Fallo se skip-slave-start è in /etc/my.cnf)

Provaci !!!

A proposito, ho la massima fiducia che funzionerà perché l'ho appena fatto per il cliente negli ultimi 2 giorni. Il client aveva 2,7 TB di dati su uno slave. Rsyncd su un altro server mentre lo slave era ancora attivo. rsync ha impiegato circa 11 ore. Ho quindi eseguito STOP SLAVE; sul primo slave e ha eseguito di nuovo rsync. Ci è voluta un'altra ora. Ho quindi eseguito il passaggio sopra e tutto è fatto.


LOL. Stavo per commentare l'OP per usare il tuo suggerimento, e in basso e vedere il suo signor Rolando DBA "Frigo". Rolando ha colpito l'unghia sulla testa e questo è il metodo preferito senza dover fermare alcun Master e senza fermare il tuo schiavo B per un periodo troppo lungo.
coderwhiz

2
So che questo è un post abbastanza vecchio ma qualcuno mi ha chiesto di questo metodo. Funziona bene supponendo che il nuovo slave e il vecchio slave siano ESATTAMENTE gli stessi. Se il nuovo slave è un arco diverso, non funzionerà (iirc). E sono quasi sicuro che se stai usando tablespace innodb per file non funzionerà. La soluzione più sicura è fare un backup completo dal master in caso di dubbi.
lusis,

@lusis - Il tuo commento è molto vero. In un mondo perfetto, che la maggior parte dei client mysql immagina di avere, vogliono che ciò avvenga poiché tutte le specifiche hardware sono identiche. Nelle configurazioni in cui l'hardware differisce, mysqldumps e ricaricare è il più sicuro. Dovresti inviare il tuo commento come risposta. Lo voterei. Vediamo se gli altri lo faranno !!!
RolandoMySQLDBA

Ho seguito la procedura. Dopo aver riavviato mysql su SlaveC, viene visualizzato il messaggio "Il database potrebbe essere corrotto o è possibile che sia stato copiato il tablespace InnoDB ma non i file di registro InnoDB". E su start slave(SlaveC) ottengo "Impossibile aprire il registro di inoltro '/var/log/mysql/mysql-relay-bin.001603"
Hussain Tamboli

In questo modo è possibile perdere facilmente i dati su ServerC.
Akuzminsky,

3

Quando aggiungiamo uno slave al nostro mix, facciamo quanto segue:

  • portare uno slave offline
  • copiare la directory dei dati del database nel nuovo slave (le impostazioni degli slave-posizione del registro, host principale ecc.) saranno corrette poiché abbiamo copiato da uno slave)
  • avviare lo slave originale
  • modifica id server in my.cnf per il nuovo slave
  • avviare un nuovo schiavo

Ho dovuto farlo da solo questo pomeriggio
sreimer

1

Ho fatto ciò che suggerisce @RolandoMySQLDBA ma aggiungendo anche un 6 ' e un 8' passaggi (questo risolve ciò che commenta @Hussain Tamboli .):

Passaggio 1) Configurare un nuovo server (ServerC)

Passaggio 2) Su ServerC, installa MySQL (stessa versione di ServerB)

Passaggio 3) Su ServerC, servizio mysql stop

Passaggio 4) Copia /etc/my.cnf da ServerB a ServerC

Passaggio 5) Su ServerC, modificare server_id su un valore diverso da ServerA e ServerB

Passaggio 6) rsync / var / lib / mysql su ServerB su ServerC

Passaggio 6 ') rsync / var / log / mysql su ServerB su ServerC

Passaggio 7) Al termine di rsync, eseguire "STOP SLAVE;" su ServerB

Passaggio 8) rsync / var / lib / mysql su ServerB su ServerC

Passaggio 8 ') rsync / var / log / mysql su ServerB su ServerC

Passaggio 9) Su ServerB, eseguire "START SLAVE;"

Passaggio 10) Su ServerC, avviare mysql di servizio

Passaggio 11) Su ServerC, eseguire "START SLAVE;" (Fallo se skip-slave-start è in /etc/my.cnf)


la tua risposta non è completa e fa riferimento ad altre cose. non è un forum, migliora la tua risposta per essere completo da solo.
asdmin,

0

Hai l'opzione "CARICARE DATI DA MASTER" ma questo è altamente sconsigliato.

Effettuate backup notturni / settimanali sul vostro sistema? In tal caso, annotare anche la posizione con il backup, quindi è possibile utilizzare quel backup per impostare un nuovo slave. Lascialo e lascia che si aggiorni da tempo.


0

Ho provato le risposte di Rolando e ha funzionato bene, ma è stato iniziato a riprodurre dall'inizio e ho dovuto aggiungere altro codice di errore per saltare (so che non è raccomandato, ma so cosa stavo facendo).

Una volta terminato il passaggio 7, ho controllato il registro mysql e annotato il nome e la posizione del registro bin e ho continuato fino al 9 ° passaggio. Prima del decimo passaggio, ho appena eseguito il change masterfile di registro e la posizione del registro. E ha continuato dal punto 11. Tutto mi sembra a posto.


-2

È necessario modificare lo slave uuid in auto.cnf in modo che il master possa differenziare i due slave.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.