Bazy danych MySQL i MariaDB: kopie zapasowe i dostępność

Co się stanie, gdy serwer bazy danych ulegnie awarii? I czy dane z wczoraj naprawdę da się odzyskać? Utrzymujemy MySQL i MariaDB z kopiami zapasowymi, których odtworzenie testujemy, z replikacją i, tam gdzie to pasuje, z klastrem Galera. Do tego dochodzą wolne zapytania i zaległe aktualizacje.

Umów rozmowę wstępną Bazy danych, z którymi pracujemy

MySQL i MariaDB od 2012 r., także w klastrze Galera
Full stack i DevOps od 2012 r.
Odpowiedź w ciągu jednego dnia roboczego

Kiedy warto przyjrzeć się bazie danych

Baza danych to często ta część systemu, której nikt nie dotyka, dopóki działa. Typowe powody, żeby to zmienić:

Nikt nie wie, czy ostatnią kopię zapasową naprawdę da się wgrać.
Baza danych działa na jednym serwerze. Gdy on ulegnie awarii, aplikacja stoi.
Strony i raporty działają coraz wolniej w miarę przyrostu danych.
Wersja jest stara, a nikt nie odważy się jej zaktualizować.
Osoby, która skonfigurowała replikację, nie ma już w firmie.

Ta strona należy do usługi Administracja Linux i infrastruktura. Jakie bazy danych znają nasi inżynierowie i jak migrujemy między nimi, opisuje strona Bazy danych.

Cylinder bazy danych połączony linią z tarczą pomiarową; wskazówka wskazuje pomarańczowy zakres skali

Kopie zapasowe, które da się odtworzyć

Kopia zapasowa ma wartość dopiero wtedy, gdy da się ją wgrać. Konfigurujemy kopie zapasowe dopasowane do Państwa bazy danych i regularnie testujemy odtworzenie:

pełne kopie wykonywane w trakcie pracy, bez zatrzymywania aplikacji
logi binarne, dzięki którym, zależnie od konfiguracji, można odtworzyć także stan tuż sprzed błędu
kopie poza serwerem bazy danych i poza strefą produkcyjną
test odtworzenia na osobnym systemie, ze zmierzonym czasem
powiadomienie, gdy kopia zapasowa się nie powiedzie

Wynik każdego testu otrzymują Państwo na piśmie. Dzięki temu wiedzą Państwo, jak stare mogą być dane po awarii i ile trwa odtworzenie.

Po lewej baza danych narysowana ciągłą linią, po prawej jej przerywana kopia; strzałka u góry prowadzi do kopii, pomarańczowa łukowa strzałka u dołu z powrotem do oryginału

Kopia zapasowa, replikacja czy klaster: co przed czym chroni?

Pytanie	Sprawdzona kopia zapasowa	Replikacja	Klaster Galera
Chroni przed	utratą danych przez błąd, usunięcie, awarię sprzętu lub atak, do stanu z ostatniej kopii	awarią serwera głównego: po przełączeniu jego rolę przejmuje replika	awarią węzła: pozostałe węzły pracują dalej
Nie chroni przed	przestojem, dopóki odtwarzanie się nie zakończy	usuniętymi danymi, bo usunięcie też jest replikowane. Przy replikacji asynchronicznej może brakować ostatnich zmian	usuniętymi danymi i błędnymi aktualizacjami, bo trafiają na wszystkie węzły
Pasuje, gdy	zawsze, jako podstawa każdego rozwiązania	krótka przerwa przy przełączeniu jest do przyjęcia albo odczyty mają być rozłożone na kilka serwerów	aplikacja musi działać dalej po awarii serwera, a dostępne są trzy serwery ze stabilną siecią

Klaster Galera: kiedy pasuje i czego nie zastępuje

Klaster Galera łączy kilka serwerów MySQL lub MariaDB. Każda zmiana jest przy zapisie przesyłana do wszystkich węzłów, a każdy węzeł może odpowiadać na zapytania. Gdy jeden serwer ulegnie awarii, pozostałe pracują dalej. Nasi inżynierowie konfigurują i utrzymują takie klastry.

Klaster stawia jednak warunki: co najmniej trzy węzły albo dwa z arbitrem, stabilną sieć oraz tabele InnoDB z kluczem głównym. Duże transakcje i wiele równoczesnych zapisów do tych samych rekordów go spowalniają. Dlatego często wystarcza replikacja z planowanym przełączeniem. Ustalamy to, zanim cokolwiek zbudujemy.

Klaster nie zastępuje też sprawdzonej kopii zapasowej. Chroni przed awarią serwera, ale nie przed usuniętymi danymi. Dlatego kopie zapasowe planujemy zawsze razem z nim.

Trzy połączone bazy danych klastra mają ten sam krzyżyk, bo usunięcie trafia wszędzie; osobna kopia zapasowa po prawej ma pomarańczowy kontur i nie ma krzyżyka

Wolne zapytania i zaległe aktualizacje

