MySQL Storage Engine Optimization:Konfiguration af InnoDB-optimering til høj ydeevne

InnoDB er en af ​​de mest udbredte lagringsmotorer i MySQL. Denne lagringsmotor er kendt som en høj-pålidelighed og en højtydende lagringsmotor, og dens vigtigste fordele omfatter understøttelse af rækkeniveaulåsning, fremmednøgler og at følge ACID-modellen. InnoDB erstatter MyISAM som standardlagringsmotor siden MySQL 5.5, som blev udgivet i 2010.

Denne lagringsmotor kan være utroligt effektiv og kraftfuld, hvis den er optimeret ordentligt - i dag kigger vi på de ting, vi kan gøre for at få den til at yde sit bedste, men før vi dykker ind i InnoDB bør vi dog forstå, hvad den førnævnte ACID-model er.

Hvad er ACID, og ​​hvorfor er det vigtigt?

ACID er et sæt egenskaber ved databasetransaktioner. Akronymet oversættes til fire ord:Atomicitet, Konsistens, Isolation og Holdbarhed. Kort sagt sikrer disse egenskaber, at databasetransaktioner behandles pålideligt og garanterer datavaliditet på trods af fejl, strømafbrydelser eller sådanne problemer. Et databasestyringssystem, der overholder disse principper, siges at være et ACID-kompatibelt DBMS. Sådan fungerer alt i InnoDB:

• Atomicitet sikrer, at udsagn i en transaktion fungerer som en udelelig enhed, og at deres virkninger ses samlet eller slet ikke;
• Konsistens håndteres af MySQL's logningsmekanismer, som registrerer alle ændringer i databasen;
• Isolation refererer til InnoDBs låsning på rækkeniveau;
• Holdbarheden opretholdes også, fordi InnoDB vedligeholder en logfil, der sporer alle ændringer i systemet.

Forstå InnoDB

Nu hvor vi har dækket ACID, skal vi nok se på, hvordan InnoDB ser ud under motorhjelmen. Sådan ser InnoDB ud indefra (billede med tilladelse fra Percona):

Fra billedet ovenfor kan vi tydeligt se, at InnoDB har nogle få parametre, der er afgørende for dens ydeevne, og disse er som følger:

• Innodb_data_file_path-parameteren beskriver systemtablespacet (systemtablespacet er lagerområdet for InnoDB-dataordbogen, de dobbelte skrive- og ændringsbuffere og fortryd-logfiler). Parameteren viser filen, hvor data afledt af InnoDB-tabeller vil blive lagret;
• innodb_buffer_pool_size-parameteren er en hukommelsesbuffer, som InnoDB bruger til at cache data og indekser af sine tabeller;
• Innodb_log_file_size-parameteren viser størrelsen af ​​InnoDB-logfiler;
• innodb_log_buffer_size-parameteren bruges til at skrive til logfilerne på disken;
• innodb_flush_log_at_trx_commit-parameteren kontrollerer balancen mellem streng ACID-overholdelse og højere ydeevne;
• innodb_lock_wait_timeout-parameteren er den tid i sekunder, en InnoDB-transaktion venter på en rækkelås, før den giver op;
• InnoDB_flush_method-parameteren definerer den metode, der bruges til at tømme data til InnoDB-datafiler og logfiler, som kan påvirke I/O-gennemstrømningen.

InnoDB gemmer også dataene fra sine tabeller i en fil kaldet ibdata1 - logfilerne er dog gemt i to separate filer ved navn ib_logfile0 og ib_logfile1:alle disse tre filer ligger i /var/lib/mysql vejviser.

For at gøre InnoDB så effektiv som muligt, skal vi finjustere disse parametre og optimere dem så meget som muligt ved at se på vores tilgængelige hardwareressourcer.

Justering af InnoDB til høj ydeevne

Følg disse trin for at justere InnoDBs ydeevne på din hardware:

• For at udvide innodb_data_file_path automatisk skal du angive autoextend-attributten i indstillingen og genstarte serveren. For eksempel:

innodb_data_file_path=ibdata1:10M:autoextend

Når parameteren autoextend bruges, øges datafilen automatisk i størrelse med 8 MB trin, hver gang der kræves plads. En ny automatisk udvidende datafil kan også angives på denne måde (i dette tilfælde kaldes den nye datafil ibdata2):

innodb_data_file_path=ibdata1:10M;ibdata2:10M:autoextend

• Når du bruger InnoDB, er den primære mekanisme, der bruges, bufferpuljen. InnoDB er stærkt afhængig af bufferpuljen, og som en tommelfingerregel bør parameteren innodb_buffer_pool_size være omkring 60 % til 80 % af den samlede tilgængelige RAM på serveren. Husk, at du også skal efterlade noget RAM til de processer, der kører i operativsystemet;

• InnoDB's innodb_log_file_size skal sættes så stor som muligt, men ikke større end nødvendigt. I dette tilfælde skal du huske på, at en større logfilstørrelse er bedre for ydeevnen, men jo større den er, desto længere tid kræves gendannelse efter et nedbrud. Som sådan er der ingen "one size fits all"-løsning, men det siges, at den kombinerede størrelse af logfilerne skal være stor nok. Dette hjælper MySQL-serveren fra regelmæssigt at arbejde med kontrolpunkter og diskudskylningsaktivitet. Dette sparer for meget CPU og disk IO og kan køre problemfrit under dens spidsbelastningstid eller høj arbejdsbelastning. Selvom den anbefalede tilgang er at teste og eksperimentere selv og selv finde den optimale værdi;

