Aktualizacja MySQL 8.0 do 8.4 w Dockerze krok po kroku

Aby zaktualizować MySQL 8.0 do 8.4 w Dockerze, zrób kopię bazy, zmień obraz na przypięty tag mysql:8.4.x i w tej samej edycji usuń flagę --default-authentication-plugin, której 8.4 już nie zna. Potem uruchom docker compose up -d – serwer sam zaktualizuje katalog danych przy pierwszym starcie. To operacja jednokierunkowa: katalog danych 8.4 nie wystartuje już na 8.0, więc kopia zapasowa jest jedyną drogą powrotu.

Dlaczego aktualizować MySQL 8.0 do 8.4 właśnie teraz?

Bo MySQL 8.0 nie jest już utrzymywany: Oracle podaje, że MySQL 8.0 osiągnął koniec życia (EOL) w kwietniu 2026 r., a ostatnim wydaniem poprawkowym jest 8.0.46. Kontener z 8.0 dalej działa, ale nie dostaje poprawek bezpieczeństwa, więc każda nowa luka w serwerze zostaje otwarta na Twoim VPS-ie.

MySQL 8.4 to seria długoterminowa (LTS), która zastępuje 8.0. Oficjalna lista ścieżek aktualizacji wymienia przejście „8.0 → 8.4.x LTS” jako wspierane przez aktualizację w miejscu, przez zrzut logiczny i ponowne wczytanie albo przez replikację. Dla jednego kontenera najprostsza jest aktualizacja w miejscu: uruchamiasz nowy obraz na starym wolumenie, a serwer sam aktualizuje słownik danych i tabele systemowe. Od MySQL 8.0.16 robi to samodzielnie, więc osobne uruchamianie mysql_upgrade nie jest potrzebne.

Dwie rzeczy na Docker Hubie sprawiają, że sprawa jest pilna. Po pierwsze, oficjalny obraz mysql nie ma już tagu 8.0 na liście wspieranych; 8.4 i 8 wskazują teraz na 8.4.13. Po drugie, tagi „pływające” poszły dalej: lts wskazuje na 9.7, a latest na serię innowacyjną 26.x. Plik compose z nieprzypiętym image: mysql albo mysql:lts może przy najbliższym docker compose pull przeskoczyć 8.4 i trafić na wersję, w której mysql_native_password w ogóle nie istnieje.

⚠️ Uwaga: Zawsze przypinaj obraz MySQL do serii albo konkretnej wersji (mysql:8.4 lub mysql:8.4.13). Zmiana wersji głównej ma być Twoją decyzją podjętą z kopią w ręku, a nie efektem ubocznym pobrania obrazów.

Co przestaje działać po zmianie obrazu na mysql:8.4?

Najczęściej kontener kończy pracę od razu, bo jego command: wciąż przekazuje --default-authentication-plugin=mysql_native_password – opcję, którą 8.4 usunął. Wiele plików compose pisanych pod MySQL 8.0 zawiera dokładnie taką linię:

services:
  db:
    image: mysql:8.0
    command: --default-authentication-plugin=mysql_native_password --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci
    volumes:
      - dbdata:/var/lib/mysql

Po uruchomieniu na mysql:8.4 ta usługa zatrzymuje się, zanim otworzy katalog danych, a w logu widać:

$ docker compose logs db
db  | [ERROR] [MY-000067] [Server] unknown variable 'default-authentication-plugin=mysql_native_password'.
db  | [ERROR] [MY-010119] [Server] Aborting

Według listy zmian w MySQL 8.4 ustawienie usuniętej opcji jest błędem, nie ostrzeżeniem. Dobra wiadomość: serwer przerywa start, zanim dotknie danych, więc nic jeszcze nie zostało zaktualizowane. To samo dotyczy pliku my.cnf zamontowanego w /etc/mysql/conf.d/ – sprawdź go razem z linią command:.

Usunięte opcje i ich zamienniki

Stan na listopad 2026 r. Źródło: MySQL 8.4 Reference Manual, What Is New.

Zmiany, które nie blokują startu, ale zmieniają działanie

