Údržba databáze
Představte si databázi jako srdce informačního systému. Její instalace a naplnění daty jsou pouze prvním krokem; aby však toto srdce spolehlivě tepalo i pod rostoucí zátěží a v neustále se měnícím digitálním prostředí, vyžaduje systematickou a odbornou péči. Údržba databáze (DB Maintenance) není jednorázový úkol, nýbrž kontinuální proces, jehož cílem je zajistit tři základní pilíře: integritu dat, vysokou dostupnost a optimální výkon.
V rámci správy databázového systému se údržba zaměřuje na předcházení kritickým stavům dříve, než nastanou. Kvalitní strategie údržby tvoří štít proti ztrátě dat při haváriích, chrání systém před bezpečnostními hrozbami a zajišťuje, že odezva aplikace zůstane blesková i při zpracování obrovských objemů informací. Následující kapitola podrobně rozebírá klíčové aspekty této správy – od technických operací, jako je zálohování a správa diskového prostoru, až po analytické činnosti, kam řadíme monitorování výkonu a optimalizaci dotazů.
Hlavní pilíře efektivní údržby
Pro dosažení stabilního a bezpečného databázového prostředí se budeme věnovat těmto klíčovým oblastem:
- kontinuita a bezpečí: jak zajistit, aby data byla v bezpečí před útoky i technickými selháními (Zálohování, Aktualizace, Správa uživatelů);
- efektivita a rychlost: metody, jak udržet databázi v nejlepší kondici a předcházet jejímu zpomalování (Optimalizace dotazů, Monitoring);
- provozní hygiena: správa fyzických prostředků a čištění databáze od zbytečné zátěže (Správa diskového prostoru).
Zálohování databázového systému
Pravidelné zálohování dat je klíčové pro úspěšnou údržbu databázového systému. Je důležité vytvářet pravidelné zálohy dat, abyste se v případě havárie nebo jiného výpadku mohli vrátit k předchozímu stavu.
Typy záloh
Při plánování zálohování v databázovém systému je nutné najít rovnováhu mezi časem potřebným pro zálohu, nároky na diskový prostor a rychlostí následné obnovy.
- plné zálohy (většinou za delší časové období, například měsíčně či týdně)
- výhoda: nejjednodušší a nejrychlejší obnova (stačí jeden soubor)
- nevýhoda: trvá nejdéle a zabírá nejvíce místa
- diferenciální zálohy (ukládá všechny změny, které proběhly od poslední plné zálohy)
- výhoda: rychlejší než plná záloha – při obnově potřebujete jen poslední plnou zálohu a poslední diferenciální soubor
- nevýhoda: zabírá více místa než inkrementální zálohy
- inkrementální zálohy (ukládá pouze změny, které nastaly od poslední zálohy jakéhokoliv typu (plné i inkrementální)
- výhoda: nejšetrnější k diskovému prostoru, nejrychlejší na vytvoření
- nevýhoda: nejsložitější obnova (musíme mít celou řetězovou posloupnost všech souborů od poslední plné zálohy)



Klíčové zásady pro zálohování
- automatika: zálohování by mělo probíhat automaticky (využíváme plánovač úloh typu linuxového cron)
- izolace: zálohy nikdy nesmí zůstat pouze na stejném diskovém oddílu (nebo dokonce stejném serveru) jako běžící databáze. Pokud selže hardware serveru, přijdete o obojí
- pravidlo 3-2-1: mít alespoň 3 kopie dat, na 2 různých typech médií a 1 kopii mít v jiné geografické lokalitě (např. cloudové úložiště nebo jiný datacentrum)
- restrikce přístupu: složka se zálohami musí být přístupná pouze pod speciálním systémovým účtem. Útočník, který získá přístup k aplikaci, by neměl mít možnost zálohy smazat.
Pravidelnost a testování
Mnoho administrátorů se dopouští chyby, že sledují pouze to, zda „skript doběhl v pořádku“. Skutečným měřítkem úspěchu je ale schopnost data obnovit.
Zlaté pravidlo: Záloha, která nebyla nikdy cvičně obnovena, jako by neexistovala.
- frekvence: standardem je plná záloha 1× denně v časech nejnižší zátěže (v noci), doplněná o inkrementální zálohy každých pár hodin (nebo dokonce minut u kritických systémů);
- verifikace: doporučuje se nastavit automatizovaný proces, který jednou týdně vezme poslední zálohu, zkusí ji „nalít“ na testovací server a ověří, zda jsou data čitelná a konzistentní.
Aktualizace databázového systému
Je důležité aktualizovat databázový software na nejnovější verzi, aby byly zajištěny nejlepší výkonnost a bezpečnost. Většina aktualizací obsahuje opravy chyb a bezpečnostní aktualizace, které jsou důležité pro bezpečnost vašich dat.
Každá aktualizace musí být dobře naplánovaná – aktualizace znamená minimálně restart databáze, tj. musí se provádět tak, aby výpadek minimalizoval vliv na aplikace (uživatele), které databázi používají.
Před aktualizací se vždy provádí kompletní záloha.
Po aktualizaci nezapomenout aktualizovat dokumentaci.
Kontrola kompatibility
- jedná-li se o větší aktualizaci, je potřeba provést aktualizaci nejprve na testovacím serveru a umožnit testování také aplikacím;
- snaha je předejít možným problémům aplikací (funkčním, výkonovým, stabilita) s novou verzí databázového serveru
Průběh aktualizace databázového systému
- plánování
- závisí na dostupnosti týmu
- závisí na možném termínu vypnutí aplikací
- všechny kroky, fallback scenario
- komunikace s vývojáři, service deskem
- testování
- většinou v odlišném (testovacím) prostředí
- např. na speciálně k tomu účelu vytvořeném serveru
- vlastní aktualizace (upgrade)
- kompletní záloha
- příprava
- odstávka
- instalace
- restart
- testování
- GoLive / FallBack
- monitorování
- dokumentace
Správa uživatelů a oprávnění
Správa uživatelských účtů a přístupových práv je důležitá pro zajištění bezpečnosti dat. Je důležité kontrolovat a spravovat přístupová práva uživatelů a minimalizovat rizika zneužití a neoprávněného přístupu k datům.
Účet v databázi by neměl existovat „navždy“. Největším bezpečnostním rizikem jsou tzv. zombie účty – účty bývalých zaměstnanců nebo lidí, kteří změnili pracovní pozici, ale jejich přístup zůstal aktivní.
- automatizace a centralizace: Ideálním stavem je napojení MariaDB na centralizovanou správu identit (např. LDAP nebo Active Directory). Pokud uživatel odejde z firmy a je deaktivován v AD, automaticky ztratí přístup i do databáze.
- pravidlo 90 dní: Pokud se uživatel 3 měsíce nepřihlásil, je pravděpodobné, že přístup již nepotřebuje. Automatizované skripty by měly takové účty detekovat a preventivně zablokovat.
- změna role: Při přestupu mezi odděleními je nutné provést revizi práv. Vývojář, který se stal manažerem, už pravděpodobně nepotřebuje práva
DROP TABLE.
Princip nejmenších funkčních oprávnění (Least Privilege)
Tento princip říká, že uživatel by měl mít minimální možnou úroveň oprávnění, která mu ještě umožní vykonávat jeho práci.
- granularita: MariaDB umožňuje definovat práva na úrovni globální, databázové, tabulkové, nebo dokonce na úrovni konkrétních sloupců.
- proč je
GRANT ALLzlo? Pokud útočník kompromituje účet s nadbytečnými právy, může smazat celou databázi. Pokud má uživatel jenSELECTnad jednou tabulkou, škoda je limitována. - oddělení rolí: Místo přidělování práv jednotlivcům je lepší vytvářet role (např.
ReadOnly_Analyst,App_Service,DB_Admin) a ty pak přiřazovat uživatelům. V databázovém systému MariaDB bohužel správa rolí implementována není.
Auditování
Auditování je „černá skříňka“ vaší databáze. Slouží k forenzní analýze po incidentu, ale také k dodržování legislativních požadavků (např. GDPR).
Audit přihlašování (Access Logs)
Sledujeme samotný vstup do systému. Pokud vidíme 50 neúspěšných pokusů o přihlášení z neznámé IP adresy během minuty, víme, že čelíme útoku typu Brute Force.
Záznam obsahuje: Čas, uživatelské jméno, zdrojovou IP adresu, výsledek (úspěch/neúspěch) a délku relace.
Audit operací (DML/DDL Audit)
U citlivých dat (např. platy zaměstnanců, osobní údaje) nestačí vědět, že se někdo přihlásil. Musíme vědět, co přesně dělal.
- Změnový log: Sledování příkazů
INSERT,UPDATE,DELETE. - Strukturální změny: Kdo změnil oprávnění jinému uživateli (
GRANT/REVOKE) nebo kdo smazal tabulku (DROP).
Sledování pomalých dotazů a jejich optimalizace
Je důležité optimalizovat dotazy na databázi pro dosažení nejlepší výkonnosti a rychlosti. Tímto způsobem můžete minimalizovat čas na vyhledání a načtení dat.
Pomalé dotazy mohou zpomalit výkon celého systému a způsobovat zpoždění ve vyhodnocování všech dotazů.
Zodpovědností databázového specialisty je sledovat nejpomalejší dotazy a předávat informace na aplikační nebo databázové vývojáře pro optimalizaci.
Úspěšnou optimalizací se může oddálit potřeba zvyšování výkonu databáze (šetří se tak prostředky).
Způsob logování na MariaDB
Nastavení si zobrazíme následujícím způsobem:
SHOW GLOBAL VARIABLES LIKE "%slow_query%";
+---------------------+-----------------+
| Variable_name | Value |
+---------------------+-----------------+
| slow_query_log | ON |
| slow_query_log_file | aleman-slow.log |
+---------------------+-----------------+
2 rows in set (0.006 sec)
Logování nastavíme pomocí příkazu:
SET GLOBAL slow_query_log=1;
Soubor je defaultně uložen ve složce /var/lib/mysql/

Monitorování výkonu
Sledování výkonu databáze v reálném čase může pomoci odhalit případné problémy nebo úzká místa výkonu a umožnit včasnou reakci na tyto situace.
- využití CPU – míra využití procesoru v čase (pokud vyroste nad určitou mez – např. 60% – a dále roste, signalizuje to potřebu upgradu nebo přidání další CPU);
- využití paměti – kolik operační paměti databázový server využívá v čase;
- diskové operace – čtení a zápis na disk, fragmentace, nutnost přenastavení přístupu k disku;
- síťová prostupnost – využití dostupné šířky sítě v čase může včas identifikovat problémy s výkonem;
- počet připojených klientů, sessions
- pomalé dotazy (slow queries)

Clusterizace databáze
Clusterizace posouvá správu databáze z úrovně „jednoho serveru“ do světa vysoké dostupnosti (High Availability) a horizontálního škálování. Zatímco běžná údržba (zálohy, aktualizace) chrání data, clusterizace chrání provoz systému před výpadkem a přetížením.
Replikace je proces automatického kopírování dat z jednoho databázového uzlu (node) na druhý. Podle toho, jak k zápisu a čtení přistupujeme, rozlišujeme dva hlavní modely:
Replikace Master-Slave (Primary-Replica)
V tomto modelu existuje jasná dělba rolí. Master (primární uzel) je jediným místem, kam aplikace zapisuje data. Slaves (repliky) pak tyto změny přebírají.
- využití: ideální pro aplikace, kde výrazně převažuje čtení nad zápisem (např. e-shopy, zpravodajské portály);
- výhoda: odlehčení hlavnímu serveru – analytické dotazy nebo generování reportů běží na replikách a nebrzdí zápisy.
Multi-Master replikace
Všechny uzly v clusteru jsou si rovny a na každý z nich lze zapisovat. To vyžaduje komplexní mechanismus pro řešení konfliktů.
- využití: kritické systémy, kde je nepřípustné, aby výpadek jednoho zapisovacího uzlu zastavil celou aplikaci.

Synchronizace: bezpečnost vs. rychlost
Při replikaci dat mezi uzly musíme vyřešit zásadní otázku: Kdy považujeme transakci za dokončenou?
| Typ | Princip | Výhody | Nevýhody |
| Synchronní | Transakce je potvrzena, až když ji zapíšou všechny uzly. | 100% konzistence, nulová ztráta dat při výpadku. | Latence (čeká se na nejpomalejší uzel), riziko zastavení při výpadku sítě. |
| Asynchronní | Master potvrdí zápis ihned a replikám ho pošle „na pozadí“. | Maximální rychlost a propustnost. | Riziko ztráty posledních transakcí, pokud Master havaruje dříve, než data odešle. |
Sharding (horizontální škálování)
Pokud už data narostou do takových rozměrů, že je jeden server nezvládne efektivně indexovat (ani v clusteru), nastupuje Sharding.
Místo jedné obří tabulky data „rozsekáme“ na menší logické kusy (shardy) a ty rozmístíme na různé fyzické stroje. Například:
- Uživatelé s ID 1–1 000 000 jsou na Serveru A.
- Uživatelé s ID 1 000 001–2 000 000 jsou na Serveru B.
Pozor na složitost: Sharding je „architektonické peklo“. Jakmile potřebujete spojit data (JOIN) ze dvou různých shardů, výkon rapidně klesá a logika aplikace se extrémně komplikuje. Sharding by měl být až poslední možností, když běžná clusterizace nestačí.
Load Balancing
Aby uživatel nemusel řešit, na který server se zrovna připojit, staví se před cluster Load Balancer (např. HAProxy nebo MariaDB MaxScale).
Tato vrstva funguje jako inteligentní směrovač:
- zápisy posílá na Mastera.
- čtení rozděluje mezi dostupné Slavy podle jejich aktuálního vytížení.
- Health Check: Pokud některý uzel v clusteru „umře“, Load Balancer ho okamžitě vyřadí z provozu, dokud nebude opět v pořádku.

Správa diskového prostoru
Je důležité sledovat diskový prostor, který databáze používá, aby se zabránilo situacím, kdy diskový prostor dosáhne svého limitu a databáze bude přestávat pracovat. Je důležité pravidelně provádět údržbu databáze, například odstraňovat nepotřebné tabulky nebo indexy, aby se minimalizovalo množství dat, které databáze používá. Také může být užitečné používat nástroje pro správu diskového prostoru, jako jsou například nástroje pro monitorování disku a jeho využití.
Neřešte stav, řešte trend.
Sledovat, že máte „teď hned“ 50 GB volného místa, nestačí. Klíčem k profesionální správě je plánování kapacity diskového prostoru.
Sledování vývoje v čase: Pomocí monitorovacích nástrojů (např. Zabbix, Grafana, Prometheus) sledujeme křivku zaplnění. Pokud víme, že databáze roste o 2 GB týdně, dokážeme přesně předpovědět, kdy narazíme na limit, a s předstihem objednat nový hardware.
Pravidlo 20 %: Proč neplnit disk na 100 %?
- operační systém: potřebuje místo pro swap, logy a dočasné soubory;
- databázové operace: při operacích jako
ALTER TABLEnebo při vytváření indexů si databáze často vytváří dočasné kopie tabulek. Pokud nemáte rezervu, tyto operace selžou. - fragmentace: extrémně plné disky trpí vyšší fragmentací na úrovni souborového systému, což zpomaluje zápis i čtení.
Řešení nedostatku místa
Když se disk začne plnit, máme tři hlavní cesty, jak situaci řešit:
- Rozšíření kapacity (Scaling)
- Přidání disků je nejrychlejší, ale nejdražší cesta.
- Enterprise realita: V profesionálním prostředí nekupujeme „disky z e-shopu“. Jde o disková pole (SAN/NAS) s vysokou redundancí (RAID), vysokým počtem operací za sekundu (IOPS) a garantovanou životností. Cena za 1 GB je zde mnohonásobně vyšší než u běžných PC.
- Archivace dat (Data Retention)
- ne všechna data musí být v „živé“ databázi navždy. Zde nastupuje spolupráce s vývojáři a byznysem.
- Definice retence: Jak staré objednávky musíme mít v primární databázi? Stačí 2 roky?
- Cold Storage: Starší data se přesunou do levnějšího úložiště (např. do jiné DB, do CSV souborů v cloudu nebo do analytického skladu), kde k nim není potřeba bleskový přístup.
- Pravidelné čištění (Purging & Optimization)
- Databáze po smazání řádků místo na disku automaticky nevrací operačnímu systému (soubor se nezmenší).
- Logy: Pravidelné odstraňování nebo rotace binárních logů (
binlogs), error logů a slow query logů. - Fragmentované tabulky: Pokud z tabulky smažete 1 milion řádků, soubor na disku zůstane stejně velký. Je nutné použít příkaz
OPTIMIZE TABLE, který tabulku „přeskládá“ a uvolní prázdné místo (tzv. overhead).