2012-03-28 9 views
9

Sto per migrare il nostro database di produzione su un altro server. È grande circa 38 GB e utilizza le tabelle MYISAM. Dato che non ho accesso fisico al nuovo file system del server, possiamo usare solo mysqldump.mysqldump senza interrompere la produzione live INSERTO

Ho esaminato questo sito e vedo se il backup online di mysqldump farà cadere il nostro sito Web di produzione. Da questo post: Run MySQLDump without Locking Tables, si dice ovviamente che mysqldump bloccherà il db e impedirà l'inserimento. Ma dopo alcuni test, sono curioso di scoprire che mostra il contrario.

Se uso

mysqldump -u root -ppassword --flush-logs testDB > /tmp/backup.sql 

mysqldump finirà per default fare un '--lock-tavoli', e questo è un Leggi i serrature (refer to mysql 5.1 doc), dove inserto concomitante ancora disponibile. Ho fatto un ciclo for da inserire in una tabella ogni secondo mentre mysqldump impiega un minuto per essere completato. Ogni secondo ci sarà un record inserito durante quel periodo. Il che significa che mysqldump non interromperà il server di produzione e INSERT può ancora andare su.

C'è qualcuno con esperienza diversa? Voglio assicurarmi che ciò avvenga prima di passare al mio server di produzione, quindi sarei lieto di sapere se ho fatto qualcosa di sbagliato che rende il mio test scorretto.

[La mia versione di mysql-server è 5.1.52, e mysqldump è 10.13]

+0

È necessario ottenere l'accesso al nuovo server ** PRIMO ** e probabilmente cercando la replica mysql per risolvere la migrazione. ** RICORDA: ** Puoi scaricare e installare sul nuovo server, ** BUT ** dopo aver eseguito il dump dei dati, ci sarà ** MORE ** new write, come sincronizzare la nuova scrittura sul nuovo server ? – ajreal

+0

Per la successiva scrittura di nuovi dati, lo risolveremo usando mysqlbinlog, che dovrebbe essere ben curato. Ora la mia preoccupazione principale sarà la prima volta il backup usando mysqldump. Voglio solo assicurarmi che mysqldump prevenga INSERT o meno. Dal mio test, non ha dimostrato che lo farà. Voglio solo essere sicuro di come sia l'altra esperienza. – sylye

risposta

0

mysqldump non aggiunge --lock-tabelle per impostazione predefinita. Prova a usare --lock-tables Fammi sapere se ha aiutato

BTW - dovresti usare anche i blocchi aggiuntivi che renderanno più veloce l'importazione!

+1

ciao, ho provato di nuovo ed è confermato che mysqldump di default pubblicherà --lock-tables. Due punti per dimostrarlo. Innanzitutto, 'mysqldump --help | grep lock' mostrerà 'lock-tables' è TRUE. 'mysql> con mostra tabelle aperte;' durante mysqldump, la colonna 'In_use' indica 1, e un altro mysql INSERT non lo fa girare a 2, in modo che mostri che è un LETTURA LEGGI LOCALE. Quindi la mia domanda è, c'è qualcun altro con il loro mysqldump che blocca la tabella e impedisce INSERT? perché il mio no. – sylye

1

Non l'ho mai fatto prima, ma è possibile provare --skip-add-locks durante il dumping.

Anche se potrebbe richiedere più tempo, è possibile eseguire il dump di diverse patch, ognuna delle quali richiederebbe molto poco tempo per essere completata. L'aggiunta di --skip--add-drop-table consentirebbe di caricare questi dump multipli più piccoli nella stessa tabella senza ricrearlo. L'utilizzo di --extended-insert renderebbe il file sql più piccolo da avviare.

Possibilmente provare qualcosa come mysqldump -u -p${password} --skip-add-drop-table --extended-insert --where='id between 0 and 20000' test_db test_table > test.sql. Si avrebbe bisogno di scaricare le strutture delle tabelle e caricarli in primo luogo per farlo in questo modo, o rimuovere la --skip-add-drop-table per la prima discarica

+0

ciao, grazie per il consiglio. Ma al momento la mia preoccupazione principale non è cercare di ridurre il tempo di mysqldump, dato che i dati sono troppi. La mia intenzione sarà di scoprire, 'mysqldump' preverrà INSERT o no mentre è in esecuzione. Alla ricerca di qualcuno che abbia fatto questo prima. – sylye

1

