Mysqldump incompleta

Sto cercando di eseguire mysqldump per creare un'istantanea del database e trovo che si fermerà casualmente a metà strada, senza segnalare alcun errore. Il mio database è relativamente piccolo (circa 100 MB) e utilizza InnoDB.

Lo sto eseguendo come:

mysqldump --force --single-transaction --quick --user myuser --password=mypass -h mydatabasehost mydb > /tmp/snapshot.sql

Verifica dei rapporti sul codice di uscita 0.

La mia versione è: mysqldump Ver 10.13 Distrib 5.1.52, per redhat-linux-gnu (i386)

Ho visto alcuni post simili e persino una segnalazione di bug ufficiale , ma nessuna soluzione sembra applicarsi.

Come faccio a ottenere mysqldump per realizzare uno snapshot completo del database?

EDIT: il mio database attualmente risiede su RDS di Amazon.

Potrebbe essere stato un problema max_allowed_packetnon essere impostato su un livello sufficientemente elevato sia sul client (ad esempio mysqldump) che sul server (ad esempio Amazon RDS). Ho impostato questo su 500M su entrambi e sembra aver risolto il problema.

Poiché le tabelle dello schema di informazioni di InnoDB forniscono solo stime del conteggio delle righe, è difficile stabilire se la mia istantanea includa davvero tutto da RDS. Tutte le tabelle sono presenti, ma i conteggi delle righe differiscono. Aggiornerò con una risposta più definitiva quando avrò del tempo per scrivere un'analisi più approfondita.

Hai provato?

mysqldump --compress --add-drop-table data --routines --events  --comments --extended-insert -h {host} -u {user} -p {database} > dbdump.sql

Questo è semplice come lo faccio sempre senza problemi. Fondamentalmente facendo il dump in questo modo ottieni tutto ciò che hai (dati, oggetti e talvolta preziosi commenti) in un determinato momento ignorando le transazioni non impegnate.

Per quanto ho capito i documenti di mysql - la transazione singola fallirà se una lettura viene eseguita sul tavolo mentre stai scaricando. Qual è il risultato quando si esegue senza "--force --single-transazione --quick"?

È del tutto possibile che la tabella sia corrotta. Non intendo dire che i dati e / o le pagine dell'indice siano danneggiati. Potrebbe esserci qualcosa di molto semplice che è rotto.

Di recente ho riscontrato un problema con uno script di backup su uno Slave Server quando parallelamente mysqldumping più database. L'esecuzione di mysqldump su uno dei database ha comportato un mysqldump molto piccolo. Il DB aveva oltre 80 tabelle. Tuttavia, mysqldump si è fermato alla quinta tabella nel DB. Quando ho eseguito SHOW CREATE TABLE tblname\Gsul tavolo sullo Slave, ho ricevuto l'errore "Tabella non trovata". Quando correvo SHOW CREATE TABLE tblname\Gsul Master, la descrizione della tabella veniva visualizzata come previsto.

Quello che è successo è stato un po 'folle: un client ha chiesto un ripristino della tabella e un ingegnere ha ripristinato il file .ibd della tabella InnoDB da un backup del disco. L'ID tablespace del file .ibd (che era 25) non corrispondeva all'ID tablespace registrato in ibdata1 (che era 28).

Ho risolto il problema eliminando lo slave, mysqldumping del master e configurando la replica da zero. Fortunatamente, lo spave di dati e indici è stato di 7 GB. Quindi il processo di rstore non è stato un grosso problema.

MORALE DELLA STORIA

Il problema di base è che mysqldump non segnala un errore su InnoDB quando l'id del tablespace non è corretto. Quando un mysqldump termina e non esegue il dump di tutte le tabelle in ordine alfabetico, ciò indica che è stato terminato da un errore e lo ha fatto senza stampare un messaggio di errore.

Verificare per assicurarsi

• puoi visualizzare la struttura della tabella usando SHOW CREATE TABLE
• puoi eseguire una query su tutto ciò che riguarda una tabella da INFORMATION_SCHEMA.TABLES

Quello che segue è solo un po 'di brainstorming su mysqldump e InnoDB:

Pensa al comportamento di mysqldump rispetto a una tabella InnoDB. Se ci sono pagine sporche nel pool di buffer InnoDB appartenenti a una tabella che si sta scaricando, le pagine sporche di tale tabella devono essere scaricate sul disco prima di SELECT /* SQL_NO_CACHE */poter eseguire una contro.

Dal momento che stai usando Amazon RDS, la mia impressione è che il tuo database sia in un'infrastruttura multi-tenant (sentiti libero di correggere questa affermazione se sto semplificando troppo). Altri database potrebbero utilizzare un pool di buffer InnoDB condiviso, un file di metadati condiviso (ibdata1) e un tablespace condiviso (ibdata1 se innodb_file_per_table è disabilitato).

Potrebbe anche verificarsi una ridondanza del database in corso, che potrebbe influire su MVCC rispetto al database, anche se si tratta di un piccolo set di dati.

Potresti voler aumentare innodb_lock_wait_timeout (impostazione predefinita 50 secondi) nella sessione mysqldump per vedere se questo ha qualche effetto su Amazon RDS (o se Amazon aumenta questo limite). Inoltre, prova a sperimentare il dumping di singole tabelle.

AGGIORNAMENTO 2011-11-14 17:58 EDT

Prova a eseguirlo all'interno della tua sessione DB (imposta su due minuti):

SET innodb_lock_wait_timeout = 120;