Větve MySQL LTS a Innovation: kterou verzi nasadit

Pro produkční databázi na konci roku 2026 platí jediná odpověď: LTS verze, tedy MySQL 8.4 nebo MySQL 9.7. Obě dostávají opravy chyb a zabezpečení celé roky, žádná z nich nemění chování uvnitř své řady a obě jsou bezpečným cílem pro aplikaci, na kterou nechceš sahat. MySQL 8.0 je u konce - poslední vydání 8.0.46 vyšlo v dubnu 2026 a Oracle pro ni už žádné opravy nepublikuje. Verze Innovation (8.1 až 8.3, 9.0 až 9.6 a nově 26.7 s kalendářním číslováním) mají kvalitu vhodnou pro produkci, ale jsou podporované jen do vydání té následující, tedy zhruba tři měsíce. Provozovat jednu z nich znamená čtyřikrát ročně upgradovat přes vydání, která smějí něco odebrat.

Zbytek tohoto průvodce vysvětluje obě větve, termíny podpory, na kterých záleží, nová kalendářní čísla verzí, která začala v červenci 2026, upgradovací cesty, které smíš a nesmíš použít, a také to, jak verze, kterou skutečně dostaneš, závisí na zdroji: na tvé linuxové distribuci, repozitářích Oracle nebo na tagu Dockeru, který se ti může pod rukama posunout.

Dvě vydavatelské větve#

Do verze 8.0 měl MySQL pro každou hlavní verzi jednu dlouhodobou řadu a nové funkce přicházely v patch vydáních. Verze 8.0.18 přinesla hash joiny a EXPLAIN ANALYZE, verze 8.0.30 přinesla innodb_redo_log_capacity. Dva servery, které se oba jmenovaly „8.0“, se tak mohly chovat docela odlišně. Od verze 8.1 v červenci 2023 Oracle rozdělil vydání do dvou větví.

Manuál Oracle popisuje obě větve jako „production-grade quality“. Rozdíl není v kvalitě, ale ve změnách. LTS řada má zmrazené chování: verze 8.4.1 až 8.4.11 obsahují opravy, ne nové funkce ani jiné výchozí hodnoty. Právě tohle zmrazení je také důvodem, proč uvnitř LTS řady funguje downgrade na místě - formát dat se nemění, takže se můžeš vrátit z 8.4.11 na 8.4.10, pokud se některý patch chová špatně.

Vydání Innovation je pravý opak. Každé z nich může označit funkce za zastaralé nebo je odstranit, změnit rezervovaná slova, změnit chování optimalizátoru a změnit výchozí hodnoty. Manuál varuje, že tyto změny „mohou mít velký dopad“, zejména na syntaxi SQL a výkon dotazů. Funkce odstraněné během cyklu Innovation jsou odstraněné definitivně v LTS, které cyklus uzavírá. Proto přechod z 8.0 na 8.4 rozbil víc, než by číslo verze naznačovalo - všechna odstranění z verzí 8.1, 8.2 a 8.3 dorazila najednou. MySQL 8.4 LTS: co se změnilo je vypisuje.

Dosavadní vzorec: série vydání Innovation a pak LTS, které výsledek zmrazí.

Termíny podpory, na kterých záleží#

Tohle jsou data, která patří do kalendáře. Oracle Lifetime Support Policy dává LTS řadě pět let premier support a tři roky extended support, počítáno od prvního GA vydání. Pro uživatele edice Community je praktický význam jednoduchý: patch vydání přicházejí až do konce tohoto okna.

Data pro 9.7 vycházejí z pravidla pět plus tři uplatněného na GA z dubna 2026. Přesný měsíc si ověř v dokumentu o lifetime support od Oracle. Každopádně 8.4 je podporovaná ještě mnoho let - není kam spěchat a aplikace, která na 8.4 přešla v roce 2025, se nemusí stěhovat znovu do konce dekády.

