Esegui MySQLDump senza bloccare le tabelle


437

Voglio copiare un database di produzione live nel mio database di sviluppo locale. C'è un modo per farlo senza bloccare il database di produzione?

Attualmente sto usando:

mysqldump -u root --password=xxx -h xxx my_db1 | mysql -u root --password=xxx -h localhost my_db1

Ma blocca ogni tabella mentre viene eseguita.


Un'altra soluzione tardiva: è anche possibile utilizzare Percona XtraBackup per scaricare il database di produzione senza interruzioni per quanto riguarda l'elaborazione delle transazioni. Consente di eseguire un backup a caldo, ovvero non influisce sulle attività correnti. Vedi qui: percona.com/software/mysql-database/percona-xtrabackup (Non ho alcuna affiliazione in alcun modo con Percona.)
delx,

Risposte:


626

L' --lock-tables=falseopzione funziona?

Secondo la pagina man , se stai scaricando tabelle InnoDB puoi usare l' --single-transactionopzione:

--lock-tables, -l

Lock all tables before dumping them. The tables are locked with READ
LOCAL to allow concurrent inserts in the case of MyISAM tables. For
transactional tables such as InnoDB and BDB, --single-transaction is
a much better option, because it does not need to lock the tables at
all.

Per DB innodb :

mysqldump --single-transaction=TRUE -u username -p DB

23
per DB innodb mysqldump --single-transazione = TRUE -u username -p DB

19
E se avessi innodb e myisam?
CMCDragonkai,

È attivo per impostazione predefinita?
CMCDragonkai,

ovviamente acceso (cioè bloccato)?
evandrix,

290

È troppo tardi, ma va bene per chiunque stia cercando l'argomento. Se non sei innoDB e non sei preoccupato di bloccare mentre esegui il dump, usa semplicemente l'opzione:

--lock-tables=false

1
Grazie per la risposta Warren, questo è stato molto utile e ha funzionato come un incantesimo.
Gavin,

7
usando '--lock-table = false --quick' usa le risorse minime del server
SyntaxGoonoo

43
Ma dovresti preoccuparti di bloccare le tabelle. Se vengono scritte più tabelle mentre mysqldump è in esecuzione (e si utilizzano chiavi esterne), il dump potrebbe essere incoerente. Non lo saprai fino a quando non lo ripristini e non esegui query JOIN sui dati incoerenti. Potrebbe essere necessario del tempo prima che i dati incoerenti vengano rilevati perché i JOIN vengono utilizzati dall'applicazione non da Mysql (con le tabelle MyISAM); il ripristino funzionerà bene, mysql non ti avvertirà delle incoerenze. Quindi: MyIsam -> blocca sempre i tuoi tavoli. InnoDB -> usa --single-transaction.
Costa

12
@Costa Non credo che bloccare le tabelle sia sufficiente per le tabelle MyISAM. Se mysqldump blocca le tabelle tra le query eseguite dall'applicazione, si ottengono le stesse incoerenze. La risposta è ancora più semplice: MyISAM -> usa invece InnoDB.
cdhowie,

@Costa dovresti sicuramente preoccuparti di bloccare le tabelle, ma solo se hai bisogno di un dump coerente . Ci sono alcuni rari casi in cui non lo fai. Ad esempio, un greggio fgrep sul dump dell'intero database (debug): scommetto che non si vuole che gli utenti aspettino ~ 20 minuti per creare il dump del database di produzione (storia vera). Se il punto è quello di ottenere il dump non solo APPENA POSSIBILE, ma anche CONSISTENTE , si dovrebbe scaricare uno slave replicato o usare uno snapshot di livello inferiore (lvm, zfs, btrfs, ecc.), Tenendo presente le FLUSH TABLES WITH READ LOCKcose.
Alex Offshore,

44

La risposta varia in base al motore di archiviazione che stai utilizzando. Lo scenario ideale è se stai usando InnoDB. In tal caso è possibile utilizzare il --single-transactionflag, che fornirà un'istantanea coerente del database nel momento in cui inizia il dump.


35

--skip-add-locks aiutato per me


2
o anche --compact per includere skip lock con altre ottimizzazioni.
ppostma1,

