Největší dny pro online nakupování v roce jsou za dveřmi. Je vaše databáze připravena? Vyladěním 20 klíčových systémových proměnných MariaDB podpoříte výkon své databáze , škálovatelnost a dostupnost , která zajistí, že každý potenciální zákazník bude mít bezproblémovou uživatelskou zkušenost. Při konfiguraci optimálního prostředí serveru MariaDB se opakovaně objevují následující systémové proměnné. Implementujte naše doporučení pro ty nejvyladěnější hodnoty a udělejte z letošního Černého pátku – Cyber Monday to nejlepší vůbec.
Několik důležitých poznámek:
- Nepřijímejte tyto návrhy slepě. Každé prostředí MariaDB je jedinečné a vyžaduje další promyšlení před provedením jakýchkoli změn. S největší pravděpodobností budete muset tato nastavení upravit pro váš konkrétní případ použití a prostředí.
- Konfigurační soubor MariaDB se nachází v /etc/my.cnf. Pokaždé, když tento soubor upravíte, budete muset restartovat službu MySQL, aby se nové změny projevily.
20 doporučení pro ladění Černého pátku a kybernetického pondělí
1. Velikost vyrovnávací paměti InnoDB
Velikost fondu vyrovnávacích pamětí InnoDB toto je nastavení číslo 1, které je třeba sledovat u každé instalace využívající InnoDB. Ve fondu vyrovnávacích pamětí jsou data a indexy ukládány do mezipaměti; jeho co největší velikost zajistí, že pro většinu operací čtení použijete paměť, nikoli disky.
>2. Velikost souboru protokolu InnoDB
innodb_log-file-size je velikost opakovaných protokolů, které se používají k zajištění rychlého a trvalého zápisu. Existují dva obecné návrhy pro velikost souboru protokolu InnoDB:
- Nastavte kombinovanou celkovou velikost souborů protokolu InnoDB větší než 25–50 % velikosti fondu vyrovnávací paměti InnoDB
nebo
- Nastavte kombinovanou velikost souboru protokolu InnoDB na hodnotu jedné hodiny záznamů protokolu během špičkového zatížení
Větší soubory protokolu mohou vést k pomalejší obnově v případě selhání serveru. Snižují však také počet potřebných kontrolních bodů a snižují I/O disku.
Vyhodnoťte velikost jedné hodiny binárních protokolů při provozní zátěži a poté se rozhodněte, zda chcete zvětšit velikost souborů protokolu InnoDB.
Správné nastavení velikosti souborů protokolu innodb je důležité pro dosažení dobrého výkonu systému. Úložný modul InnoDB společnosti MariaDB používá pevný (kruhový) prostor redo logu. Velikost je řízena innodb_log_file_size a innodb_log_files_in_group (výchozí 2). Vynásobením těchto hodnot získáte prostor redo log, který je k dispozici pro použití. I když by technicky nemělo záležet na tom, zda použijete proměnnou innodb_log_file_size nebo innodb_log_files_in_group k ovládání velikosti prostoru opakování, většina lidí prostě pracuje s innodb_log_file_size a nechá innodb_log_files_in_group na pokoji.
Velikost redo prostoru InnoDB je jednou z nejdůležitějších možností konfigurace pro zátěže náročné na zápis. Přichází však s kompromisy. Čím více prostoru pro opakování je nakonfigurováno, tím lépe může InnoDB optimalizovat I/O zápisu. Zvětšení prostoru pro opakování však také znamená delší dobu obnovy, když systém ztratí napájení nebo se zhroutí z jiných důvodů.
3. Velikost vyrovnávací paměti protokolu InnoDB
Větší velikost vyrovnávací paměti protokolu InnoDB znamená méně diskových I/O pro větší transakce. Doporučuje se nastavit toto na 64M na všech serverech.
4. InnoDB Log Flush Interval
Proměnná innodb_flush_log_at_trx_commit řídí, kdy dojde k vyprázdnění vyrovnávací paměti protokolu na disk. innodb_flush_log_at_trx_commit =1 (výchozí) vyprázdní vyrovnávací paměť protokolu na disk při každém potvrzení transakce. Toto je nejbezpečnější, ale také nejméně výkonná možnost.
innodb_flush_log_at_trx_commit =0 každou sekundu vyprázdní vyrovnávací paměť protokolu na disk, ale při potvrzení transakce nic. Může dojít ke ztrátě až jedné sekundy (možná více kvůli plánování procesu). Pokud dojde k nějakému selhání, MySQL nebo server mohou ztratit data. Toto je nejrychlejší, ale nejméně bezpečná možnost.
innodb_flush_log_at_trx_commit =2 zapíše vyrovnávací paměť protokolu do souboru při každém potvrzení, ale každou sekundu se vyprázdní na disk. Pokud má mezipaměť disku záložní baterii (například řadič raid mezipaměti zálohovaný baterií), jedná se obecně o nejlepší rovnováhu mezi výkonem a bezpečností. Pád MySQL by neměl přijít o data. Selhání serveru nebo výpadek napájení může ztratit až sekundu (možná i více kvůli plánování procesu). Baterií zálohovaná mezipaměť tuto možnost snižuje.
Pro bezpečnost doporučujeme použít první možnost.
5. Kapacita InnoDB IO
kapacita innodb_io_capacity by měla být nastavena přibližně na maximální počet IOPS, který dokáže základní úložiště zpracovat.
Ve výchozím nastavení je tato hodnota nastavena na 1000. Doporučujeme provést benchmarking úložiště, abyste zjistili, zda můžete tuto hodnotu dále zvýšit.
6. Velikost mezipaměti vláken
Sledujte hodnotu Threads_created. Pokud se stále zvyšuje rychlostí vyšší než několik vláken za minutu, zvyšte hodnotu thread_cache_size.
Velikost mezipaměti vláken je v aktuální výchozí konfiguraci nastavena na 200.
7. Mezipaměť tabulek a Mezipaměť definic tabulek
Proměnné table_open_cache a table_defintion_cache řídí počet tabulek a definic, které mají zůstat otevřené pro všechna vlákna.
Sledujte Open_tables, Open_table_definitions, Opened_tables a Opened_table_definitions, abyste určili nejlepší hodnotu. Obecným návrhem je nastavit table_open_cache (a následně table_definition_cache) pouze dostatečně vysoko, aby se snížila rychlost nárůstu hodnoty stavu Opened_tables (a Opened_table_definitions).
Table_open_cache i table_defintion_cache jsou ve výchozí konfiguraci nastaveny na 2048.
8. Mezipaměť dotazů
Mezipaměť dotazů je dobře známým úzkým hrdlem, které lze pozorovat i při mírné souběžnosti. Nejlepší možností je deaktivovat ji od prvního dne nastavením query_cache_size =0 (výchozí v MariaDB 10) a použít jiné způsoby, jak urychlit čtení dotazů:dobré indexování, přidávání replik pro rozložení zátěže čtení nebo použití externí mezipaměti ( memcache nebo redis, například). Pokud jste již vytvořili svou aplikaci MariaDB s povolenou mezipamětí dotazů a nikdy jste nezaznamenali žádný problém, může být pro vás mezipaměť dotazů prospěšná. V takovém případě buďte opatrní, pokud se jej rozhodnete deaktivovat.
9. Dočasné tabulky, tmp_table_size a max_heap_table_size
MySQL používá nižší z hodnot max_heap_table_size a tmp_table_size k omezení velikosti dočasných tabulek v paměti. Jedná se o proměnné pro klienta. Tato velká hodnota sice může pomoci snížit počet dočasných tabulek vytvořených na disku, ale také zvyšuje riziko dosažení kapacity paměti serveru, protože se jedná o jednoho klienta. Obecně je doporučená hodnota pro začátek pro obě proměnné 32 až 64 milionů a podle potřeby doladění.
Dočasné tabulky se často používají pro GROUP BY, ORDER BY, DISTINCT, UNION, dílčí dotazy atd. V ideálním případě by je MySQL měla vytvářet v paměti s co nejmenším počtem na disku.
Je důležité si uvědomit, že dotazy, které správně nepoužívají spojení, a vytváření velkých dočasných tabulek mohou být jedním z důvodů vyššího počtu dočasných tabulek na disku. Dalším důvodem je, že paměťový modul používá sloupce s pevnou délkou a předpokládá nejhorší scénář. Pokud sloupce nemají správnou velikost (například VARCHAR(255) pro krátký řetězec), ovlivní to velikost tabulky v paměti a může způsobit, že se na disk přesune dříve, než by měla. Dočasné tabulky se sloupci blob a text se také okamžitě přesunou na disk, protože je paměťový modul nepodporuje.
Obě jsou aktuálně standardně nastaveny na 64 milionů.
10. Úroveň protokolu varování
Doporučujeme nastavit úroveň protokolu varování na log_warnings =2. Pokud tak učiníte, budou protokolovat informace o přerušených připojeních a chybách s odepřeným přístupem.
11. Max připojení
Pokud se často setkáváte s chybou „Příliš mnoho připojení“, je hodnota max_connections příliš nízká. Protože aplikace neuzavírá připojení k databázi správně, často potřebujete mnohem více než výchozích 151 připojení. Hlavní nevýhodou vysokých hodnot pro max_connections (řekněme 1 000 nebo více) je to, že server přestane reagovat, pokud musí spustit tolik aktivních transakcí. Zde může pomoci použití fondu připojení na úrovni aplikace nebo fondu vláken na úrovni MariaDB.
12. Izolace transakcí
Prozkoumejte dostupné úrovně izolace transakcí a určete nejlepší izolaci transakcí pro případ použití vašeho serveru.
13. Binární formát logu
Pro replikaci master-master doporučujeme použít formát binárního protokolu ROW.
14. Auto-Increment Offsets
Aby se snížila pravděpodobnost kolize mezi dvěma mastery, které budou zapsány současně, je třeba odpovídajícím způsobem upravit hodnoty automatického přírůstku a posunu automatického přírůstku.
15. Synchronizovat Binlog
Operační systém ve výchozím nastavení zpracovává vyprázdnění binlogu na disk. V případě selhání serveru je možné ztratit transakce z binárního protokolu, což vede k nesynchronizaci replikace. Nastavení sync_binlog =1 způsobí vyprázdnění souboru binlog při každém odevzdání.
Toto je pomalejší, ale nejbezpečnější možnost.
16. Crash Safe(r) Slaves
Chcete-li zabránit chybám replikace po havárii podřízeného zařízení, povolte obnovení protokolu přenosu a synchronizaci souborů protokolu přenosu a informačních souborů protokolu přenosu na disk.
17. Log Slave Updates
Chcete-li mít zřetězenou replikaci (master -> slave -> slave), je třeba povolit log_slave_updates. To podřízenému zařízení říká, aby zapisoval replikované transakce do vlastního binárního protokolu, aby je pak bylo možné replikovat na podřízené mimo něj.
18. Slave pouze pro čtení
Podřízené jednotky by měly být pouze pro čtení, aby do nich nebyla náhodně zapsána data.
Poznámka :Uživatelé se super právy mohou stále zapisovat, když je server pouze pro čtení.
>19. Slave Net Timeout
Proměnná slave_net_timeout je počet sekund, po které bude slave zařízení čekat na paket od hlavního zařízení, než se pokusí znovu připojit. Výchozí hodnota je 3600 (1 hodina). To znamená, že pokud se odkaz přeruší a není detekován, může trvat až hodinu, než se slave znovu připojí. To by mohlo vést k tomu, že otrok bude najednou až hodinu za pánem.
Doporučujeme nastavit slave_net_timeout na rozumnější hodnotu, například 30 nebo 60.
20. Podívejte se na náš webinář o přípravě na černý pátek a kybernetické pondělí
Podívejte se na náš webový seminář na vyžádání – Příprava na Černý pátek a Cyber Monday – a naučte se čtyři zásadní principy připravenosti databáze: bezpečnostní opatření k ochraně vaší databáze před škodlivými útoky, ladění výkonu abyste zajistili hladký uživatelský dojem, strategie vysoké dostupnosti aby vám neunikl jediný prodej a škálovatelnost připravit se na očekávaný růst i neočekávané skoky.