1) L'uso del --opt è lo stesso come specificato --add-drop-table, --add-locks, --create-options, --disable-keys, --extended-insert, --lock-tables, --quick e --set-charset. Anche tutte le opzioni che rappresenta --opt sono attive per impostazione predefinita perché --opt è attivato per impostazione predefinita.

2) mysqldump può recuperare e riversare il contenuto della tabella riga per riga, oppure può recuperare l'intero contenuto da una tabella e memorizzarlo nella memoria prima di eseguirlo. Il buffering in memoria può essere un problema se si stanno scaricando tabelle di grandi dimensioni. Per scaricare tabelle riga per riga, utilizzare l'opzione --quick (o --opt, che abilita --quick). L'opzione --opt (e quindi --quick) è attivata per impostazione predefinita, quindi per abilitare il buffer di memoria, utilizzare --skip-quick.

3)--single-transaction Questa opzione emette un comunicato BEGIN SQL prima di scaricare i dati dal server (tabelle transazionali InnoDB).

Se lo schema è una combinazione di entrambi InnoDB e MyISAM, seguendo l'esempio vi aiuterà a:

mysqldump -uuid -ppwd --skip-opt --single-transaction --max_allowed_packet=512M db > db.sql 
2

Ora, si può avere una base di dati con le tabelle disgiunte, o un data warehouse - dove tutto non è normalizzato (del tutto), e dove non ci sono collegamenti cosa così mai tra le tabelle. In tal caso, qualsiasi discarica funzionerebbe.

I ASSUME, che un database di produzione contenente dati 38G contiene elementi grafici in qualche forma (BLOB), e quindi - in modo ubriaco - si hanno collegamenti da altre tabelle. Destra?

Pertanto, si è - per quanto posso vedere - a rischio di perdere seri collegamenti tra tabelle (in genere coppie di chiavi primarie/estranee), quindi, è possibile acquisire una tabella al punto di essere aggiornata/inserita in , mentre il suo dipendente (che usa quella tabella come fonte primaria) non è stato ancora aggiornato. Quindi perderai la cosiddetta integrità del tuo database.

Più spesso, è estremamente ingombrante per ristabilire l'integrità, più spesso a causa di che il sistema utilizza/generazione/mantenimento del sistema di database non è stato fatto come un sistema di transazione orientata, quindi, relazioni nel database non può essere monitorato eccetto tramite le relazioni chiave primarie/estranee.

Così puoi sicuramente fare a meno di copiare il tuo tavolo senza serrature e molte delle altre proposte qui sopra - ma sei a rischio di scottarti le dita e, a seconda di quanto siano sensibili le operazioni del sistema - tu può bruciare gravemente o semplicemente graffiare la superficie.

Esempio: se il database è un sistema di database mission critical, contenente frequenza battito cardiaco raccomandato per i dispositivi di supporto alla vita in una terapia intensiva, penserei più di due volte, prima di fare la migrazione.

Se, tuttavia, il database contiene le immagini da Facebook o sito simile = si può essere in grado di vivere con le conseguenze di qualsiasi cosa, da 0 fino a 129,388 collegamenti persi :-).

Ora - tanto per l'analisi. Soluzione:

VOI DEVI creare un software che esegua il dump per voi con piena integrità, tabella impostata per tabella, tupla per tupla. Devi identificare quel gruppo di dati, che può essere copiato dalla tua attuale base online 24/7/365 alla tua nuova base, quindi farlo, quindi contrassegnare che è stato copiato.

IFFF ora cambia in mente i record che avete già copiato, avrete bisogno di fare la successiva copia di quelli. Può essere un affare complicato farlo.

IFFF si sta eseguendo una versione più avanzata di MySQL - è possibile creare effettivamente un altro sito e/o una replica o un database distribuito - e quindi farla franca, in questo modo.

IFFF avete una finestra di diciamo 10 minuti, che è possibile creare in caso di necessità, allora si può anche semplicemente copiare i file fisici, che si trova sul disco. Sto parlando di .stm .std - e così via - file - quindi puoi chiudere il server per alcuni minuti, quindi copiare.

Ora ad una domanda cardinale:

Hai bisogno di fare la manutenzione delle vostre macchine di volta in volta. Il tuo sistema non ha spazio per questo tipo di operazioni? Altrimenti, allora cosa farai, quando il disco rigido si blocca. Presta attenzione al "quando" - non "se".

+0

In che modo una dimensione del database da 38 GB implica grafica o contenuto BLOB? – MattBianco