K verzi 8.0: „konec životnosti“ znamená žádné další opravy od Oracle, včetně zranitelností objevených po dubnu 2026. Některé distribuce a poskytovatelé cloudu drží vlastní balíčky o něco déle - Ubuntu 22.04 a 24.04 dostaly 8.0.46 v červnu 2026 a Oracle prodloužil 8.0 na své službě HeatWave do dubna 2027 - ale to jsou poslední patche řady, kterou nikdo nevyvíjí. Server, který stále běží na 8.0, je ten, který naplánuj jako první.

Kalendářní čísla verzí od 26.7#

V červenci 2026 MySQL změnil číslování. Verze 9.7 je poslední řada se sekvenčními čísly, všechno další používá kalendářní verze ve tvaru YY.M.P - dvouciferný rok, měsíc vydání, číslo patche. Červencové vydání Innovation z roku 2026 je 26.7.0 a Oracle pojmenoval další vydání Innovation jako 26.10, 27.1, 27.4 a 27.7.

Dvě věci lidi zaskočí.

Zaprvé, číslo už neříká, o jakou větev jde. Verze 26.7 je Innovation proto, že to Oracle tvrdí, ne kvůli číslicím, a budoucí LTS bude mít také kalendářní číslo. Vždy se řiď poznámkami k vydání nebo repozitářem, ze kterého instaluješ, a nic nevyvozuj z řetězce verze. Na běžícím serveru:

SELECT @@version, @@version_comment;

@@version_comment ukazuje build, například MySQL Community Server - GPL. Buildy distribucí přidávají vlastní text.

Zadruhé, čísla patchů uvnitř LTS řady teď následují čtvrtletní bezpečnostní cyklus. Každý čtvrtletní Critical Patch Update (CPU) zvýší třetí číslo: 8.4.11, pak 8.4.12. Pokud vážná zranitelnost vyžaduje opravu mezi čtvrtletími, Oracle vydá cílený patch (CSPU) se čtvrtým číslem - 8.4.11.1, 8.4.11.2 - a další čtvrtletní vydání se vrátí ke třem číslům. U vydání Innovation zůstává třetí číslo na 0, protože opravou pro dané čtvrtletí je prostě další vydání Innovation. Instalační balíčky MSI pro Windows kódují čtyřdílné verze jinak (8.4.11.1 se v metadatech instalátoru zobrazí jako 8.4.1101), což je jen kosmetika.

Skripty, které parsují mysql --version nebo SELECT VERSION() a předpokládají jednociferné hlavní číslo verze, budou 26.7.0 číst špatně. Porovnávej verze číselně po jednotlivých složkách, ne jako řetězce, a zkontroluj monitorovací dashboardy a fakta v Ansible nebo Puppetu, která se větví podle „hlavní verze 8 nebo 9“.

Cesty upgradu a downgradu#

Model větví přichází se striktními pravidly, které skoky server podporuje na místě. Zkráceně: z LTS na další LTS, nikdy nepřeskakovat.

Pravidla, jak je uvádí referenční manuál:

• Uvnitř LTS řady jsou podporované upgrady i downgrady na místě. Z 8.4.3 na 8.4.11 a zpět je v pořádku.
• Z jedné LTS na další LTS je upgrade na místě podporovaný: 8.4.x na 9.7.x. Přeskočit LTS podporované není - z 8.4 nemůžeš rovnou na LTS, která bude následovat po 9.7.
• Vydání Innovation se dá na místě upgradovat na pozdější vydání Innovation ve stejném cyklu nebo do LTS, které cyklus uzavírá: 9.1 na 9.2 nebo 9.5 na 9.7.
• Vydání Innovation nemůže přímo přejít do dalšího cyklu. Z 8.3 se na 9.0 jde přes 8.4.
• Pouze 9.7 LTS se dá na místě upgradovat do prvního cyklu s kalendářními verzemi, který začíná verzí 26.7.
• Downgrade vydání Innovation vždy vyžaduje logický dump a načtení.