• Uwierzytelnianie. mysql_native_password jest domyślnie wyłączona w 8.4. Użytkownik aplikacji utworzony na 8.0 z tą wtyczką dostaje ERROR 1045 (28000): Access denied, a utworzenie takiego konta kończy się ERROR 1524 (HY000): Plugin 'mysql_native_password' is not loaded. Oba wyjścia opisuję niżej.
• Niestandardowe klucze obce. Klucze obce wskazujące na nieunikalny lub częściowy klucz są odrzucane w nowych CREATE TABLE, dopóki restrict_fk_on_non_standard_key ma wartość ON (domyślnie). Istniejące tabele aktualizują się bez problemu, a serwer zapisuje ostrzeżenie dla każdego takiego klucza. Migracje, które tworzą nowe, przestaną działać.
• Nowe słowa zastrzeżone. MANUAL, PARALLEL, QUALIFY i TABLESAMPLE są teraz zastrzeżone. Kolumnę manual trzeba w surowym SQL ująć w backticki; ORM-y, które zawsze cytują identyfikatory, tego nie odczują.
• Domyślne wartości InnoDB. Zmieniło się kilka ustawień domyślnych, co ma znaczenie na małym VPS-ie z wolnym dyskiem. Jeśli Twoja konfiguracja zależała od starych wartości, ustaw je jawnie.

Stan na listopad 2026 r. Źródło: MySQL 8.4 Reference Manual, What Is New.

Jak zrobić kopię zapasową kontenera MySQL przed aktualizacją?

Zrób dwie kopie: zrzut logiczny mysqldump, który wczytasz do dowolnej wersji MySQL, oraz kopię zatrzymanego wolumenu z danymi, która najszybciej przywraca dokładnie stan z 8.0. Potem sprawdź, czy zrzut naprawdę się odtwarza.

Dwie kopie wynikają z jednokierunkowości aktualizacji. Dokumentacja MySQL o obniżaniu wersji dopuszcza powrót z 8.4 do 8.0 tylko przez zrzut logiczny (albo replikację) i tylko w celu wycofania zmian. Serwer 8.0 nie otworzy po prostu katalogu danych 8.4.

Przed kopią uruchom narzędzie sprawdzające gotowość do aktualizacji (upgrade checker). Czyta działający serwer 8.0 i wypisuje usunięte opcje, problemy z uwierzytelnianiem, słowa zastrzeżone użyte jako nazwy i inne niezgodności. MySQL Shell jest w obrazie mysql:8.4, więc nic nie instalujesz; bez --target-version narzędzie sprawdza zgodność z własną wersją Shella:

# find the network of your compose project, e.g. myapp_default
docker network ls

# run the 8.4 upgrade checker (MySQL Shell ships in the mysql:8.4 image)
# against the 8.0 server that is still running
docker run --rm -it --network myapp_default mysql:8.4.13 \
  mysqlsh -- util checkForServerUpgrade root@db:3306

Przeczytaj każdy wpis Error w raporcie; ostrzeżenia o mysql_native_password są spodziewane i omawiam je dalej. Następnie zatrzymaj usługi zapisujące do bazy i zrób kopie. Zamień myapp_ na nazwę swojego projektu compose, a nazwy usług na własne:

# 1. stop everything that writes to the database (app, workers, scheduler)
docker compose stop app queue scheduler

# 2. logical dump of the application database
docker compose exec -T db sh -c 'exec mysqldump -uroot -p"$MYSQL_ROOT_PASSWORD" \
  --single-transaction --routines --triggers --events \
  --databases "$MYSQL_DATABASE"' | gzip > db-before-8.4.sql.gz

# 3. physical copy of the stopped data volume
docker compose stop db
docker volume ls | grep dbdata            # e.g. myapp_dbdata
docker run --rm -v myapp_dbdata:/var/lib/mysql:ro -v "$PWD":/backup alpine \
  tar czf /backup/dbdata-8.0.tgz -C /var/lib/mysql .

Zrzut korzysta z --single-transaction, czyli spójnej migawki tabel InnoDB bez ich blokowania, i obejmuje procedury, wyzwalacze i zdarzenia. Kopię wolumenu robisz dopiero po docker compose stop db: pliki działającego serwera MySQL skopiowane „na żywo” mogą nie wystartować. Instrukcja przygotowania do aktualizacji wymaga też czystego zamknięcia serwera – docker compose stop je zapewnia, o ile serwer zdąży się zatrzymać w limicie czasu (domyślnie 10 sekund; przy dużym buforze InnoDB zwiększ go przez stop_grace_period).

