SNEL een stilgelegde database dumpen:
Het gebruik van de "-T" optie met mysqldump resulteert in veel .sql- en .txt-bestanden in de opgegeven map. Dit is ~50% sneller voor het dumpen van grote tabellen dan een enkel .sql-bestand met INSERT-instructies (duurt 1/3 minder kloktijd).
Bovendien is er een enorm voordeel bij het herstellen als u meerdere tabellen parallel kunt laden en meerdere kernen kunt verzadigen. Op een 8-core box kan dit wel een verschil van 8x zijn in de wandkloktijd om de dump te herstellen, bovenop de efficiëntieverbeteringen van "-T". Omdat "-T" ervoor zorgt dat elke tabel in een apart bestand wordt opgeslagen, is het gemakkelijker om ze parallel te laden dan een enorm .sql-bestand op te splitsen.
Door de bovenstaande strategieën tot hun logische uiterste te nemen, zou men een script kunnen maken om een database op grote schaal parallel te dumpen. Nou, dat is precies wat de Maakit mk-parallel-dump (zie http:/ /www.maatkit.org/doc/mk-parallel-dump.html ) en mk-parallel-restore tools zijn; perl-scripts die meerdere aanroepen doen naar het onderliggende mysqldump-programma. Toen ik deze echter probeerde te gebruiken, had ik problemen om het herstel te voltooien zonder dubbele sleutelfouten die niet voorkwamen bij vanilla dumps, dus houd er rekening mee dat uw kilometerstand kan variëren.
Dumpen van gegevens uit een LIVE-database (zonder serviceonderbreking):
De --single-transaction schakelaar is erg handig voor het dumpen van een live database zonder deze stil te hoeven zetten of voor het dumpen van een slave database zonder te stoppen met slaven.
Helaas is -T niet compatibel met --single-transactie, dus je krijgt er maar één.
Meestal gaat het verwijderen van de stortplaats veel sneller dan het herstellen ervan. Er is nog steeds ruimte voor een tool die het binnenkomende monolithische dumpbestand neemt en het in meerdere stukken verdeelt om parallel te laden. Bij mijn weten bestaat zo'n tool nog niet.
Het overbrengen van de dump via het netwerk is meestal een overwinning
Luisteren naar een inkomende dump bij één hostrun:
nc -l 7878 > mysql-dump.sql
Voer vervolgens op uw DB-host
mysqldump $OPTS | nc myhost.mydomain.com 7878
Dit vermindert de strijd voor de schijfspindels op de master van het schrijven van de dump naar schijf, waardoor uw dump enigszins wordt versneld (ervan uitgaande dat het netwerk snel genoeg is om bij te blijven, een redelijk veilige veronderstelling voor twee hosts in hetzelfde datacenter). Plus, als je een nieuwe slave aan het bouwen bent, bespaart dit de stap om het dumpbestand over te zetten nadat het klaar is.
Waarschuwingen - u moet natuurlijk voldoende netwerkbandbreedte hebben om de zaken niet ondraaglijk te vertragen, en als de TCP-sessie breekt, moet u helemaal opnieuw beginnen, maar voor de meeste dumps is dit geen groot probleem.
Tot slot wil ik een punt van veel voorkomende verwarring uit de weg ruimen.
Ondanks hoe vaak je deze vlaggen ziet in mysqldump-voorbeelden en tutorials, zijn ze overbodig omdat ze standaard AAN staan:
--opt--add-drop-table--add-locks--create-options--disable-keys--extended-insert--lock-tables--quick--set-charset.
Van http://dev.mysql.com/doc/refman/ 5.1/nl/mysqldump.html :
Van die gedragingen is "--quick" een van de belangrijkste (sla het cachen van de volledige resultaatset in mysqld over voordat de eerste rij wordt verzonden), en kan met "mysql" zijn (wat NIET standaard aanzet --quick) om zoekopdrachten die een grote resultatenset opleveren drastisch te versnellen (bijvoorbeeld het dumpen van alle rijen van een grote tabel).