Verze 8.0 stojí před tímto modelem, ale platí stejný princip: z 8.0 na 8.4 na místě je podporované z novějšího patche 8.0, z 8.0 na 9.7 se jde přes 8.4. Verze 5.7 se musí nejdřív dostat na 8.0.

Logický dump a načtení se většině těchto omezení vyhne. Dump pomocí mysqldump nebo MySQL Shell z 8.0 nebo 8.4 se do 9.7 načte téměř vždy, protože je to jen SQL. Selhat může obsah - účty na odstraněných autentizačních pluginech, rezervovaná slova použitá jako identifikátory, definery, které neexistují. Je to také cesta pro každou hostovanou databázi, kde na serveru poskytovatele nemůžeš vyměnit binárky. Záloha a obnova pomocí mysqldump pokrývá přepínače a migrace MySQL na nový hostitel samotné přepnutí.

Před každým skokem spusť kontrolu upgradu z MySQL Shellu proti starému serveru s cílovou verzí, kterou zamýšlíš:

$ mysqlsh root@db.example.com:3306 -- util check-for-server-upgrade \    --target-version=9.7.2

Použij MySQL Shell alespoň tak nový jako cílová verze, protože kontrola zná jen verze vydané před ní.

Kterou verzi provozovat v produkci#

Pro většinu lidí je rozhodnutí mezi dvěma podporovanými LTS řadami.

Zůstaň na 8.4 nebo na ni přejdi, pokud na ní tvá aplikace už funguje, pokud ji nabízí tvůj hosting, nebo pokud ORM, ovladač či nástroje ještě nedohnaly 9.x. Verze 8.4 má premier support do roku 2029, nic tě před tím k přechodu nenutí. Je to také konzervativní cíl z 8.0, protože cesta z 8.0 na 8.4 je prošlapaná a 8.4 ti ještě dovoluje jako nouzové řešení znovu zapnout mysql_native_password.

Vyber 9.7 pro nový projekt bez historie nebo pokud chceš to, co přišlo ve verzích 9.0 až 9.6: datový typ VECTOR, novější práci na optimalizátoru a několik funkcí, které Oracle s verzí 9.7 přesunul z Enterprise do edice Community, včetně metrik replikačního applieru a statistik řízení toku ve Group Replication. Počítej s cenou: mysql_native_password byl ve verzi 9.0 odstraněn úplně, takže každý účet nebo klient, který na něm stále závisí, selže a není žádný přepínač, kterým by ses vrátil. Každý ovladač musí umět caching_sha2_password.

Použij vydání Innovation pro testování, pro vývojová prostředí, která sledují, co přichází, nebo pokud potřebuješ konkrétní funkci hned a máš tým připravený upgradovat každé čtvrtletí. Provozovat 26.x v produkci je legitimní - Oracle ji podporuje - ale jen když někdo vlastní ten čtvrtletní upgrade a testovací sada aplikace běží proti každému novému vydání.

Pravidlo, které se osvědčilo: produkce na LTS, jedna stagingová nebo CI databáze na nejnovějším vydání Innovation. Až dorazí další LTS, odstranění z éry Innovation se už v CI ukázala a produkční upgrade je naplánovaný, ne objevený.

Balíčky distribucí#

Co ti dá apt install mysql-server nebo dnf install mysql-server, závisí na vydání distribuce, ne na tom, co Oracle zrovna doporučuje. Distribuce vybírají verzi ve chvíli, kdy zmrazí vydání, a drží ji po celou dobu jeho života.

Na Ubuntu 24.04 je balíček mysql-server stále mysql-server-8.0. Ubuntu do něj v červnu 2026 dodalo 8.0.46, ale od Oracle už žádná 8.0.47 nepřijde, takže server s Ubuntu 24.04 a MySQL z distribuce běží na řadě, která se zastavila. Řešením je upgradovat operační systém na 26.04 nebo nainstalovat 8.4 z repozitáře Oracle.

