Przejdź do treści 
Transakcja bazy danych Dzienniki najpierw zapisują każdą zmianę w dzienniku i kontrolują bezpieczny zapis na stronach danych, co oznacza, że właściwości takie jak trwałość sql pozostają nienaruszone nawet w przypadku awarii. Wyjaśniam, w jaki sposób te dzienniki umożliwiają odzyskiwanie po awarii z analizą, ponawianiem i cofaniem, w jaki sposób WAL kontroluje I / O i jak odzyskiwanie punkt w czasie działa niezawodnie w praktyce.
Punkty centralne
- KWAS bezpieczeństwo: transakcje pozostają atomowe, spójne, odizolowane i trwałe.
- WAL po pierwsze: zapisz dziennik przed stroną danych, aby zapewnić bezpieczne potwierdzenia.
- Redo/UndoPo awarii należy wprowadzić potwierdzone zmiany i anulować niekompletne.
- punkty kontrolneSkrócenie czasu odzyskiwania i kontrola wzrostu kłód.
- Kopie zapasowePełne, różnicowe, łączone kopie zapasowe dziennika do odzyskiwania w czasie.
Krótkie wyjaśnienie transakcji i ACID
A Transakcja łączy kilka operacji bazodanowych w jedną logiczną jednostkę, którą potwierdzam lub całkowicie odrzucam. Cztery właściwości ACID zapewniają szyny ochronne: atomowość zapobiega stanom w połowie ukończonym, spójność zachowuje reguły i ograniczenia, izolacja oddziela jednoczesne procesy, a trwałość chroni potwierdzone dane. Upewniam się, że COMMIT ma miejsce tylko wtedy, gdy odpowiednie wpisy w dzienniku zostały trwale zapisane, ponieważ to jest dokładnie to, czego wymaga ACID. Trwałość gwarantowane. I odwrotnie, ROLLBACK cofa wszystkie kroki transakcji i przywraca spójny stan. Oznacza to, że baza danych pozostaje niezawodnie użyteczna nawet w przypadku błędów, awarii zasilania lub restartów.
Rejestrowanie z wyprzedzeniem zapisu (WAL) zrozumiałe
Na stronie WAL-Zasadniczo najpierw zapisuję zmiany sekwencyjnie w dzienniku transakcji i spłukuję dziennik do nośnika danych w celu COMMIT, zanim pojawią się strony danych. Ta procedura redukuje losowe dostępy do zapisu, zwiększa wydajność I/O i pozwala na bezpieczne potwierdzenia bez natychmiastowego utrwalania każdej strony danych. W pamięci RAM zmieniam strony w buforze, tworzę rekordy dziennika z wartościami przed/po i łączę je z identyfikatorami transakcji. COMMIT oznacza: wpisy dziennika są trwałe, baza danych może później zapisywać strony danych asynchronicznie. Dokładnie w ten sposób mogę rozpoznać po awarii przy użyciu funkcji Dziennik-historia, aby zrozumieć, co naprawdę zostało potwierdzone.
Struktura dziennika: segmenty, obcinanie i punkty kontrolne
Dziennik transakcji często składa się z kilku Segmenty, którego baza danych używa w sposób ciągły, dzięki czemu procesy zapisu pozostają obliczalne. Gdy segment jest pełny, przełączam się na następny i zwalniam stare, już zarchiwizowane obszary poprzez obcięcie. Punkt kontrolny oznacza stan, z którego muszę odczytać tylko nowsze wpisy dziennika w celu odzyskania danych; znacznie skraca to czas uruchamiania po awarii. Aby uzyskać bardziej szczegółowe informacje, zobacz mój przegląd Uwagi dotyczące punktów kontrolnych i jasną kategoryzację dźwigni związanych ze wzmocnieniem zapisu. Jeśli dokładnie zaplanujesz interwał punktów kontrolnych, automatyczny wzrost i maksymalny rozmiar dziennika, unikniesz wąskich gardeł i utrzymasz Przywrócenie możliwe do zaplanowania.
Odzyskiwanie po awarii w trzech fazach
Po awarii baza danych była odczytywana od ostatniego Punkt kontrolny i rozpoczyna się od analizy: które transakcje były aktywne, które strony danych są dotknięte, które zatwierdzenia są dostępne. Podczas fazy redo system aktualizuje potwierdzone zmiany, jeśli nie są one jeszcze w pełni zintegrowane ze stronami danych. Faza cofania resetuje następnie niekompletne transakcje, dzięki czemu żadne niedokończone zmiany nie są widoczne. Proces ten przebiega automatycznie, a postępy i potencjalne opóźnienia są widoczne w dzienniku i komunikatach o stanie. Czynnik decydujący pozostaje: Bez niezawodnego Dziennik-Żaden system nie mógł rozpoznać, co jest ważne, a co nie.
MySQL/InnoDB: odzyskiwanie po awarii mysql w praktyce
Dzięki InnoDB, MySQL zarządza Redo-log dla potwierdzonych zmian i undo log dla anulowania otwartych transakcji. Podczas ponownego uruchamiania po awarii zasilania, InnoDB używa tych plików do rozpoznania, które transakcje zostały zakończone poprawnie. MySQL następnie wykonuje operacje redo dla potwierdzonych wpisów i cofa niekompletne transakcje za pomocą Undo. Sprawdzam komunikaty serwera podczas nieplanowanych restartów, aby zobaczyć czas trwania i postęp odzyskiwania oraz rozpoznać wąskie gardła, takie jak pełne woluminy. Jeśli odpowiednio ustawisz pliki dziennika, rozmiary buforów i strategie płukania, skrócisz czas odzyskiwania. Odzyskiwanie-czasami wyraźnie.
Wydajność kontra trwałość: praktyczny kompromis
Każdy Trwałość-gwarancja kosztuje opóźnienie, ponieważ COMMIT wymaga trwałego zapisu dziennika. Zmniejszam to opóźnienie za pomocą szybszej pamięci masowej, takiej jak SSD lub NVMe, zgrupowanych płukań i rozsądnych wzorców wsadowych. W konfiguracjach rozproszonych replikacja asynchroniczna może odciążyć lokalne ścieżki zapisu, ale przynosi niewielkie okno potencjalnej utraty danych w przypadku całkowitej awarii. Ustawienia takie jak bardziej rygorystyczne zasady spłukiwania zwiększają bezpieczeństwo, ale wydłużają czas odpowiedzi; luźniejsze tryby zmniejszają opóźnienia, ale ryzykują dane w przypadku awarii wkrótce po COMMIT. Poniższa tabela zawiera kompaktowy przegląd popularnych technik i ich efektów.
| Technologia | Cel | Wpływ na opóźnienia | Wskazówka |
|---|---|---|---|
| WAL-Flush do COMMIT | Chroni potwierdzone transakcje | Wyższe przy powolnym magazynowaniu | Szybki nośnik danych logowania się opłaca |
| Zgrupowane Spłuczki | Mniej wywołań we/wy | Niższe ze względu na sprzedaż wiązaną | Precyzyjne dostrajanie za pomocą limitu czasu/rozmiaru partii |
| NVMe-Pamięć | Zmniejsza szczytowe opóźnienia | Znacznie niższy | Preferowanie oddzielnych woluminów dziennika |
| Asynchroniczny Replikacja | Łagodzi lokalne zobowiązania | Lokalnie niższe | Zwróć uwagę na małe okno RPO |
Mierzę te efekty pod obciążeniem produkcyjnym, ustawiam docelowe wartości opóźnień i przepustowości i porównuję je z wymaganiami dotyczącymi utraty danych. Następnie dostosowuję interwały spłukiwania, bufory dziennika i nośniki pamięci masowej, aby zoptymalizować wydajność i przepustowość. Bezpieczeństwo pasują do siebie.
Strategia tworzenia kopii zapasowych i odzyskiwania danych w czasie rzeczywistym
Dziennik transakcji rozwija swój pełny potencjał dzięki jasnemu Kopia zapasowa-Łańcuch pełnych kopii zapasowych, różnicowych lub przyrostowych kopii zapasowych i kopii zapasowych dziennika. W sytuacji awaryjnej przywracam ostatnią pełną kopię zapasową, następnie przywracam różnicowe lub przyrostowe kopie zapasowe i stosuję kopie zapasowe dziennika do żądanego punktu w czasie. Pozwala mi to na wycofanie nieprawidłowych zmian masowych lub usunięcie danych bez GDZIEKOLWIEK. Więcej informacji na temat procedur i narzędzi podsumowałem w moim porównaniu Kopia zapasowa a migawka razem. Regularne testowanie przywracania pozwala zaoszczędzić czas i zabezpieczyć się na wypadek najgorszego. Dane od trwałej utraty.
Monitorowanie i typowe problemy z dziennikami
Pełny Dziennik-Woluminy zatrzymują operacje zapisu, więc stale monitoruję ich rozmiar, wzrost i wykorzystanie we/wy. Niewłaściwy model odzyskiwania może spowodować rozrost dzienników lub uniemożliwić odzyskiwanie w czasie, więc sprawdzam tryb, aby dopasować go do scenariusza wdrożenia. Świadomie planuję częstotliwość punktów kontrolnych, kroki automatycznego wzrostu i czasy obcinania, aby utrzymać krótkie czasy uruchamiania po awariach. Rejestruję również kody błędów bazy danych, które wskazują na blokowanie transakcji, długie czasy spłukiwania lub wąskie gardła pamięci masowej. Konsekwentnie stosowane monitorowanie zmniejsza ryzyko i utrzymuje Dostępność wysoki.
Testy odzyskiwania, RTO i RPO
Kopie zapasowe bez Test pozostają bezwartościowe, dlatego regularnie importuję kopie zapasowe na oddzielnych systemach i sprawdzam kroki. Dla każdej aplikacji definiuję cel czasu odzyskiwania, tj. maksymalny tolerowany czas przestoju, oraz cel punktu odzyskiwania, tj. maksymalną akceptowalną utratę danych. Cele te kontrolują mój zestaw interwałów tworzenia kopii zapasowych, częstotliwość tworzenia kopii zapasowych dziennika i strategię replikacji. Czysty plan awaryjny określa osoby odpowiedzialne, narzędzia, hasła, lokalizacje przechowywania i dokładne sekwencje poleceń. Tylko dzięki udokumentowanej praktyce można szybko Przywrócenie bez przykrych niespodzianek.
Wirtualizacja, chmura i replikacja
W maszynach wirtualnych lub w chmurze łączę Migawki z kopiami zapasowymi dziennika w celu utworzenia elastycznych punktów przywracania. Konfiguracje wielowęzłowe często wykorzystują dziennik transakcji jako strumień dla replik, które podążają w czasie zbliżonym do rzeczywistego. Przyglądam się modelom spójności, aby uniknąć scenariuszy podziału mózgu i jasno regulować przełączanie awaryjne. Aby uzyskać kategoryzację wspólnych strategii, zapoznaj się z moim przeglądem Replikacja i przełączanie awaryjne. Jeśli chcesz poznać trasy transportowe dla danych dziennika i Opóźnienie między strefami podejmuje uzasadnione decyzje dotyczące wysokiej dostępności.
Szczegóły dziennika wewnętrznego: LSN, PageLSN i pełne obrazy stron
Po każdym mechanizmie redo/undo następują kolejne numery sekwencji dziennika (LSN). Każdą zmianę łączę z numerem LSN, a także zapisuję PageLSN na stronach danych, których ona dotyczy. Podczas odzyskiwania sprawdzam: jeśli PageLSN jest mniejszy niż LSN wpisu w dzienniku, muszę zastosować redo, w przeciwnym razie strona jest już aktualna. Do rozpoznawania procesów rozerwanego zapisu używam sum kontrolnych i - w zależności od silnika - Obrazy na całą stronę lub bufor podwójnego zapisu. Procedura ta chroni przed rozdartymi zapisami i sprawia, że operacje ponownego zapisu są idempotentne: ponowne zastosowanie tej samej zmiany nie wyrządza szkody, ponieważ logika LSN zapobiega wielokrotnemu wykonywaniu.
Rejestrowanie fizyczne a logiczne - i dlaczego oba są potrzebne
Rozróżniam logowanie fizyczne (delty specyficzne dla strony lub całych stron) i logowanie logiczne (operacje specyficzne dla linii lub instrukcji). Fizyczne logi są kompaktowe i szybkie do podsumowania, logi logiczne są przenośne i nadają się do replikacji lub audytów. W systemach z wielowarstwowymi logami (takimi jak redo silnika pamięci masowej plus oddzielny dziennik replikacji) zwracam uwagę na spójność: potwierdzony COMMIT musi być czysty zarówno w strumieniu redo, jak i replikacji. Pozwala mi to na niezawodne odzyskiwanie danych lokalnie i jednocześnie obsługę identyfikowalnych, deterministycznych replik.
Izolacja, MVCC i Cofnij w życiu codziennym
Logi ściśle współpracują z wybraną izolacją. Dzięki MVCC pozwalam czytelnikom patrzeć na spójne migawki, podczas gdy pisarze tworzą nowe wersje. Dziennik cofnięć przechowuje starsze stany, dopóki żadna transakcja nie może ich zobaczyć. Dlatego celowo planuję procesy oczyszczania/odkurzania: długo działające transakcje odczytu blokują zwalnianie starych wersji i rozdęcie dzienników. W praktyce ustawiam limity czasu wykonywania transakcji, sprawdzam regularne kopie zapasowe migawek pod kątem ich wpływu na retencję starych wersji i utrzymuję obciążenia odczytu wymagające historii z dala od systemów podstawowych tak daleko, jak to możliwe.
Ścieżki zatwierdzania, zatwierdzanie grupowe i wpływ sprzętu
Czas trwania COMMIT jest określony przez ścieżkę do stabilnego przechowywania. Używam Group Commit, aby potwierdzić kilka transakcji ze wspólnym spłukiwaniem i sprawdzić, czy mój system jest stabilny. fsync/fdatasync i bariery zapisu nie są dezaktywowane. Kontroler z podtrzymywaną bateryjnie pamięcią podręczną zapisu lub dyski SSD z ochroną przed utratą zasilania zmniejszają ryzyko i opóźnienia. W środowiskach podobnych do MySQL świadomie kalibruję parametry płukania: tryby ścisłe zapewniają trwałość, luźniejsze przenoszą obciążenia na rzadkie przypadki awarii. Decydującym czynnikiem jest udokumentowana ocena ryzyka - i możliwość poparcia jej zmierzonymi wartościami.
Przechowywanie dzienników, szyfrowanie i zgodność z przepisami
Dzienniki transakcji mogą zawierać poufne treści. Szyfruję je w spoczynku, obracam klucze zgodnie ze specyfikacjami i zapewniam, że kopie zapasowe dzienników są również chronione. Okres przechowywania wywodzę z RPO, wymogów prawnych i budżetów na przechowywanie. Na potrzeby audytów rejestruję procesy dostępu, rotacji i usuwania w identyfikowalny sposób. Tam, gdzie dane osobowe mogą znaleźć się w dziennikach, sprawdzam maskowanie na wyższym poziomie lub polegam na dziennikach logicznych, które nie zawierają żadnych surowych danych. W ten sposób łączę odzyskiwalność z ochroną danych i zgodnością z przepisami.
Odzyskiwanie danych w czasie rzeczywistym krok po kroku
W praktyce postępuję w następujący sposób w celu przywrócenia punktu w czasie: Zatrzymuję pisanie klientów lub izoluję system docelowy, wybieram pełną kopię zapasową jako podstawę i przywracam ją na osobnej instancji. Następnie stosuję różnicowe / przyrostowe kopie zapasowe i zwijam kopie zapasowe dziennika tuż przed zdarzeniem. Definiuję punkt docelowy jako znacznik czasu lub jako LSN/SCN i sprawdzam, czy wszystkie segmenty dziennika są dostępne bez luk. Po imporcie sprawdzam spójność i efekty uboczne (np. sumy wyzwalaczy, indeksy drugorzędne) i dopiero wtedy przecinam system. Z wyprzedzeniem dokumentuję źródła czasu, strefy czasowe i odchylenia zegara, aby można było jasno określić czas docelowy.
Typowe wzorce błędów i szybkie środki zaradcze
Typowe błędy mogę rozpoznać po wzorcu: Jeśli brakuje segmentu dziennika, import jest przerywany - pomoże tu tylko wcześniejsze przywrócenie lub istniejący stan repliki. Komunikaty takie jak „Log-LSN is in the future“ wskazują na niezgodność między plikami danych a historią dziennika, często spowodowaną nieprawidłową sekwencją kopiowania. Uszkodzenie redo zmusza mnie do rozpoczęcia od konserwatywnych trybów odzyskiwania, tylko do odczytu i natychmiastowego tworzenia nowych, czystych kopii zapasowych. Jeśli punkt kontrolny nigdy nie działa „z tyłu“, skaluję rozmiar dziennika, zmniejszam udział brudnych stron lub rozkładam I / O, aby redo nie stało się ciągłym palnikiem. Jeśli partycja dziennika jest pełna: utwórz miejsce, ponownie aktywuj archiwizację, a następnie ostrożnie zrestartuj usługi.
Planowanie wydajności i benchmarki
Wymiaruję dzienniki zgodnie z rzeczywistym tempem zmian. Aby to zrobić, mierzę MB/s na ścieżce zapisu dziennika przy użyciu profili dziennych i tygodniowych, biorę pod uwagę szczyty (wsad, ETL, zamknięcie miesiąca) i zachowuję co najmniej wielokrotność tego szczytu jako bufor. Bufor dziennika w pamięci RAM nie może stać się wąskim gardłem, w przeciwnym razie opóźnienia wzrosną z powodu częstego płukania. W przypadku punktów kontrolnych jasno definiuję maksymalny czas odzyskiwania po awarii i na tej podstawie określam docelowe wartości dla brudnych stron i okien dziennika. Używam benchmarków w sposób ukierunkowany: narzędzia syntetyczne pokazują trendy, ale walidacja odbywa się przy realistycznym obciążeniu, z uwzględnieniem replikacji, szyfrowania i mechanizmów ochrony pamięci. Tylko wtedy RTO/RPO odpowiadają zmierzonym opóźnieniom zatwierdzania.
Krótkie podsumowanie
Dzienniki transakcji zapewniają ubezpieczenie przed utratą danych: dokumentują zmiany, zapisują zatwierdzenia i przywracają systemy do spójnych stanów po awariach. WAL sprawia, że proces jest wystarczająco szybki do codziennego użytku i szczytowych obciążeń, podczas gdy punkty kontrolne i obcinanie utrzymują czas uruchamiania i rozmiar dziennika pod kontrolą. Dzięki pełnym, różnicowym i dziennikowym kopiom zapasowym osiągam odzyskiwanie w punkcie w czasie i mogę wycofywać błędy z najwyższą dokładnością. Jeśli połączysz monitorowanie, testy odzyskiwania, jasne RTO/RPO i dostosowaną technologię pamięci masowej, możesz osiągnąć niezawodność bez niepotrzebnych opóźnień. W ostatecznym rozrachunku liczy się to, że rozumiem, utrzymuję i regularnie ćwiczę tworzenie kopii zapasowych logów. Baza danych nawet w sytuacjach awaryjnych.
