HURTIG dumpning af en stillestående database:
Brug af "-T "-indstillingen med mysqldump resulterer i masser af .sql- og .txt-filer i den angivne mappe. Dette er ~50 % hurtigere til at dumpe store tabeller end en enkelt .sql-fil med INSERT-sætninger (tager 1/3 mindre vægur-tid).
Derudover er der en enorm fordel ved gendannelse, hvis du kan indlæse flere tabeller parallelt og mætte flere kerner. På en 8-kerne boks kan dette være så meget som en 8X forskel i vægurs tid for at genoprette lossepladsen, oven i effektivitetsforbedringerne leveret af "-T". Fordi "-T" får hver tabel til at blive gemt i en separat fil, er det nemmere at indlæse dem parallelt end at opdele en massiv .sql-fil.
Tager man ovenstående strategier til deres logiske ekstreme, kunne man lave et script til at dumpe en database bredt parallelt. Nå, det er præcis, hvad Maakit mk-parallel-dump (se http:/ /www.maatkit.org/doc/mk-parallel-dump.html ) og mk-parallel-restore værktøjer er; perl-scripts, der foretager flere opkald til det underliggende mysqldump-program. Men da jeg forsøgte at bruge disse, havde jeg problemer med at få gendannelsen til at fuldføre uden duplikatnøglefejl, der ikke opstod med vaniljedumper, så husk på, at dit kilometertal kan variere.
Dumping af data fra en LIVE-database (uden tjenesteafbrydelse):
--single-transaction switchen er meget nyttig til at tage et dump af en live database uden at skulle stille den eller tage et dump af en slave database uden at skulle stoppe med at slave.
Desværre er -T ikke kompatibel med --single-transaction, så du får kun én.
Normalt er det meget hurtigere at tage lossepladsen end at genoprette det. Der er stadig plads til et værktøj, der tager den indkommende monolitiske dumpfil og deler den i flere stykker, der skal indlæses parallelt. Mig bekendt eksisterer et sådant værktøj endnu ikke.
Overførsel af dumpet over netværket er normalt en gevinst
Sådan lytter du efter et indgående dump på én værtskørsel:
nc -l 7878 > mysql-dump.sql
Kør derefter
på din DB-værtmysqldump $OPTS | nc myhost.mydomain.com 7878
Dette reducerer striden for diskspindlerne på masteren fra at skrive dumpet til disken, hvilket gør din dump en smule hurtigere (forudsat at netværket er hurtigt nok til at følge med, en rimelig sikker antagelse for to værter i samme datacenter). Plus, hvis du bygger en ny slave ud, sparer dette trinnet med at skulle overføre dumpfilen, efter at den er færdig.
Advarsler - selvfølgelig skal du have nok netværksbåndbredde til ikke at bremse tingene uudholdeligt, og hvis TCP-sessionen går i stykker, skal du starte forfra, men for de fleste dumps er dette ikke en større bekymring.
Til sidst vil jeg opklare et punkt med almindelig forvirring.
På trods af hvor ofte du ser disse flag i mysqldump eksempler og tutorials, er de overflødige, fordi de er slået TIL som standard:
--opt--add-drop-table--add-locks--create-options--disable-keys--extended-insert--lock-tables--quick--set-charset.
Fra http://dev.mysql.com/doc/refman/ 5.1/da/mysqldump.html :
Af disse adfærd er "--quick" en af de vigtigste (springer cachelægning af hele resultatet i mysqld over, før den første række sendes), og kan være med "mysql" (som IKKE slår --quick til som standard) for dramatisk at fremskynde forespørgsler, der returnerer et stort resultatsæt (f.eks. dumpning af alle rækkerne i en stor tabel).