77
Ciò rimuove le istruzioni LOCK TABLES e UNLOCK TABLES dal file di dump, non influisce sul blocco durante l'esportazione.
dabest1,

11
No, non è quello che stai cercando! Vedi il commento di dabest1. Questo non fa NULLA per impedire che i tuoi tavoli vengano bloccati mentre fai un mysqldump. Questa NON è una risposta alla domanda.
or

@dabest e @orrd sono corretti: --skip-add-locksrenderebbe più rapido il ripristino del dump. Questa non è una risposta corretta
dr_



10

Onestamente, configurerei la replica per questo, come se non si bloccassero le tabelle si otterrebbero dati incoerenti dal dump.

Se il dump richiede più tempo, le tabelle che erano già state scaricate potrebbero essere cambiate insieme ad alcune tabelle che stanno per essere scaricate.

Quindi bloccare le tabelle o utilizzare la replica.


L'intero DB è quasi interamente letto, quindi non sono troppo preoccupato per il suo cambiamento.
Greg,

2
Questo commento non è corretto MVCC consente di leggere lo stato coerente senza blocchi su InnoDB.
Scott Hyndman,

5
Se non hai già configurato la replica, devi eseguire un dump per configurarlo. Lo stesso problema esiste.
Matt Connolly,

3
Se non hai già installato la replica, dovrai comunque bloccare le tabelle per eseguire il dump per garantire l'integrità dei dati. Quindi è un
problema

9

Questo è più o meno in ritardo rispetto al ragazzo che ha detto che era in ritardo rispetto alla risposta originale, ma nel mio caso (MySQL via WAMP su Windows 7), ho dovuto usare:

--skip-lock-tables

Questo è ciò che ha funzionato per me per scaricare information_schema senza avere l'errore "Accesso negato per l'utente 'debian-sys-maint' @ 'localhost' al database 'information_schema' quando utilizza LOCK TABLES"
Rui F Ribeiro

6
    mysqldump -uuid -ppwd --skip-opt --single-transaction --max_allowed_packet=1G -q db |   mysql -u root --password=xxx -h localhost db

Al voto, questo ha funzionato per me basta aggiungere i parametri --skip-opt --single-transazione --max_allowed_packet = 1G
Steven Lizarazo,

1
Non consiglio "--skip-opt" per questo scopo. Questo fa molto di più di quello che la domanda originale ha chiesto. Disattiva la modalità rapida, non include il set di caratteri, ecc.
Ecc

3

Quando si utilizza MySQL Workbench, in Esportazione dati, fare clic su Opzioni avanzate e deselezionare le opzioni "tabelle di blocco".

inserisci qui la descrizione dell'immagine


1

Poiché nessuno di questi approcci ha funzionato per me, ho semplicemente fatto un:

mysqldump [...] | grep -v "LOCK TABLE" | mysql [...]

Escluderà entrambi LOCK TABLE <x>e i UNLOCK TABLEScomandi.

Nota: si spera che i tuoi dati non contengano quella stringa!


2
--skip-add-locks durante il dump fa anche questo
codewandler,


0

Un'altra risposta tardiva:

Se stai cercando di creare una copia a caldo del database del server (in un ambiente Linux) e il motore di database di tutte le tabelle è MyISAM, dovresti usare mysqlhotcopy.

Secondo la documentazione:

Utilizza FLUSH TABLES, LOCK TABLES e cp o scp per eseguire un backup del database. È un modo rapido per eseguire un backup del database o delle singole tabelle, ma può essere eseguito solo sullo stesso computer in cui si trovano le directory del database. mysqlhotcopy funziona solo per il backup di tabelle MyISAM e ARCHIVE.

Il LOCK TABLEStempo dipende dal tempo in cui il server può copiare i file MySQL (non crea un dump).


0

Oggi anche io ho riscontrato lo stesso problema ma non avevo accesso alla riga di comando, quindi ho aperto il file sql nell'editor di Blocco note e rimosso la riga sotto dalle tabelle

LOCK TABLES `yourtable name` WRITE;

poi ho importato nel mio ambiente di sviluppo. Funziona bene. spero che aiuti qualcuno

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.