[MySQL] mysqldump deadlock?

[Keiichi]

Van een complete MySQL server moet ik een mysqldump maken om deze daarna op een andere server te brengen. Hierbij ging ik als volgt te werk:
1) Alle tables locken (FLUSH TABLES WITH READ LOCK)
2) MySQL dump maken van alle databases en data
3) MySQL server afsluiten.
4) Alles overzetten.

Na het maken van de dump, weet ik in ieder geval dat er geen wijzigingen meer zijn. Echter kom ik niet langs stap 2. Hij wacht op de lock om gereleased te worden, output uit SHOW PROCESSLIST:

| 193 | root | localhost:50416 | mijndb | Query | 16 | Waiting for release of readlock | LOCK TABLES `mijntabel` READ /*!32311 LOCAL */,`mijn tabel` RE |

Ik heb al eerder bij andere kleine servers precies hetzelfde gedaan, maar leverde toen geen probleem op.

Waarom wacht mysqldump op het releasen van de lock, terwijl mysql toch alleen hoeft te lezen?

-edit-

ik gebruik versie 5.0.85

[curry684]

Dit is een vraag die niet zo even simpel te beantwoorden is - er zijn namelijk in DB-land meerdere soorten locks, zoals 'read exclusive', 'read intent' en 'read shared'. Zoals je je wel kunt voorstellen is dit van invloed hier, en onder meer ook afhankelijk van je gebruikte storage mechanisms.

Ik vraag me echter vooral af waarom je zo omslachtig doet met locks - waarom breng je niet gewoon de applicaties/websites down die de server aanspreken, dat is enkele malen simpeler en heeft hetzelfde effect?

[Cartman!]

Nu weet ik niks van de tool waarmee jij de dump wilt maken, maar wil die niet de data gaan lezen terwijl jij net die lock erop gezet hebt

[Creepy]

Waarom niet direct

code:

mysqldump --all-databases --single-transaction

gebruiken?
Volgens de docs doet dat het volgende:

Uit de mysqldump man page
This backup acquires a global read lock on all tables (using
FLUSH TABLES WITH READ LOCK) at the beginning of the dump. As
soon as this lock has been acquired, the binary log
coordinates are read and the lock is released. If long
updating statements are running when the FLUSH statement is
issued, the MySQL server may get stalled until those
statements finish. After that, the dump becomes lock-free and
does not disturb reads and writes on the tables. If the update
statements that the MySQL server receives are short (in terms
of execution time), the initial lock period should not be
noticeable, even with many updates.

Dan hoef je zelf niks meer te locken en unlocken.

[Keiichi]

@creepy Omdat na de dump het schrijven weer doorgaat.

Een gebruiker of process kan data naar de database toegeschreven hebben, waarna deze op de verse MySQL server niet meer naar voren komt.

Er zijn natuurlijk verschillende dingen om te bedenken om dit te voorkomen, zoals bv het dichtgooien van een server, de databestanden op de nieuwe server zetten. Aangezien de nieuwe server met de optie 'innodb_file_per_table', gaat dat niet zo werken.

@curry684: Zoals genoemde mag er na de dump niets meer geschreven worden.

@cartman: Die lock is dat er enkel nog maar gelezen kan worden.


Het frapante is dat ik exact het hele genoemde verhaal van mij eerder op een andere server WEL voor elkaar gekregen heb.

[curry684]

Keiichi schreef op woensdag 18 november 2009 @ 12:25:
@curry684: Zoals genoemde mag er na de dump niets meer geschreven worden.

Dat snap ik wel maar waarom fix je dat niet op de logische plaats - zeg maar het uitzetten van de omringende toepassingen of in maintenance mode zetten ervan.

Dat daargelaten zoek je denk ik deze my.cnf property.