Årets største online-shoppingdage er lige rundt om hjørnet. Er din database klar? Ved at justere 20 vigtige MariaDB-systemvariabler vil du styrke din databases ydeevne , skalerbarhed og tilgængelighed , hvilket sikrer, at alle potentielle kunder får en smidig brugeroplevelse. Følgende systemvariable dukker op gentagne gange ved konfiguration af et optimalt MariaDB-servermiljø. Implementer vores anbefalinger for de mest indstillede værdier, og gør dette års Black Friday-Cyber Monday-periode til din bedste nogensinde.
Et par vigtige bemærkninger:
- Acceptér ikke disse forslag blindt. Hvert MariaDB-miljø er unikt og kræver yderligere eftertanke, før der foretages ændringer. Du bliver højst sandsynligt nødt til at justere disse indstillinger til din specifikke brugssituation og miljø.
- MariaDB-konfigurationsfilen er placeret i /etc/my.cnf. Hver gang du ændrer denne fil, skal du genstarte MySQL-tjenesten, så de nye ændringer kan træde i kraft.
20 anbefalinger til justering af Black Friday og Cyber Monday
1. InnoDB Buffer Pool Størrelse
InnoDB-bufferpuljens størrelse dette er indstillingen nr. 1 at se på for enhver installation, der bruger InnoDB. Bufferpuljen er hvor data og indekser cachelagres; at have det så stort som muligt, vil sikre, at du bruger hukommelse og ikke diske til de fleste læseoperationer.
2. InnoDB-logfilstørrelse
innodb_log-file-size er størrelsen på gentag-logfilerne, som bruges til at sikre at skriveprocessen er hurtig og holdbar. Der er to generelle forslag til størrelsen på InnoDB-logfilen:
- Indstil den samlede samlede størrelse af InnoDB-logfiler, der er større end 25-50 % af InnoDB-bufferpuljens størrelse
eller
- Indstil kombineret InnoDB-logfilens logstørrelse svarende til én times logindtastninger under spidsbelastning
Større logfiler kan føre til langsommere gendannelse i tilfælde af servernedbrud. Men de reducerer også antallet af nødvendige kontrolpunkter og reducerer disk I/O.
Evaluer størrelsen af en times binære logfiler under operationel belastning, og beslut derefter, om du vil øge størrelsen på InnoDB-logfilerne.
Det er vigtigt at få indodb-logfilstørrelserne rigtige for at opnå god systemydelse. MariaDBs InnoDB-lagringsmotor bruger en fast størrelse (cirkulær) redo-logplads. Størrelsen styres af innodb_log_file_size og innodb_log_files_in_group (standard 2). Multiplicer disse værdier for at få den gentag-logplads, der er tilgængelig til brug. Selvom det teknisk set ikke burde være ligegyldigt, om du bruger variablen innodb_log_file_size eller innodb_log_files_in_group til at kontrollere størrelsen på genskabspladsen, arbejder de fleste bare med innodb_log_file_size og lader innodb_log_files_in_group være.
InnoDBs størrelse på genoptagelsesplads er en af de vigtigste konfigurationsmuligheder for skrivetunge arbejdsbelastninger. Det kommer dog med afvejninger. Jo mere omstillingsplads, der er konfigureret, jo bedre kan InnoDB optimere skrive-I/O. Forøgelse af genoptagepladsen betyder dog også længere genoprettelsestider, når systemet mister strøm eller går ned af andre årsager.
3. InnoDB Log Buffer Størrelse
En større InnoDB-logbufferstørrelse betyder mindre disk I/O for større transaktioner. Det foreslås at indstille dette til 64M på alle servere.
4. InnoDB Log Flush Interval
Innodb_flush_log_at_trx_commit-variablen kontrollerer, når logbufferen tømmes til disken. innodb_flush_log_at_trx_commit =1 (standard) tømmer logbufferen til disken ved hver transaktions-commit. Dette er den sikreste men også den mindst effektive mulighed.
innodb_flush_log_at_trx_commit =0 tømmer logbufferen til disken hvert sekund, men intet ved transaktionsbekræftelse. Op til et sekund (muligvis mere på grund af procesplanlægning) kan gå tabt. Hvis der er et nedbrud, kan MySQL eller serveren miste data. Dette er den hurtigste men mindst sikre mulighed.
innodb_flush_log_at_trx_commit =2 skriver logbufferen ud til filen på hver commit, men tømmer til disken hvert sekund. Hvis diskcachen har en batteribackup (for eksempel en batteriunderstøttet cache-raid-controller), er dette generelt den bedste balance mellem ydeevne og sikkerhed. Et nedbrud af MySQL bør ikke miste data. Et servernedbrud eller strømafbrydelse kan miste op til et sekund (muligvis mere på grund af procesplanlægning). En batteribaseret cache reducerer denne mulighed.
Vi foreslår, at du bruger den første mulighed for sikkerheden.
5. InnoDB IO-kapacitet
innodb_io_capacity bør indstilles til omtrent det maksimale antal IOPS, den underliggende lagerplads kan håndtere.
Som standard er dette indstillet til 1000. Vi anbefaler at benchmarke lageret for at afgøre, om du kan øge denne værdi yderligere.
6. Trådcachestørrelse
Overvåg værdien af Threads_created. Hvis den fortsætter med at stige med mere end et par tråde i minuttet, skal du øge værdien af thread_cache_size.
Trådcachestørrelsen er indstillet til 200 i den aktuelle standardkonfiguration.
7. Tabelcache og Tabeldefinitionscache
Table_open_cache og table_defintion_cache-variablerne styrer antallet af tabeller og definitioner for at holde åbne for alle tråde.
Overvåg Open_tables, Open_table_defintitions, Opened_tables og Opened_table_definitions for at bestemme den bedste værdi. Det generelle forslag er kun at sætte table_open_cache (og efterfølgende table_definition_cache) højt nok til at reducere stigningshastigheden for statusværdien for Åbnede_tabeller (og åbnet_tabel_definitioner).
Både table_open_cache og table_defintion_cache er sat til 2048 i standardkonfigurationen.
8. Forespørgselscache
Forespørgselscachen er en velkendt flaskehals, der kan ses, selv når samtidigheden er moderat. Den bedste mulighed er at deaktivere den fra dag ét ved at indstille query_cache_size =0 (standarden i MariaDB 10) og at bruge andre måder til at fremskynde læseforespørgsler:have god indeksering, tilføje replikaer for at sprede læsebelastningen eller bruge en ekstern cache ( memcache eller redis, for eksempel). Hvis du allerede har bygget din MariaDB-applikation med forespørgselscachen aktiveret og aldrig har bemærket noget problem, kan forespørgselscachen være gavnlig for dig. I så fald skal du være forsigtig, hvis du beslutter dig for at deaktivere den.
9. Midlertidige tabeller, tmp_table_size og max_heap_table_size
MySQL bruger den laveste af max_heap_table_size og tmp_table_size til at begrænse størrelsen af midlertidige tabeller i hukommelsen. Disse er variabler pr. klient. Selvom denne værdi er stor kan hjælpe med at reducere antallet af midlertidige tabeller, der oprettes på disken, øger det også risikoen for at nå serverens hukommelseskapacitet, da dette er pr. klient. Generelt er 32M til 64M den foreslåede værdi til at begynde med for både variabler og juster efter behov.
Midlertidige tabeller bruges ofte til GROUP BY, ORDER BY, DISTINCT, UNION, underforespørgsler osv. Ideelt set bør MySQL oprette disse i hukommelsen med så få på disken som muligt.
Det er vigtigt at bemærke, at forespørgsler, der ikke bruger sammenkædninger korrekt og opretter store midlertidige tabeller, kan være en årsag til et højere antal midlertidige tabeller på disken. En anden grund er, at hukommelseslagermaskinen bruger kolonner med fast længde og antager det værst tænkelige scenario. Hvis kolonnerne ikke har den rigtige størrelse (f.eks. en VARCHAR(255) for en kort streng), påvirker dette størrelsen af tabellen i hukommelsen og kan få den til at gå til disken tidligere, end den burde. Midlertidige tabeller med blob- og tekstkolonner går også med det samme til disken, da hukommelseslagermaskinen ikke understøtter dem.
Begge er i øjeblikket indstillet til 64M som standard.
10. Advarselslogniveau
Vi anbefaler, at du indstiller advarselslogniveauet til log_warnings =2. Hvis du gør det, logges oplysninger om afbrudte forbindelser og fejl med nægtet adgang.
11. Max forbindelser
Hvis du ofte står over for fejlen "For mange forbindelser", er max_connections for lav. Fordi applikationen ikke lukker forbindelser til databasen korrekt, har du ofte brug for meget mere end standardforbindelserne på 151. Den største ulempe ved høje værdier for max_connections (f.eks. 1.000 eller mere) er, at serveren ikke reagerer, hvis den skal køre så mange aktive transaktioner. Brug af en forbindelsespulje på applikationsniveau eller en trådpulje på MariaDB-niveau kan hjælpe her.
12. Transaktionsisolering
Undersøg de tilgængelige transaktionsisoleringsniveauer, og find den bedste transaktionsisolering til din servers brugssituation.
13. Binært logformat
Vi anbefaler at bruge det binære ROW-logformat til master-master-replikering.
14. Automatisk stigningsforskydning
For at hjælpe med at reducere chancerne for kollision mellem to mastere, der skrives til samtidigt, skal værdierne for automatisk stigning og automatisk stigning justeres i overensstemmelse hermed.
15. Synkroniser binlog
Som standard håndterer operativsystemet tømning af binlog til disk. I tilfælde af et servernedbrud er det muligt at miste transaktioner fra den binære log, hvilket fører til, at replikering ikke er synkroniseret. Indstilling af sync_binlog =1 får binlog-filen til at blive tømt ved hver commit.
Dette er langsommere, men den sikreste mulighed.
16. Crash Safe(r) Slaves
For at hjælpe med at undgå replikeringsfejl efter et slavenedbrud skal du aktivere relæloggendannelse og synkronisering af relælog- og relæloginfofiler til disk.
17. Log Slave-opdateringer
For at have kædet replikering (master -> slave -> slave), skal log_slave_updates være aktiveret. Dette fortæller en slave om at skrive replikerede transaktioner til sin egen binære log, så de derefter kan replikeres til slaver ud af den.
18. Skrivebeskyttede slaver
Slaver bør være skrivebeskyttet for at undgå, at data ved et uheld bliver skrevet til dem.
Bemærk :Brugere med superprivilegier kan stadig skrive, når serveren er skrivebeskyttet.
19. Slave Net Timeout
Slave_net_timeout-variablen er det antal sekunder, som slaven venter på en pakke fra masteren, før den forsøger at oprette forbindelse igen. Standard er 3600 (1 time). Det betyder, at hvis linket går ned og ikke registreres, kan der gå op til en time, før slaven genopretter forbindelse. Dette kan føre til, at slaven pludselig er op til en time efter mesteren.
Vi anbefaler at indstille slave_net_timeout til en mere rimelig værdi, såsom 30 eller 60.
20. Se vores webinar om forberedelse til Black Friday og Cyber Monday
Se vores on-demand webinar – Forberedelse til Black Friday og Cyber Monday – for at lære de fire vitale principper for databaseberedskab: sikkerhedsforanstaltninger for at beskytte din database mod ondsindede angreb, indstilling af ydeevne for at sikre, at du leverer en smidig brugeroplevelse, strategier med høj tilgængelighed for at sikre, at du ikke går glip af et eneste salg og skalerbarhed for at forberede sig på både forventet vækst og uventede stigninger.