Przetestuj zrzut na jednorazowym kontenerze 8.0, żeby wiedzieć, że plik jest kompletny, zanim będzie Ci potrzebny:

docker run -d --name restore-test -e MYSQL_ROOT_PASSWORD=test mysql:8.0
docker logs -f restore-test               # wait for "ready for connections", then Ctrl+C
gunzip -c db-before-8.4.sql.gz | docker exec -i restore-test mysql -uroot -ptest
docker exec restore-test mysql -uroot -ptest -e \
  "SELECT table_schema, COUNT(*) AS tables FROM information_schema.tables GROUP BY table_schema;"
docker rm -f restore-test

Skopiuj oba pliki poza serwer albo przynajmniej na inny dysk – np. do magazynu obiektowego OVHcloud. Kopia, która leży na tym samym dysku co baza, nie chroni przed awarią tego dysku.

Co zrobić z mysql_native_password?

Albo zostaw ją na razie włączoną flagą --mysql-native-password=ON, albo przenieś wszystkie konta na caching_sha2_password przed aktualizacją lub zaraz po niej. Obie drogi działają na 8.4; tylko druga zadziała na MySQL 9, z którego wtyczkę usunięto.

Najpierw sprawdź, które konta używają której wtyczki. Uruchom to na serwerze 8.0 przed aktualizacją:

SELECT user, host, plugin
FROM mysql.user
ORDER BY plugin, user;

Jeśli wszystkie konta aplikacji mają już caching_sha2_password (domyślną dla nowych kont od MySQL 8.0), natywna wtyczka nie jest Ci potrzebna: usuń starą flagę, zostaw domyślne authentication_policy równe *,, i gotowe. Konta z mysql_native_password zwykle powstały dlatego, że plik compose wymusił tę wtyczkę przy tworzeniu bazy, często ze względu na stary sterownik PHP.

Opcja A: zostaw natywne uwierzytelnianie

Dodaj --mysql-native-password=ON do flag serwera. Jeśli nowe konta też mają używać natywnej wtyczki (np. dlatego, że instalator aplikacji sam tworzy użytkownika), zastąp usuniętą opcję flagą --authentication-policy=mysql_native_password,,. Opis zmiennej authentication_policy wyjaśnia format: do trzech czynników oddzielonych przecinkami; pierwszy element ustala wtyczkę dla pierwszego czynnika, a puste elementy zostawiają opcjonalny drugi i trzeci czynnik otwarte. Łagodniejsza wersja, *:mysql_native_password,,, ustawia natywną wtyczkę jako domyślną, ale dopuszcza też inne.

Opcja B: przenieś konta na caching_sha2_password

Uruchom 8.4 z włączoną natywną wtyczką (opcja A), żeby konta mogły się zalogować, a potem zmieniaj je po kolei. Gdy nie zostanie żadne, zrestartuj serwer bez flagi:

-- move one account to the 8.4 default plugin (keep or change the password)
ALTER USER 'app_user'@'%' IDENTIFIED WITH caching_sha2_password BY 'the-password';

-- check the result
SELECT user, host, plugin FROM mysql.user WHERE user = 'app_user';

Zanim wyłączysz wtyczkę, sprawdź, czy każdy klient potrafi się tak uwierzytelnić. Aktualne sterowniki MySQL dla PHP (mysqlnd), Pythona i Node.js obsługują caching_sha2_password. Pierwsze logowanie nowej sesji wymaga połączenia TLS albo wymiany kluczy RSA; MySQL generuje certyfikaty TLS przy pierwszym starcie, więc połączenia między kontenerami zwykle korzystają z TLS bez konfiguracji. Najczęstszą niespodzianką są narzędzia kopii: jeśli kontener z kopiami używa mysqldump z MariaDB, zrób prawdziwy zrzut zmienionym kontem, zanim usuniesz natywną wtyczkę.

Aktualizacja MySQL 8.0 do 8.4 w Docker Compose krok po kroku

Zmień obraz i flagi serwera w jednej edycji, uruchom samą bazę, poczekaj w logu na koniec aktualizacji słownika danych, a potem uruchom resztę.