Gdy aplikacja zwalnia, szukamy przyczyny, zanim ktoś kupi większy serwer. Analizujemy najwolniejsze zapytania, czytamy ich plany wykonania, uzupełniamy brakujące indeksy i dostosowujemy konfigurację. Jeśli przyczyna leży w kodzie, na przykład w bardzo wielu małych zapytaniach na jedną stronę, usuwamy ją tam. Nasi inżynierowie znają do tego także ColdFusion, Lucee i PHP.

Nowe wersje główne MySQL i MariaDB wgrywamy najpierw na kopię i testujemy na niej aplikację. Tam, gdzie to możliwe, nowy serwer działa dzięki replikacji równolegle ze starym. Przełączamy w uzgodnionym z Państwem oknie serwisowym, a stary stan pozostaje jako droga powrotu.

Cylinder bazy danych, obok stoper i pięć poziomych pasków różnej długości jak czasy zapytań; najdłuższy pasek jest pomarańczowy

Jak postępujemy

Przegląd bazy danych

Sprawdzamy kopie zapasowe, replikację, konfigurację i najwolniejsze zapytania. Ostatnią kopię testowo wgrywamy na osobny system. Raport otrzymują Państwo na piśmie.
Plan

Z raportu powstaje rekomendacja z nakładem pracy: lepsze kopie zapasowe, replikacja albo klaster, zależnie od tego, jaką awarię zniesie Państwa aplikacja. O tym, co wdrażamy, decydują Państwo.
Wdrożenie

Rozwiązanie budujemy najpierw obok produkcji i testujemy je na kopii danych. Przełączamy w uzgodnionym oknie serwisowym, z drogą powrotu.
Utrzymanie

Na życzenie opiekujemy się potem bazą danych w ramach administracji Linux: monitoring kopii zapasowych i replikacji, regularne testy odtworzenia, aktualizacje i runbook dla Państwa zespołu.

Pierwszy krok: przegląd bazy danych z testem odtworzenia

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.

od 1 900 € netto

Zwykle 2 dni robocze

Zamów przegląd bazy danych

Z naszych projektów

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.

Pytania o kopie zapasowe, replikację i klaster

Jak sprawdzają Państwo, czy nasze dane da się odtworzyć?

Ostatnią kopię zapasową wgrywamy na osobny system, który ustalamy z Państwem, a nie na serwer produkcyjny. Mierzymy przy tym, ile trwa odtworzenie. Potem sprawdzamy, czy baza danych jest kompletna: tabele, liczbę rekordów, próbki ważnych danych i, jeśli to możliwe, uruchomienie aplikacji na tej kopii.

Wynik zapisujemy na piśmie, także wtedy, gdy czegoś brakuje. W bieżącej opiece powtarzamy test regularnie, żeby kopia zapasowa nie stała się niezauważenie bezużyteczna.

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.

Kiedy opłaca się klaster Galera?

Gdy aplikacja musi działać dalej także po awarii serwera bazy danych, a już kilka minut przerwy to za dużo. Galera wymaga do tego co najmniej trzech węzłów albo dwóch węzłów z arbitrem, stabilnej sieci z krótkimi opóźnieniami oraz tabel InnoDB z kluczem głównym.

Przy bardzo dużych transakcjach albo wielu równoczesnych zapisach do tych samych rekordów klaster dochodzi do granic. Wtedy często lepiej pasuje prostsze rozwiązanie: replikacja z planowanym przełączeniem albo szybkie, sprawdzone odtworzenie z kopii. Co pasuje do Państwa aplikacji, podaje rekomendacja z przeglądu bazy danych.

Nasza aplikacja działa coraz wolniej. Czy to wina bazy danych?

Często tak, ale nie zawsze. Najpierw przyglądamy się najwolniejszym zapytaniom, ich planom wykonania i indeksom. Do tego dochodzi konfiguracja, na przykład pamięć przeznaczona na dane i indeksy, oraz blokady między równoczesnymi operacjami.

Często przyczyna leży w aplikacji: strona wysyła bardzo wiele małych zapytań albo raport wczytuje całe tabele. Ponieważ nasi inżynierowie znają też ColdFusion, Lucee i PHP, usuwamy problem tam, gdzie powstaje. Większy serwer często nie jest wtedy potrzebny.

Czy czasem pełnią Państwo dyżury w weekendy?

Tak. Wsparcie i awarie obsługujemy całą dobę (24/7), także w weekendy. Prace planowane na weekend, na przykład przełączenie w oknie serwisowym, wykonujemy po uzgodnieniu. W pozostałych sprawach jesteśmy dostępni od poniedziałku do piątku od 9:00 do 17:00 czasu środkowoeuropejskiego, a na zapytania odpowiadamy w ciągu jednego dnia roboczego.

W 20 minut ustalimy, jaki pierwszy krok pasuje do Państwa systemu

Państwo opisują cel i obecny stan, my mówimy otwarcie, czy i jak możemy pomóc. Odpowiedź w ciągu jednego dnia roboczego, bez zobowiązań.

Umów rozmowę wstępną Jak pracujemy

Telefon (niemiecki, polski, angielski) +48 501 250 220

E-mail E-mail

Dostępni: poniedziałek–piątek, 9:00–17:00 (czas środkowoeuropejski); wsparcie i awarie całą dobę (24/7)