Państwa system działa, ale nikt nie zna go dokładnie. Spisujemy aplikację, bazę danych, serwer i pocztę, oceniamy ryzyka, na piśmie rekomendujemy dalszą drogę, a na życzenie przejmujemy utrzymanie systemu.
MySQL, MariaDB i Galera: utrzymanie i migracja baz danych
Nasi inżynierowie utrzymują bazy MySQL i MariaDB, także w klastrze Galera, i przenoszą dane między bazami, na przykład z Firebird na MariaDB. Obsługują również bazy PostgreSQL, Microsoft SQL Server i Oracle.
- MySQL i MariaDB od 2012 r., także w klastrze Galera
- Migracje między bazami danych, na przykład z Firebird na MariaDB
- Odpowiedź w ciągu jednego dnia roboczego
Gdzie stosujemy bazy danych
Za każdą aplikacją webową stoi baza danych i często to ta część, której nikt nie dotyka. Najczęściej jest to MySQL lub MariaDB, od lat na tym samym serwerze i z konfiguracją, której nikt nie spisał. Z oboma systemami nasi inżynierowie pracują od 2012 r.: instalacja, kopie zapasowe, replikacja, klastry Galera, wydajność i aktualizacje.
Z PostgreSQL, Microsoft SQL Server i Oracle nasi inżynierowie pracują w aplikacjach, których dane się tam znajdują, i przy integracjach z takimi systemami. Firebird znają przede wszystkim z migracji.
Jak zabezpieczamy MySQL i MariaDB w bieżącym utrzymaniu i dbamy o ich dostępność, opisuje strona Bazy danych MySQL i MariaDB.
Typowe zadania z MySQL i MariaDB
- Inwentaryzacja: wersja, konfiguracja, kopie zapasowe, użytkownicy i uprawnienia, rozmiar i przyrost danych
- Kopie zapasowe z logami binarnymi i regularnym testem odtworzenia
- Konfiguracja i monitorowanie replikacji i klastrów Galera, a po awarii ponowne łączenie węzłów
- Wyszukiwanie wolnych zapytań, uzupełnianie indeksów i dostrajanie konfiguracji, w razie potrzeby także w kodzie aplikacji
- Aktualizacje i nowe wersje główne, najpierw testowane na kopii
- Zmiana z MySQL na MariaDB lub odwrotnie oraz migracje z innych baz danych
- Porządkowanie zestawów znaków, gdy po przeniesieniu polskie znaki wyświetlają się błędnie
- Przeniesienie bazy danych na nowy serwer lub do kontenera, z trwałym magazynem danych i drogą powrotu
MariaDB i MySQL: podobne, ale nie takie same
MariaDB powstała jako odgałęzienie MySQL i wiele aplikacji działa z obiema. Z każdą wersją główną obie bazy coraz bardziej się jednak od siebie różnią. W utrzymaniu liczą się przede wszystkim trzy różnice.
Wysoka dostępność. W MariaDB Galera jest już wbudowana. Dla MySQL Galera istnieje jako osobny wariant serwera, a obok niego jest replikacja grupowa samego MySQL. Która droga pasuje, zależy od tego, co już u Państwa działa.
Replikacja między obiema bazami. Oba systemy różnie oznaczają transakcje w replikacji. Mieszana konfiguracja z MySQL i MariaDB jest więc możliwa tylko w ograniczonym zakresie i nadaje się raczej do przeprowadzki niż do stałej pracy.
Funkcje i optymalizator. Typ danych JSON, pojedyncze funkcje i optymalizator zachowują się różnie. To samo zapytanie może być szybkie w jednym systemie i wolne w drugim. Dlatego przed zmianą testujemy aplikację na kopii.
Migracje między bazami danych
Aplikacja rzadko zmienia bazę danych bez powodu. Częste powody to system, którego nikt w zespole już nie zna, albo stare sterowniki, które nie działają z nowymi wersjami aplikacji. Czasem wszystkie aplikacje mają działać na jednej bazie danych. Typowy przykład to przejście z Firebird na MariaDB.
Zmienia się przy tym więcej niż tylko miejsce przechowywania danych. Typy danych, zestawy znaków, procedury składowane, wyzwalacze i dialekt SQL się różnią, a zapytania w kodzie trzeba do tego dostosować. Dlatego najpierw migrujemy na kopię, porównujemy dane z oryginałem i przełączamy dopiero po testach.
Jeśli baza danych działa stabilnie i jest utrzymywana, nie doradzamy zmiany tylko dlatego, że inny system wygląda nowocześniej.
Technologie i zakres
| Obszar | Zakres |
|---|---|
| MySQL i MariaDB | Instalacja, kopie zapasowe z testem odtworzenia, replikacja, wydajność i aktualizacje |
| Wysoka dostępność | Klastry Galera z MySQL i MariaDB, replikacja z planowanym przełączeniem |
| Firebird | Migracje, na przykład na MariaDB |
| PostgreSQL, Microsoft SQL Server i Oracle | Aplikacje, których dane znajdują się w tych bazach, i integracje z nimi |
| Środowisko pod spodem | Linux z Debianem i Ubuntu, Docker, KVM i Proxmox |
Typowe sytuacje wyjściowe z bazami danych
-
-
Dla PHP 8.2 poprawki bezpieczeństwa kończą się 31.12.2026, dla PHP 8.1 i starszych już się skończyły (stan: 2026-10). Przenosimy rozbudowywane od lat aplikacje PHP, także z szablonami Smarty i frontendem w jQuery, na PHP 8.4 lub 8.5. Testujemy każdy etap.
-
Państwa dane są dziś przenoszone ręcznie między dwoma systemami albo partner wymaga interfejsu API? Łączymy istniejące aplikacje przez REST lub SOAP, synchronizujemy dane między nimi i wysyłamy wiadomości transakcyjne oraz powiadomienia z Państwa procesów.
-
Zespół nie nadąża, brakuje konkretnej wiedzy albo przed ważną decyzją potrzebna jest druga opinia? Przejmujemy wydzieloną część: moduł, backend do Państwa frontendu, interfejs, migrację albo przegląd kodu. Pracujemy w Państwa repozytorium i systemie zgłoszeń, a kod i wiedza zostają u Państwa.
Pierwszy krok: przegląd bazy danych z raportem na piśmie
Przegląd bazy danych: MySQL i MariaDB
Dla firm, których aplikacja zależy od bazy danych MySQL lub MariaDB i które chcą wiedzieć, co się stanie przy awarii i czy dane z wczoraj naprawdę da się odtworzyć.
- Kopie zapasowe: co jest zabezpieczane, jak często i gdzie leżą kopie
- Test odtworzenia na osobnym systemie, ze zmierzonym czasem
- Replikacja i odporność na awarie: co jest, a czego brakuje
- Najwolniejsze zapytania i brakujące indeksy
- Wersja, stan wsparcia i konfiguracja
- Rekomendacja: kopie zapasowe, replikacja lub klaster, zależnie od potrzeb
Klaster, taki jak MariaDB Galera, chroni przed awarią serwera, ale nie przed usuniętymi danymi. Do tego potrzebne są sprawdzone kopie zapasowe. Dlatego zaczynamy od testu odtworzenia. Na jakim systemie się odbędzie, ustalamy z Państwem. W produkcyjnej bazie danych niczego nie zmieniamy.
Co zawiera wynik
Pisemny raport z wynikiem testu odtworzenia, ryzykami według priorytetu i rekomendacją z nakładem pracy. Raport należy do Państwa. Na życzenie wdrażamy potem wybrane rozwiązanie, także klaster Galera.
Projekty z MariaDB
-
Indeksy SQL w bazie sklepu: od pełnych skanów do mikrosekund
Baza sklepu bez indeksów działała, dopóki tabele były małe. Przy 500 tysiącach zamówień i 1,75 miliona pozycji każdy filtr i każdy JOIN schodził do pełnego skanu. Zmierzyliśmy dokładnie, ile kosztują brakujące indeksy, dodaliśmy właściwe i opisaliśmy pułapki, przez które indeks bywa bezużyteczny, choć istnieje.
-
ColdFusion pod obciążeniem: diagnoza i naprawa błędu JVM heap space
Aplikacja Adobe ColdFusion działała bez zarzutu przy niskim ruchu, a w godzinach szczytu zwracała błędy i zwalniała. Zreprodukowaliśmy problem na realnej bazie, zmierzyliśmy dokładny punkt, w którym sterta JVM się wyczerpuje, i naprawiliśmy konfigurację pamięci, z tym samym testem obciążeniowym przed i po jako dowodem.
Pytania o MySQL, MariaDB i inne bazy danych
MySQL czy MariaDB: na czym polega różnica?
MariaDB powstała jako odgałęzienie MySQL. W wielu aplikacjach obie bazy można stosować zamiennie: w rdzeniu ten sam SQL, podobne narzędzia i podobna konfiguracja. Z każdą wersją główną coraz bardziej się jednak od siebie różnią, na przykład w replikacji, typie danych JSON, pojedynczych funkcjach i działaniu optymalizatora.
Zmiana nie jest więc zwykłą wymianą oprogramowania. Najpierw sprawdzamy, z jakich funkcji korzysta Państwa aplikacja, przenosimy dane na kopię i testujemy na niej aplikację. Dopiero potem przełączamy, w uzgodnionym z Państwem oknie serwisowym i z drogą powrotu.
Jak przebiega zmiana bazy danych, na przykład z Firebird na MariaDB?
Zaczynamy od inwentarza: tabele, typy danych, zestawy znaków, procedury składowane, wyzwalacze i zapytania w aplikacji. Firebird i MariaDB używają różnych dialektów SQL. Dlatego przenosimy schemat i logikę na nowy dialekt i dostosowujemy zapytania w kodzie.
Następnie migrujemy dane na kopię i porównujemy je z oryginałem tabela po tabeli. Aplikację testujemy na nowej bazie danych, zanim przełączymy ją w uzgodnionym oknie serwisowym. Dopóki nowa baza nie działa stabilnie, stara pozostaje jako droga powrotu.
Czy pracują Państwo także z PostgreSQL, Microsoft SQL Server lub Oracle?
Tak: w aplikacjach, których dane znajdują się w tych bazach, oraz przy integracjach z takimi systemami. Firebird nasi inżynierowie znają przede wszystkim z migracji, na przykład na MariaDB.
Przy MySQL i MariaDB, także w klastrze Galera, przejmujemy również utrzymanie, kopie zapasowe i wysoką dostępność. Przy pozostałych bazach danych już w rozmowie wstępnej mówimy otwarcie, co przejmiemy sami, a gdzie lepiej sprawdzi się Państwa zespół lub wyspecjalizowany dostawca.
Jak podnoszą Państwo MySQL lub MariaDB do nowej wersji głównej?
Najpierw na kopii. Sprawdzamy, jakie ustawienia, tryby SQL i funkcje zmieniają się w nowej wersji i z czego korzysta Państwa aplikacja. Potem wgrywamy aktualną kopię zapasową na osobny system, podnosimy ją do nowej wersji i testujemy na niej aplikację.
Tam, gdzie pozwala na to środowisko, stawiamy nowy serwer obok starego i utrzymujemy go w synchronizacji przez replikację. Przełączenie jest wtedy krótkie i odbywa się w uzgodnionym oknie serwisowym. Stary serwer ze stanem sprzed przełączenia pozostaje jako droga powrotu.
Czy klaster Galera zastępuje kopie zapasowe?
Nie. Klaster chroni przed awarią serwera, ale nie przed usuniętymi danymi. Każda zmiana trafia na wszystkie węzły, także przypadkowe usunięcie danych lub błędna aktualizacja. Wtedy danych brakuje na wszystkich serwerach jednocześnie.
Do tego potrzebne są sprawdzone kopie zapasowe poza klastrem. Dzięki logom binarnym można, zależnie od konfiguracji, odtworzyć także stan z chwili tuż przed błędem. Czy to się uda, pokazuje dopiero test odtworzenia. Dlatego od niego zaczyna się nasz przegląd bazy danych.
Nie są Państwo pewni, jaka usługa pasuje do systemu?
Prosimy opisać system w dwóch zdaniach. Odpowiemy, jaka usługa pasuje i czy produkt wejściowy ze stałą ceną będzie właściwym pierwszym krokiem.