Årets största onlineshoppingdagar är precis runt hörnet. Är din databas redo? Genom att justera 20 viktiga MariaDB-systemvariabler kommer du att stärka din databas prestanda , skalbarhet och tillgänglighet , vilket säkerställer att varje potentiell kund har en smidig användarupplevelse. Följande systemvariabler dyker upp upprepade gånger när du konfigurerar en optimal MariaDB-servermiljö. Implementera våra rekommendationer för de mest anpassade värdena och gör årets Black Friday–Cyber Monday-period till din bästa någonsin.
Ett par viktiga anmärkningar:
- Acceptera inte dessa förslag blint. Varje MariaDB-miljö är unik och kräver ytterligare eftertanke innan du gör några ändringar. Du kommer sannolikt att behöva justera dessa inställningar för ditt specifika användningsfall och miljö.
- MariaDB-konfigurationsfilen finns i /etc/my.cnf. Varje gång du ändrar den här filen måste du starta om MySQL-tjänsten så att de nya ändringarna kan träda i kraft.
20 rekommendationer för inställning av Black Friday och Cyber Monday
1. InnoDB buffertpoolstorlek
InnoDB-buffertpoolens storlek det här är den första inställningen att titta på för alla installationer som använder InnoDB. Buffertpoolen är där data och index cachelagras; att ha den så stor som möjligt säkerställer att du använder minne och inte diskar för de flesta läsoperationer.
2. InnoDB-loggfilstorlek
innodb_log-file-size är storleken på redo-loggarna, som används för att se till att skrivningar är snabba och hållbara. Det finns två allmänna förslag för storlek på InnoDB-loggfilen:
- Ställ in den sammanlagda totala storleken för InnoDB-loggfiler som är större än 25–50 % av InnoDB-buffertpoolens storlek
eller
- Ange den kombinerade InnoDB-loggfilens loggstorlek lika med en timmes loggposter under toppbelastning
Större loggfiler kan leda till långsammare återställning i händelse av en serverkrasch. Men de minskar också antalet kontrollpunkter som behövs och minskar disk I/O.
Utvärdera storleken på en timmes binära loggar under operativ belastning och bestäm sedan om du vill öka storleken på InnoDB-loggfilerna.
Att få rätt storlek på innodb-loggfilen är viktigt för att uppnå bra systemprestanda. MariaDB:s InnoDB-lagringsmotor använder ett (cirkulärt) redo-loggutrymme med fast storlek. Storleken styrs av innodb_log_file_size och innodb_log_files_in_group (standard 2). Multiplicera dessa värden för att få reda på loggutrymmet som är tillgängligt för användning. Även om det tekniskt sett inte borde spela någon roll om du använder variabeln innodb_log_file_size eller innodb_log_files_in_group för att styra storleken på omställningsutrymmet, arbetar de flesta bara med innodb_log_file_size och låter innodb_log_files_in_group vara.
InnoDB:s storlek på omställningsutrymme är ett av de viktigaste konfigurationsalternativen för skrivintensiva arbetsbelastningar. Det kommer dock med avvägningar. Ju mer omställningsutrymme som konfigurerats, desto bättre kan InnoDB optimera skriv-I/O. Att öka omställningsutrymmet innebär dock också längre återställningstider när systemet tappar ström eller kraschar av andra skäl.
3. InnoDB Log Buffer Size
En större InnoDB-loggbuffertstorlek innebär mindre disk I/O för större transaktioner. Det rekommenderas att ställa in detta till 64M på alla servrar.
4. InnoDB Log Flush Interval
Innodb_flush_log_at_trx_commit-variabeln kontrollerar när tömning av loggbufferten till disken sker. innodb_flush_log_at_trx_commit =1 (standard) tömmer loggbufferten till disken vid varje transaktion. Detta är det säkraste men också det minst presterande alternativet.
innodb_flush_log_at_trx_commit =0 tömmer loggbufferten till disken varje sekund, men ingenting vid transaktionsbekräftelse. Upp till en sekund (möjligen mer på grund av processschemaläggning) kan gå förlorad. Om det blir någon krasch kan MySQL eller servern förlora data. Det här är det snabbaste men minst säkra alternativet.
innodb_flush_log_at_trx_commit =2 skriver ut loggbufferten till filen vid varje commit men spolar till disken varje sekund. Om diskcachen har en batteribackup (till exempel en batteriuppbackad cache raid-kontroller) är detta i allmänhet den bästa balansen mellan prestanda och säkerhet. En krasch av MySQL bör inte förlora data. En serverkrasch eller strömavbrott kan förlora upp till en sekund (möjligen mer på grund av processschemaläggning). En batteristödd cache minskar denna möjlighet.
Vi föreslår att du använder det första alternativet för säkerhets skull.
5. InnoDB IO-kapacitet
innodb_io_capacity bör ställas in på ungefär det maximala antalet IOPS som den underliggande lagringen kan hantera.
Som standard är detta inställt på 1000. Vi rekommenderar att du jämför lagringen för att avgöra om du kan öka detta värde ytterligare.
6. Trådcachestorlek
Övervaka värdet på Threads_created. Om den fortsätter att öka med mer än några trådar per minut ökar du värdet på thread_cache_size.
Trådcachestorleken är inställd på 200 i den nuvarande standardkonfigurationen.
7. Tabellcache och tabelldefinitionscache
variablerna table_open_cache och table_defintion_cache styr antalet tabeller och definitioner för att hållas öppna för alla trådar.
Övervaka Open_tables, Open_table_definitions, Opened_tables och Opened_table_definitions för att avgöra det bästa värdet. Det allmänna förslaget är att endast ställa in table_open_cache (och därefter table_definition_cache) tillräckligt högt för att minska ökningshastigheten för statusvärdet för Öppnade tabeller (och öppnade_tabeller).
Både table_open_cache och table_defintion_cache är inställda på 2048 i standardkonfigurationen.
8. Fråga cache
Frågecachen är en välkänd flaskhals som kan ses även när samtidigheten är måttlig. Det bästa alternativet är att inaktivera det från dag ett genom att ställa in query_cache_size =0 (standard i MariaDB 10) och att använda andra sätt för att snabba upp läsfrågor:ha bra indexering, lägga till repliker för att sprida läsbelastningen eller använda en extern cache ( memcache eller redis, till exempel). Om du redan har byggt din MariaDB-applikation med frågecachen aktiverad och aldrig har märkt något problem, kan frågecachen vara till nytta för dig. Var i så fall försiktig om du bestämmer dig för att inaktivera det.
9. Tillfälliga tabeller, tmp_table_size och max_heap_table_size
MySQL använder det lägre av max_heap_table_size och tmp_table_size för att begränsa storleken på temporära tabeller i minnet. Dessa är per klient variabler. Även om det här värdet är stort kan det hjälpa till att minska antalet tillfälliga tabeller som skapas på disken, men det ökar också risken för att nå serverns minneskapacitet eftersom det är per klient. I allmänhet är 32M till 64M det föreslagna värdet till att börja med för både variabler och justera efter behov.
Tillfälliga tabeller används ofta för GROUP BY, ORDER BY, DISTINCT, UNION, underfrågor, etc. Helst bör MySQL skapa dessa i minnet, med så få på disken som möjligt.
Det är viktigt att notera att frågor som inte använder kopplingar på rätt sätt och skapar stora tillfälliga tabeller kan vara en anledning till ett högre antal temporära tabeller på disken. En annan anledning är att minneslagringsmotorn använder kolumner med fast längd och antar det värsta scenariot. Om kolumner inte har rätt storlek (till exempel en VARCHAR(255) för en kort sträng), påverkar detta storleken på tabellen i minnet och kan göra att den hamnar på disken tidigare än den borde. Dessutom kommer tillfälliga tabeller med blob- och textkolumner omedelbart att läggas till disken, eftersom minneslagringsmotorn inte stöder dem.
Båda är för närvarande inställda på 64M som standard.
10. Varningsloggnivå
Vi rekommenderar att du ställer in varningsloggnivån till log_warnings =2. Om du gör det loggas information om avbrutna anslutningar och åtkomst nekad fel.
11. Max anslutningar
Om du ofta stöter på felet "För många anslutningar" är max_connections för lågt. Eftersom programmet inte stänger anslutningar till databasen korrekt behöver du ofta mycket mer än standardanslutningarna 151. Den största nackdelen med höga värden för max_connections (säg 1 000 eller fler) är att servern inte svarar om den måste köra så många aktiva transaktioner. Att använda en anslutningspool på applikationsnivå eller en trådpool på MariaDB-nivå kan hjälpa här.
12. Transaktionsisolering
Undersök de tillgängliga transaktionsisoleringsnivåerna och bestäm den bästa transaktionsisoleringen för din servers användningsfall.
13. Binärt loggformat
Vi rekommenderar att du använder det binära loggformatet ROW för master-master-replikering.
14. Auto-ökningsförskjutningar
För att minska risken för kollision mellan två masters som skrivs till samtidigt måste värdena för automatisk inkrement och automatisk ökning justeras i enlighet med detta.
15. Synkronisera Binlog
Som standard hanterar operativsystemet att spola binloggen till disken. I händelse av en serverkrasch är det möjligt att förlora transaktioner från den binära loggen, vilket leder till att replikeringen inte synkroniseras. Inställning av sync_binlog =1 gör att binlog-filen töms vid varje commit.
Detta är långsammare, men det säkraste alternativet.
16. Crash Safe(r) Slaves
För att undvika replikeringsfel efter en slavkrasch, aktivera återställning av relälogg och synkronisering av relälogg- och relälogginformationsfiler till disk.
17. Logga slavuppdateringar
För att ha kedjad replikering (master -> slav -> slav) måste log_slave_updates aktiveras. Detta säger åt en slav att skriva replikerade transaktioner till sin egen binära logg så att de sedan kan replikeras till slavar utanför den.
18. Skrivskyddade slavar
Slavar bör vara skrivskyddade för att undvika att data av misstag skrivs till dem.
Obs :Användare med superprivilegier kan fortfarande skriva när servern är skrivskyddad.
19. Slave Net Timeout
Variabeln slave_net_timeout är antalet sekunder som slaven väntar på ett paket från mastern innan den försöker återansluta. Standard är 3600 (1 timme). Det betyder att om länken går ner och inte upptäcks kan det ta upp till en timme innan slaven återansluter. Detta kan leda till att slaven plötsligt är upp till en timme efter mastern.
Vi rekommenderar att du ställer in slave_net_timeout till ett mer rimligt värde, till exempel 30 eller 60.
20. Se vårt webbseminarium om att förbereda för Black Friday och Cyber Monday
Titta på vårt webbseminarium på begäran – Förberedelser för Black Friday och Cyber Monday – för att lära dig de fyra viktiga principerna för databasberedskap: säkerhetsåtgärder för att skydda din databas från skadliga attacker, prestandajustering för att säkerställa att du levererar en smidig användarupplevelse, strategier med hög tillgänglighet för att säkerställa att du inte missar en enda försäljning och skalbarhet för att förbereda sig för både förväntad tillväxt och oväntade toppar.