De grootste online winkeldagen van het jaar staan voor de deur. Is uw database klaar? Door 20 belangrijke MariaDB-systeemvariabelen af te stemmen, verbetert u de prestaties van uw database , schaalbaarheid en beschikbaarheid , zodat elke potentiële klant een vlotte gebruikerservaring heeft. De volgende systeemvariabelen komen herhaaldelijk naar voren bij het configureren van een optimale MariaDB-serveromgeving. Implementeer onze aanbevelingen voor de meest afgestemde waarden en maak van de Black Friday-Cyber Monday-periode van dit jaar uw beste ooit.
Een paar belangrijke opmerkingen:
- Accepteer deze suggesties niet blindelings. Elke MariaDB-omgeving is uniek en vereist extra aandacht voordat er wijzigingen worden aangebracht. U zult deze instellingen hoogstwaarschijnlijk moeten aanpassen aan uw specifieke gebruikssituatie en omgeving.
- MariaDB-configuratiebestand bevindt zich in /etc/my.cnf. Elke keer dat u dit bestand wijzigt, moet u de MySQL-service opnieuw opstarten zodat de nieuwe wijzigingen van kracht kunnen worden.
20 aanbevelingen voor afstemming op Black Friday en Cyber Monday
1. InnoDB-bufferpoolgrootte
De grootte van de InnoDB-bufferpool dit is de beste instelling om naar te kijken voor elke installatie met InnoDB. De bufferpool is waar gegevens en indexen in de cache worden opgeslagen; als u deze zo groot mogelijk maakt, zorgt u ervoor dat u voor de meeste leesbewerkingen geheugen en geen schijven gebruikt.
2. InnoDB-logbestandsgrootte
innodb_log-file-size is de grootte van de redo-logboeken, die worden gebruikt om ervoor te zorgen dat schrijfacties snel en duurzaam zijn. Er zijn twee algemene suggesties voor de grootte van InnoDB-logbestanden:
- Gecombineerde totale grootte van InnoDB-logbestanden groter dan 25-50% van de InnoDB-bufferpoolgrootte instellen
of
- Stel de gecombineerde loggrootte van het InnoDB-logbestand in op één uur aan logboekvermeldingen tijdens piekbelasting
Grotere logbestanden kunnen leiden tot langzamer herstel in het geval van een servercrash. Ze verminderen echter ook het aantal benodigde controlepunten en verminderen de schijf-I/O.
Evalueer de grootte van binaire logbestanden van een uur onder operationele belasting en beslis vervolgens of u de grootte van de InnoDB-logbestanden wilt vergroten.
Het is belangrijk dat de innodb-logbestandsgrootten juist zijn om goede systeemprestaties te bereiken. De InnoDB-opslagengine van MariaDB gebruikt een (circulaire) redo-logruimte met een vaste grootte. De grootte wordt bepaald door innodb_log_file_size en innodb_log_files_in_group (standaard 2). Vermenigvuldig die waarden om de logruimte voor opnieuw uitvoeren te krijgen die beschikbaar is voor gebruik. Hoewel het technisch gezien niet uitmaakt of je de variabele innodb_log_file_size of innodb_log_files_in_group gebruikt om de grootte van de opnieuw uit te voeren ruimte te bepalen, werken de meeste mensen gewoon met de innodb_log_file_size en laten ze innodb_log_files_in_group met rust.
InnoDB's redo-ruimtegrootte is een van de belangrijkste configuratie-opties voor schrijfintensieve workloads. Het komt echter met afwegingen. Hoe meer ruimte voor opnieuw uitvoeren is geconfigureerd, hoe beter InnoDB de schrijf-I/O kan optimaliseren. Het vergroten van de ruimte voor opnieuw uitvoeren betekent echter ook langere hersteltijden wanneer het systeem stroom verliest of om andere redenen crasht.
3. InnoDB-logboekbuffergrootte
Een grotere InnoDB-logbuffergrootte betekent minder schijf-I/O voor grotere transacties. Het wordt aangeraden om dit op alle servers in te stellen op 64 miljoen.
4. InnoDB Log Flush Interval
De variabele innodb_flush_log_at_trx_commit bepaalt wanneer de logbuffer naar de schijf wordt leeggemaakt. innodb_flush_log_at_trx_commit =1 (standaard) spoelt de logbuffer naar schijf bij elke transactie. Dit is de veiligste, maar ook de minst presterende optie.
innodb_flush_log_at_trx_commit =0 spoelt de logbuffer elke seconde naar de schijf, maar niets bij het vastleggen van transacties. Er kan maximaal één seconde (mogelijk meer vanwege de procesplanning) verloren gaan. Bij een crash kunnen MySQL of de server gegevens kwijtraken. Dit is de snelste, maar minst veilige optie.
innodb_flush_log_at_trx_commit =2 schrijft de logbuffer bij elke commit naar het bestand, maar wordt elke seconde naar de schijf gespoeld. Als de schijfcache een batterijback-up heeft (bijvoorbeeld een cache-raidcontroller met batterijondersteuning), is dit over het algemeen de beste balans tussen prestaties en veiligheid. Een crash van MySQL mag geen gegevens verliezen. Een servercrash of stroomuitval kan tot een seconde duren (mogelijk meer vanwege procesplanning). Een cache met batterijvoeding verkleint deze mogelijkheid.
We raden u aan de eerste optie te gebruiken voor de veiligheid.
5. InnoDB IO-capaciteit
innodb_io_capacity moet worden ingesteld op ongeveer het maximale aantal IOPS dat de onderliggende opslag aankan.
Standaard is dit ingesteld op 1000. We raden aan om de opslag te benchmarken om te bepalen of u deze waarde verder kunt verhogen.
Bewaak de waarde van Threads_created. Als het blijft toenemen met meer dan een paar threads per minuut, verhoogt u de waarde van thread_cache_size.
De grootte van de threadcache is ingesteld op 200 in de huidige standaardconfiguratie.
De variabelen table_open_cache en table_defintion_cache bepalen het aantal tabellen en definities dat voor alle threads open moet blijven.
Controleer Open_tables, Open_table_defintitions, Opened_tables en Opened_table_definitions om de beste waarde te bepalen. De algemene suggestie is om table_open_cache (en vervolgens table_definition_cache) alleen hoog genoeg in te stellen om het stijgingspercentage van de statuswaarde Opened_tables (en Opened_table_definitions) te verminderen.
Zowel table_open_cache als table_defintion_cache zijn in de standaardconfiguratie ingesteld op 2048.
8. Querycache
De querycache is een bekend knelpunt dat zelfs zichtbaar is als de gelijktijdigheid matig is. De beste optie is om het vanaf de eerste dag uit te schakelen door query_cache_size =0 in te stellen (de standaard in MariaDB 10) en om andere manieren te gebruiken om leesquery's te versnellen:goede indexering, replica's toevoegen om de leesbelasting te spreiden of een externe cache gebruiken ( geheugencache of redis bijvoorbeeld). Als u uw MariaDB-toepassing al hebt gebouwd met de querycache ingeschakeld en nog nooit een probleem hebt opgemerkt, kan de querycache nuttig voor u zijn. Wees in dat geval voorzichtig als u besluit het uit te schakelen.
9. Tijdelijke tabellen, tmp_table_size en max_heap_table_size
MySQL gebruikt de laagste waarde van max_heap_table_size en tmp_table_size om de grootte van tijdelijke tabellen in het geheugen te beperken. Dit zijn per klantvariabelen. Hoewel een hoge waarde kan helpen om het aantal tijdelijke tabellen dat op schijf wordt gemaakt, te verminderen, verhoogt het ook het risico dat de geheugencapaciteit van de server wordt bereikt, aangezien dit per client is. Over het algemeen is 32M tot 64M de voorgestelde waarde om mee te beginnen voor beide variabelen en waar nodig af te stemmen.
Tijdelijke tabellen worden vaak gebruikt voor GROUP BY, ORDER BY, DISTINCT, UNION, subquery's, enz. Idealiter zou MySQL deze in het geheugen moeten maken, met zo weinig mogelijk op schijf.
Het is belangrijk op te merken dat query's die joins niet op de juiste manier gebruiken en het maken van grote tijdelijke tabellen een reden kunnen zijn voor een groter aantal tijdelijke tabellen op schijf. Een andere reden is dat de geheugenopslag-engine kolommen met een vaste lengte gebruikt en uitgaat van het worstcasescenario. Als de grootte van kolommen niet correct is (bijvoorbeeld een VARCHAR(255) voor een korte tekenreeks), heeft dit invloed op de grootte van de tabel in het geheugen en kan deze eerder naar de schijf gaan dan zou moeten. Tijdelijke tabellen met blob- en tekstkolommen gaan ook onmiddellijk naar de schijf, omdat de geheugenopslagengine ze niet ondersteunt.
Beide zijn momenteel standaard ingesteld op 64 miljoen.
10. Niveau waarschuwingslogboek
We raden aan om het waarschuwingslogniveau dit in te stellen op log_warnings =2. Hierdoor wordt informatie vastgelegd over afgebroken verbindingen en fouten bij het weigeren van toegang.
Als je vaak de foutmelding 'Te veel verbindingen' krijgt, is max_connections te laag. Omdat de toepassing verbindingen met de database niet correct sluit, hebt u vaak veel meer nodig dan de standaard 151 verbindingen. Het belangrijkste nadeel van hoge waarden voor max_connections (bijvoorbeeld 1.000 of meer) is dat de server niet meer reageert als hij zoveel actieve transacties moet uitvoeren. Het gebruik van een verbindingspool op applicatieniveau of een threadpool op MariaDB-niveau kan hierbij helpen.
12. Transactie-isolatie
Onderzoek de beschikbare transactie-isolatieniveaus en bepaal de beste transactie-isolatie voor het gebruik van uw server.
13. Binair logformaat
We raden u aan de binaire log-indeling ROW te gebruiken voor master-master-replicatie.
Om de kans op botsingen tussen twee masters waarnaar tegelijkertijd wordt geschreven te verkleinen, moeten de waarden voor automatisch ophogen en automatisch ophogen dienovereenkomstig worden aangepast.
15. Binlog synchroniseren
Standaard regelt het besturingssysteem het legen van de binlog naar schijf. In het geval van een servercrash, is het mogelijk om transacties uit het binaire logboek te verliezen, waardoor de replicatie niet synchroon loopt. Door sync_binlog =1 in te stellen, wordt het binlog-bestand bij elke commit leeggemaakt.
Dit is langzamer, maar de veiligste optie.
16. Crash Safe(r) Slaves
Om replicatiefouten na een slave-crash te voorkomen, schakelt u relaislogboekherstel en synchronisatie van het relaislogboek en relaislogboekinformatiebestanden naar schijf in.
Voor geketende replicatie (master -> slave -> slave) moet log_slave_updates zijn ingeschakeld. Dit vertelt een slave om gerepliceerde transacties naar zijn eigen binaire logboek te schrijven, zodat ze vervolgens kunnen worden gerepliceerd naar slaves ervan.
Slaven moeten alleen-lezen zijn om te voorkomen dat er per ongeluk gegevens naar worden geschreven.
Opmerking :Gebruikers met superprivileges kunnen nog steeds schrijven wanneer de server alleen-lezen is.
19. Slave Net Timeout
De variabele slave_net_timeout is het aantal seconden dat de slave wacht op een pakket van de master voordat hij opnieuw probeert verbinding te maken. De standaardwaarde is 3600 (1 uur). Dit betekent dat als de link uitvalt en niet wordt gedetecteerd, het tot een uur kan duren voordat de slave opnieuw verbinding maakt. Dit kan ertoe leiden dat de slave plotseling tot een uur achterloopt op de master.
We raden aan om slave_net_timeout in te stellen op een meer redelijke waarde, zoals 30 of 60.
20. Bekijk onze webinar over voorbereiding op Black Friday en Cyber Monday
Bekijk ons on-demand webinar – Voorbereiding op Black Friday en Cyber Monday - om de vier essentiële principes van databaseparaatheid te leren: beveiligingsmaatregelen om uw database te beschermen tegen kwaadaardige aanvallen, afstemming van de prestaties om ervoor te zorgen dat u een soepele gebruikerservaring levert, strategieën voor hoge beschikbaarheid om ervoor te zorgen dat u geen enkele verkoop mist en schaalbaarheid om je voor te bereiden op zowel verwachte groei als onverwachte pieken.