Debian si zaslouží poznámku, protože lidi překvapuje: apt install default-mysql-server na Debianu nainstaluje MariaDB a příkaz mysql je klient MariaDB. MariaDB se odštěpila z MySQL 5.5 a od té doby se rozešla - není to verze MySQL, má vlastní vydání a plán podpory a nepřečte datový adresář MySQL 8.4. Pokud na Debianu potřebuješ samotný MySQL, získáš ho z APT repozitáře Oracle nebo z Dockeru.

Co máš nainstalováno, zjistíš na kterékoli z nich takto:

$ mysqld --version$ apt-cache policy mysql-server      # Debian and Ubuntu$ dnf info mysql-server              # RHEL family

Repozitáře Oracle#

Oracle publikuje repozitáře APT a Yum na repo.mysql.com a právě tam se větev volí explicitně. Balíček pro nastavení repozitáře (mysql-apt-config na Debianu a Ubuntu, mysql84-community-release a podobné na rodině RHEL) nainstaluje konfiguraci, ve které vybereš jednu řadu: repozitář 8.4 LTS, repozitář 9.7 LTS nebo repozitář Innovation.

Na straně Yum je každá větev samostatně pojmenovaný repozitář a povolíš přesně jeden. Příklad z manuálu používá mysql-innovation-community pro Innovation a mysql-9.7-lts-community pro 9.7 LTS:

$ dnf repolist all | grep mysql$ sudo dnf config-manager --disable mysql-innovation-community$ sudo dnf config-manager --enable mysql-9.7-lts-community

Na Debianu a Ubuntu se volba dělá v dialogu při instalaci mysql-apt-config a později ji lze změnit:

$ sudo dpkg-reconfigure mysql-apt-config$ sudo apt update

Smysl výběru větve místo verze se ukáže při apt upgrade. Repozitář LTS tě posune z 8.4.10 na 8.4.11 a nikdy na 9.7. Repozitář Innovation tě posune z jednoho vydání Innovation na další, což Innovation znamená, a úloha unattended-upgrades namířená na něj provede funkční upgrade tvé databáze, kdykoli Oracle něco vydá. Na produkčním serveru povol repozitář LTS a nic jiného. Také ověř, že Oracle pro tvé vydání distribuce repozitář publikuje, než se na něj spolehneš - nová vydání distribucí se někdy přidávají měsíce po svém uvedení.

Tagy obrazů Dockeru#

Oficiální obraz mysql na Docker Hubu mapuje tagy na větve a některé z nich se posouvají. K říjnu 2026 jsou podporované tyto tagy:

Každý má varianty -oracle nebo -oraclelinux9, všechny současné obrazy jsou postavené na Oracle Linux 9. Varianty obrazů na bázi Debianu patřily k 8.0 a zanikly s ní a mysql:8.0 už není v seznamu podporovaných - tag se pořád stáhne, ale nikdo ho nebude znovu sestavovat.

Většinu nehod způsobují tři tagy.

latest je vydání Innovation. Soubor Compose s image: mysql nebo image: mysql:latest při příštím docker compose pull upgraduje databázi na aktuální vydání Innovation - a protože downgrady Innovation vyžadují dump a načtení, změnou tagu se zpět nevrátíš.

lts se posunul. Dokud v dubnu 2026 nevyšla 9.7, byl mysql:lts verze 8.4. Kdo se připnul na lts s tím, že to znamená „stabilní“, dostal při dalším pullu upgrade na místě z 8.4 na 9.7 - podporovaný upgrade, ale takový, který odstranil mysql_native_password a nešlo ho vrátit přepnutím tagu. lts se posune znovu, až dorazí další LTS.

8 se posunul také. Za života 8.0 ukazoval na 8.0 a nyní ukazuje na 8.4.

Bezpečný postup je připnout se na řadu, kterou sis vybral, a nechat patche přicházet:

services:  db:    image: mysql:8.4    environment:      MYSQL_ROOT_PASSWORD_FILE: /run/secrets/mysql_root      MYSQL_DATABASE: app    volumes:      - db-data:/var/lib/mysql

mysql:8.4 přebírá patche 8.4 a nikdy nepřeskočí na jinou řadu. Pokud chceš, aby i každý patch byl rozhodnutím, připni plnou verzi (mysql:8.4.11) a zvyšuj ji sám. V obou případech verzi dál nese datový adresář ve volume: kontejner spuštěný z novější řady ho při prvním startu upgraduje a starší řada na něm odmítne nastartovat. Docker Compose pro malé stacky pokrývá volumes a secrets podrobněji.

Kontrola a plánování tvé verze#

Krátký audit pro každý MySQL, za který odpovídáš:

1. Zjisti přesnou verzi pomocí SELECT @@version; a odkud pochází: balíček distribuce, repozitář Oracle, tag Dockeru nebo hostingový poskytovatel.
2. Přiřaď ji k větvi a termínu podpory podle tabulek výše. Cokoli na 8.0, 5.7 nebo na vydání Innovation, které není nejnovější, je teď bez podpory.
3. Zkontroluj, jak se aktualizuje. Balíček distribuce následuje distribuci, repozitář Oracle větev, kterou jsi povolil, tag Dockeru to, na co tag ukazuje, a hostovaná databáze poskytovatele.
4. Pokud se potřebuješ přesunout, vyber cílovou LTS, spusť kontrolu upgradu, přesuň autentizaci pryč z mysql_native_password (viz uživatelé a oprávnění v MySQL) a vyzkoušej to na kopii.
5. Datum konce podpory řady, na které skončíš, si zapiš do kalendáře rok předem.

FAQ#

Je MySQL 9.7 vydání LTS?

Ano. MySQL 9.7.0 vyšel v dubnu 2026 jako druhá řada LTS po 8.4 a uzavírá cyklus Innovation 9.x, který začal verzí 9.0. Je to také poslední řada se sekvenčními čísly verzí, pozdější vydání používají kalendářní verze jako 26.7.

Je bezpečné provozovat vydání Innovation v produkci?

Oracle ho podporuje a nazývá ho kvalitou pro produkci, takže to není lehkomyslné. Zádrhel je v okně podpory: každé vydání Innovation se patchuje jen do příštího, takže zůstat v podpoře znamená funkční upgrade zhruba každé tři měsíce a každý z nich může něco odebrat. Pokud nemáš čas každý z nich otestovat, použij LTS.

Můžu upgradovat z MySQL 8.0 rovnou na 9.7?

Na místě ne. Podporovaná cesta na místě je 8.0 na 8.4 a pak 8.4 na 9.7. Logický dump z 8.0 načtený do čistého serveru 9.7 obvykle funguje, pokud žádné účty nezávisí na mysql_native_password a kontrola upgradu nehlásí nic vážného.

Co mi dá mysql:latest v Dockeru?

Aktuální vydání Innovation - k říjnu 2026 verzi 26.7. Mění se každé čtvrtletí. Pro databázi, na které ti záleží, se připni na mysql:8.4 nebo mysql:9.7, ne na latest a ne na lts, protože lts se posune na další LTS, až vyjde.

Musím opustit MySQL 8.4 kvůli 9.7?

Ne. Verze 8.4 má premier support do dubna 2029 a extended support do dubna 2032 a stále dostává čtvrtletní patch vydání. Přechod na 9.7 stojí za to naplánovat před rokem 2029, ale dřív žádný termín není.

Je MariaDB verze MySQL?

Ne. MariaDB vznikla jako fork MySQL 5.5 a dnes je to samostatná databáze s vlastními verzemi a plánem podpory. Debian ji nainstaluje, když požádáš o default-mysql-server. Pro většinu klientů mluví stejným protokolem, ale její datové soubory a novější funkce nejsou zaměnitelné s MySQL 8.4 ani 9.7.