1. Edytuj usługę db

   Przypnij mysql:8.4.13 (albo mysql:8.4, jeśli chcesz dostawać wersje poprawkowe przy każdym pobraniu) i zamień starą flagę. Przykład zostawia natywne uwierzytelnianie, co jest bezpiecznym wyborem dla istniejącej bazy; usuń obie flagi uwierzytelniania, jeśli wszystkie konta mają już caching_sha2_password.

   services:
     db:
       image: mysql:8.4.13
       command: >-
         --mysql-native-password=ON
         --authentication-policy=mysql_native_password,,
         --character-set-server=utf8mb4
         --collation-server=utf8mb4_unicode_ci
       volumes:
         - dbdata:/var/lib/mysql

2. Pobierz obraz i uruchom samą bazę

   Start samego db sprawia, że aplikacja nie łączy się w trakcie aktualizacji tabel systemowych.

   docker compose pull db
   docker compose up -d db
   docker compose logs -f db

3. Obserwuj aktualizację w logu

   Przy pierwszym starcie serwer rozpoznaje katalog danych 8.0, aktualizuje słownik danych i schematy systemowe, po czym przyjmuje połączenia. Spodziewaj się linii podobnych do tych (skrócone; numery wersji będą inne):

   [System] [MY-013381] [Server] Server upgrade from '80046' to '80413' started.
   [System] [MY-013381] [Server] Server upgrade from '80046' to '80413' completed.
   [System] [MY-010931] [Server] /usr/sbin/mysqld: ready for connections. Version: '8.4.13'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  MySQL Community Server - GPL.

   Serwer aktualizuje metadane i tabele systemowe, a nie wiersze Twoich tabel, więc dla typowej bazy aplikacji to krótka chwila. Nie zatrzymuj kontenera w trakcie. Jeśli zamiast tego w logu pojawi się błąd, według dokumentacji aktualizacji serwer wycofuje swoje zmiany w katalogu danych – usuń zgłoszony problem i uruchom ponownie.

4. Uruchom aplikację

   Wykonaj docker compose up -d dla całego projektu. Jeśli aplikacja czeka na bazę przez healthcheck (mysqladmin ping działa na 8.4 bez zmian), wystartuje sama, gdy db będzie zdrowe.

5. Zachowaj stary plik compose i kopie

   Nie usuwaj pliku .tgz ani zrzutu przez co najmniej kilka dni normalnej pracy. To jedyna droga powrotu.

ℹ️ Informacja: docker compose pull nigdy nie zmienia Twojego pliku compose. Jeśli nowe wydanie aplikacji przynosi nowy docker-compose.yml z mysql:8.4, i tak musisz skopiować ten plik (albo scalić usługę db) do swojej instalacji, zanim cokolwiek się zmieni.

Jak sprawdzić, czy aktualizacja się udała?

Sprawdź cztery rzeczy: serwer zgłasza 8.4, zestaw znaków i porównania (collation) się nie zmieniły, aplikacja loguje się i widzi wszystkie migracje, a polecenie kopii nadal tworzy zrzut.

# server version and character set
docker compose exec db mysql -uroot -p -e \
  "SELECT VERSION(); SHOW VARIABLES LIKE 'character_set_server'; SHOW VARIABLES LIKE 'collation_server';"

# table collations per schema (compare with the same query before the upgrade)
docker compose exec db mysql -uroot -p -e \
  "SELECT table_schema, table_collation, COUNT(*) FROM information_schema.tables
   WHERE table_schema NOT IN ('mysql','sys','information_schema','performance_schema')
   GROUP BY 1, 2;"

# the application still sees all its migrations (Laravel example)
docker compose exec app php artisan migrate:status

# a dump still works with the client your backups use
docker compose exec -T db sh -c 'exec mysqldump -uroot -p"$MYSQL_ROOT_PASSWORD" \
  --no-data --databases "$MYSQL_DATABASE"' > /dev/null && echo "dump OK"

Porównaj wynik zapytania o collation z wynikiem sprzed aktualizacji. Aktualizacja w miejscu zostawia istniejące tabele bez zmian; różnica zwykle oznacza, że migracja odtworzyła tabelę przy innych ustawieniach domyślnych serwera. Zostaw flagi --character-set-server i --collation-server, których używasz na 8.0, żeby nowe tabele pasowały do starych – dla polskich znaków ważne jest, by zostać przy utf8mb4.