• Værdien for innodb_log_buffer_size skal indstilles til mindst 16M. En stor logbuffer tillader store transaktioner at køre uden behov for at skrive loggen til disken, før transaktionerne forpligter sig til at gemme nogle disk I/O;

• Når du tuner innodb_flush_log_at_trx_commit, skal du huske på, at denne parameter accepterer tre værdier - 0, 1 og 2. Med en værdi på 1 opnår du ACID-overensstemmelse og med værdierne 0 eller 2 får du mere ydeevne, men mindre pålidelighed, fordi transaktioner, for hvilke logfiler endnu ikke er blevet tømt til disken, kan gå tabt i et nedbrud;

• For at indstille innodb_lock_wait_timeout til en korrekt værdi, skal du huske på, at denne parameter definerer tiden i sekunder (standardværdien er 50) før udsender følgende fejl og ruller den aktuelle sætning tilbage:

ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

• I InnoDB er der flere tilgængelige flush-metoder. Som standard er denne indstilling sat til "async_unbuffered" på Windows-maskiner, hvis værdien er sat til NULL og til "fsync" i Linux-maskiner. Her er hvad metoderne er, og hvad de gør:

• Du bør også overveje at aktivere indstillingen for innodb_file_per_table. Denne parameter er ON som standard i MySQL 5.6 og nyere. Denne parameter fritager dig for administrationsproblemer i forbindelse med InnoDB-tabeller ved at gemme dem i separate filer og undgå oppustede hovedordbøger og systemtabeller. Aktivering af denne variabel forhindrer også datagendannelseskompleksitet, når en bestemt tabel er beskadiget
• Nu hvor du har ændret disse indstillinger i henhold til instruktionerne ovenfor, burde du være næsten klar til at gå! Før du går i gang, bør du nok holde øje med den travleste fil i hele InnoDB-infrastrukturen - ibdata1.

Håndtering af ibdata1

Der er flere klasser af information, der er gemt i ibdata1:

1. Dataene fra InnoDB-tabeller;
2. Indekserne for InnoDB-tabeller;
3. InnoDB-tabelmetadata;
4. Multiversion Concurrency Control (MVCC) data;
5. Dobbeltskrivningsbufferen - sådan en buffer gør InnoDB i stand til at gendanne fra halvskrevne sider. Formålet med en sådan buffer er at forhindre datakorruption;
6. Indsættelsesbufferen - sådan en buffer bruges af InnoDB til at buffere opdateringer til den samme side, så de kan udføres på én gang og ikke efter hinanden.

Når man beskæftiger sig med store datasæt, kan ibdata1-filen blive ekstrem stor, og dette kan være kernen i et meget frustrerende problem - filen kan kun vokse og som standard kan den ikke krympe. Du kan lukke MySQL ned og slette denne fil, men dette anbefales ikke, medmindre du ved, hvad du laver. Når den slettes, vil MySQL ikke fungere korrekt, da ordbogen og systemtabellerne er væk, og derfor er hovedsystemtabellen beskadiget.

Følg disse trin for at formindske ibdata1 én gang for alle:

1. Dump alle data fra InnoDB-databaser. Du kan bruge mysqldump eller mysqlpump til denne handling;
2. Slet alle databaser undtagen mysql-, performance_schema- og information_schema-databaserne;
3. Stop MySQL;
4. Tilføj følgende til din my.cnf-fil:

   [mysqld]
   innodb_file_per_table = 1
   innodb_flush_method = O_DIRECT
   innodb_log_file_size = 25% of innodb_buffer_pool_size
   innodb_buffer_pool_size = up to 60-80% of available RAM.

5. Slet ibdata1- og ib_logfile*-filerne (disse vil blive genskabt ved næste genstart af MySQL);
6. Start MySQL og gendan dataene fra det dump, du tog før. Efter at have udført de trin, der er skitseret ovenfor, vil ibdata1-filen stadig vokse, men den vil ikke længere indeholde data fra InnoDB-tabeller - filen vil kun indeholde metadata, og hver InnoDB-tabel vil eksistere uden for ibdata1. Nu, hvis du går til mappen /var/lib/mysql, vil du se to filer, der repræsenterer hver tabel, du har med InnoDB-motoren. Filerne vil se sådan ud:
   1. degraderbar.frm
   2. degraderbar.ibd

.frm-filen indeholder lagringsmotorens header, og .ibd-filen indeholder tabeldata og indekser for din tabel.

Før du udruller ændringerne, skal du dog sørge for at finjustere parametrene i henhold til din infrastruktur. Disse parametre kan gøre eller ødelægge InnoDB-ydeevnen, så sørg for at holde øje med dem hele tiden. Nu skulle du være god til at gå!

Oversigt

For at opsummere kan optimering af InnoDBs ydeevne være en stor fordel, hvis du udvikler applikationer, der kræver dataintegritet og høj ydeevne på samme tid - InnoDB giver dig mulighed for at ændre, hvor meget hukommelse motoren må forbruge, for at ændre logfilstørrelsen, skyllemetoden motoren bruger og så videre - disse ændringer kan få InnoDB til at yde ekstremt godt, hvis de er tunet korrekt. Før du udfører nogen forbedringer, skal du dog være opmærksom på konsekvenserne af dine handlinger for både din server og MySQL.

Som altid, før du optimerer noget til ydeevne, skal du altid tage (og teste!) sikkerhedskopier, så du kan gendanne dine data, hvis det er nødvendigt, og altid teste eventuelle ændringer på en lokal server, før ændringerne udrulles til produktionen.