Potem po prostu użyj aplikacji: zaloguj się, zapisz coś, uruchom zadanie w tle i jedną zaplanowaną kopię. Jeszcze raz przejrzyj log MySQL pod kątem ostrzeżeń o niestandardowych kluczach obcych lub przestarzałych opcjach i popraw je, póki masz w pamięci, co zostało zmienione.

Czy da się wrócić z 8.4 do 8.0?

Tylko przez odtworzenie kopii. MySQL nie wspiera obniżenia wersji z 8.4 do 8.0 w miejscu; tabela obniżania wersji dopuszcza jedynie zrzut logiczny i wczytanie albo replikację, i to tylko w celu wycofania zmian, gdy na danych nie użyto nowych funkcji 8.4.

W praktyce są dwie drogi. Jeśli aktualizacja się nie udała albo aplikacja działa źle w ciągu kilku minut, odtwórz kopię zatrzymanego wolumenu: dostajesz dokładnie stan z 8.0, ale tracisz wszystko zapisane po kopii. Jeśli 8.4 działało już jakiś czas i masz nowe dane, które chcesz zachować, zrób świeży mysqldump na 8.4 i wczytaj go do nowego, pustego kontenera 8.0 – to jest ścieżka wspierana.

docker compose stop
docker compose rm -f db
docker volume rm myapp_dbdata             # deletes the upgraded 8.4 data

# put the old docker-compose.yml back (image: mysql:8.0 and the old command:)
docker compose create db                  # recreates the empty volume
docker run --rm -v myapp_dbdata:/var/lib/mysql -v "$PWD":/backup alpine \
  tar xzf /backup/dbdata-8.0.tgz -C /var/lib/mysql
docker compose up -d

⚠️ Uwaga: docker volume rm usuwa dane na dobre. Uruchom je dopiero, gdy sprawdzisz, że dbdata-8.0.tgz istnieje, nie jest pusty i tar tzf dbdata-8.0.tgz | head wypisuje pliki.

Pamiętaj, że powrót oznacza znowu niewspieraną wersję. Traktuj go jako sposób na zyskanie czasu, dopóki nie usuniesz tego, co zablokowało aktualizację – nie jako cel.

Aktualizacja bazy w instalacji NetSendo

NetSendo przeniosło swój docker-compose.yml na MySQL 8.4 LTS w wersji 2.2.0 (6 listopada 2026 r.). Usługa db używa teraz image: mysql:8.4 z --mysql-native-password=ON --authentication-policy=mysql_native_password,,, więc użytkownik bazy utworzony przez instalację na 8.0 nadal się loguje, a mysqldump z MariaDB w obrazie aplikacji, z którego korzystają kopie NetSendo, nadal się uwierzytelnia.

Istniejąca instalacja nie zmienia się sama. Pobranie nowego obrazu aplikacji zostawia Twój plik compose bez zmian, więc baza zostaje na 8.0 i działa z nowym obrazem. Żeby zaktualizować, zrób kopię bazy, podmień docker-compose.yml na ten z wydania (obraz i command: razem) i uruchom docker compose up -d; MySQL zaktualizuje katalog danych przy pierwszym starcie. Notatki wydania opisują przetestowaną ścieżkę: migracje na 8.0, ten sam wolumen uruchomiony na 8.4, aplikacja się loguje, a mysqldump działa. Ogólne kroki instalacji znajdziesz w szybkim starcie, a ustawienia bazy w .env w dokumentacji konfiguracji.

Jeśli dopiero wybierasz platformę do samodzielnego hostowania, porównanie oprogramowania do e-mail marketingu na własnym serwerze pokazuje, jakiej bazy wymaga każde narzędzie i co oznacza jego utrzymanie.

Najczęściej zadawane pytania

Źródła

• MySQL 8.4 Reference Manual: What Is New in MySQL 8.4
• MySQL 8.4 Reference Manual: Upgrade Paths
• MySQL 8.4 Reference Manual: Downgrading MySQL
• MySQL 8.4 Reference Manual: Native Pluggable Authentication
• MySQL 8.4 Reference Manual: authentication_policy
• Oracle Cloud: MySQL Server Versions (MySQL 8.0 end of life)
• Docker Hub: official mysql image and supported tags
• NetSendo v2.2.0 release notes