Czy można uruchomić bazę danych z zamontowanego przez sieć woluminu Docker?

Eva Wong

IceWhale author

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

Can You Run a Database From a Network-Mounted Docker Volume? - Zima Store Online

Czasami, ale tylko wtedy, gdy baza danych wyraźnie obsługuje semantykę i opóźnienia sieciowego systemu plików; lokalna trwała pamięć masowa jest bezpiecznym rozwiązaniem domyślnym.

Decyzja ma znaczenie, gdy skonteneryzowane obciążenie PostgreSQL, MariaDB lub SQLite korzysta z NFS albo SMB w celu łatwiejszego centralnego przechowywania danych. Dwa konkurencyjne scenariusze to obsługiwane blokowanie, fsync i semantyka awarii oraz zachowanie związane z opóźnieniami, pamięcią podręczną, blokadami lub ponownym połączeniem, które narusza oczekiwania bazy danych. Zacznij od zapisanej konfiguracji i danych przeznaczonych do usunięcia, obserwuj jedną gałąź naraz i przerwij, jeśli test zwiększa ryzyko utraty danych, problemów z uprawnieniami lub dostępnością.

Zdefiniuj warunki decyzji dotyczącej plików bazy danych w pamięci sieciowej

Zapisz środowisko przed wprowadzeniem zmian: wersje oprogramowania i oprogramowania układowego, tożsamości urządzeń, punkt montowania lub ścieżkę sieciową, wolne miejsce, uprawnienia oraz obserwowany objaw. Punkt odniesienia musi zawierać wystarczająco dużo szczegółów, aby odtworzyć skonteneryzowane obciążenie PostgreSQL, MariaDB lub SQLite korzystające z NFS albo SMB w celu łatwiejszego centralnego przechowywania danych.

Pierwszym kandydatem jest obsługiwane blokowanie, fsync i semantyka awarii. Drugim są opóźnienia oraz zachowanie pamięci podręcznej, blokad lub ponownego połączenia, które narusza oczekiwania bazy danych. Bieżąca strona PostgreSQL w NFS definiuje mechanizm lub granicę polecenia używaną w teście; nie zastępuje jednak obserwacji z tego konkretnego serwera domowego.

Zapisz warunek akceptacji i warunek przerwania przed uruchomieniem testu rozróżniającego. Wynik pozytywny musi zmienić dowody przewidywane przez jedną gałąź, pozostawiając niepowiązane usługi bez zmian; wynik negatywny musi przywrócić system do zapisanego stanu, zamiast uruchamiać ciąg spekulatywnych poprawek.

Przetestuj twierdzenie bez obniżania pierwotnego wymagania

Użyj następującego testu rozróżniającego: przywróć przeznaczoną do usunięcia bazę danych na dokładnie tym samym punkcie montowania, uruchom testy spójności i odzyskiwania po awarii oraz zasymuluj krótką przerwę w sieci. Zachowaj stałe obciążenie, klienta, ścieżkę, zestaw plików i czas, aby wynik można było przypisać zmienionej wartości.

Skorzystaj z informacji o zagrożeniach związanych z sieciowymi systemami plików dla baz danych, aby wybrać parametr, który rzeczywiście rozdzieli te gałęzie, a następnie zarejestruj jego znacznik czasu, status wyjścia, treść błędu, tożsamość urządzenia lub migawki, opóźnienie, liczbę przesłanych bajtów, uprawnienia i stan odzyskiwania. Pomyślne zakończenie polecenia nie wystarczy, gdy testowane twierdzenie dotyczy tożsamości, trwałości lub stanu aplikacji.

Powtórz test raz po ponownym uruchomieniu, ponownym połączeniu, ponownym zamontowaniu lub wyczyszczeniu pamięci podręcznej, jeśli takie zdarzenie jest częścią pierwotnego warunku. Jeśli pierwszy przebieg jest destrukcyjny lub środowiska nie można przywrócić, przerwij i odtwórz test na przeznaczonej do usunięcia kopii.

Test: ciągłe transakcje -> przerwanie sieci -> ponowne zamontowanie -> odzyskiwanie bazy danych -> kontrole

Interpretuj wyniki pozytywne, negatywne i wyjątkowe

WYNIK POZYTYWNY: transakcje pozostają trwałe, a odzyskiwanie kończy się powodzeniem bez uszkodzeń przy docelowym opóźnieniu i opcjach montowania. Zapisz dokładną wersję, tożsamość i obciążenie, dla których test zakończył się powodzeniem, aby wniosek pozostał warunkowy, a nie stał się twierdzeniem uniwersalnym.

WYNIK NEGATYWNY: baza danych zawiesza się, zgłasza błędy blokad lub fsync albo po awarii wraca do działania z niespójnym stanem. Wynik negatywny nie dowodzi automatycznie przeciwnej gałęzi, gdyż na obie mogą wpływać sieć, pamięć, uprawnienia lub spójność źródła; przed eskalacją odizoluj te wspólne zależności.

WYNIK WYJĄTKOWY LUB NIEJEDNOZNACZNY: przenieś pliki bazy danych z powrotem do lokalnej trwałej pamięci masowej oraz wykonuj kopie zapasowe lub replikację na poziomie aplikacji. Zachowaj dzienniki i nie uruchamiaj poleceń naprawy, czyszczenia, usuwania, partycjonowania ani rekurencyjnej zmiany właściciela, dopóki nie będzie istnieć kopia możliwa do odzyskania.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

Potwierdź decyzję przy użyciu pierwotnego obciążenia

Zastosuj działanie odpowiadające zaobserwowanej gałęzi, a następnie powtórz pierwotny warunek, a nie jego uproszczony zamiennik. Decyzja jest prawidłowa tylko wtedy, gdy transakcje pozostają trwałe, a odzyskiwanie kończy się powodzeniem bez uszkodzeń przy docelowym opóźnieniu i opcjach montowania przez dwa cykle lub podczas odpowiedniego ponownego uruchomienia, uśpienia, przerwy albo zmiany obciążenia.

Skorzystaj z procedury zrzutu bazy danych, aby sprawdzić najbliższy zależny proces, ale pozostaw pierwotny wyzwalacz bez zmian. Niepowiązane zestawy danych, udziały, kontenery, użytkownicy i punkty odzyskiwania muszą zachować wcześniejszy dostęp i czas działania.

Granica przerwania jest jednoznaczna: jeśli baza danych zawiesza się, zgłasza błędy blokad lub fsync albo po awarii wraca do działania z niespójnym stanem, wróć do ostatniej zweryfikowanej konfiguracji, zachowaj dowody i eskaluj do dokładniejszego testu platformy lub sprzętu tylko wtedy, gdy gałąź daje się powtórzyć.

Po uzyskaniu docelowego wyniku porównaj go z zachowaniem limitów czasu NFS, aby poprawka nie przeniosła ryzyka do sąsiedniej usługi. Pomyślny test docelowy z nową awarią kopii zapasowej, tożsamości, limitu czasu lub dostępności nadal oznacza nieudaną zmianę.

Najczęściej zadawane pytania

W przypadku plików bazy danych w pamięci sieciowej dodatkowe wyszukiwania zwykle dotyczą tego, czy NFS jest bezpieczniejszy od SMB dla plików bazy danych, czy dziennik WAL bazy danych może pozostać lokalny, gdy dane są zdalne, oraz czy sieciowy wolumin Docker różni się od montowania NFS na hoście. Poniższe odpowiedzi oddzielają te przypadki brzegowe od głównej decyzji.

Granica akceptacji pozostaje bez zmian: transakcje pozostają trwałe, a odzyskiwanie kończy się powodzeniem bez uszkodzeń przy docelowym opóźnieniu i opcjach montowania. Jeśli kolejny warunek zmienia system plików, tożsamość, ścieżkę sieciową lub wersję aplikacji, powtórz tylko test rozróżniający, którego dotyczy ta zmiana.

Przerwij rozszerzanie eksperymentu, gdy baza danych zawiesza się, zgłasza błędy blokad lub fsync albo po awarii wraca do działania z niespójnym stanem. W takim przypadku przenieś pliki bazy danych z powrotem do lokalnej trwałej pamięci masowej oraz wykonuj kopie zapasowe lub replikację na poziomie aplikacji; zachowaj dowody przed eskalacją do właściciela platformy, pamięci masowej lub sprzętu.

Czy NFS jest bezpieczniejszy od SMB dla plików bazy danych?

Sama nazwa protokołu nie wystarczy; znaczenie mają obsługa przez bazę danych, implementacja serwera, semantyka montowania i opóźnienia.

Czy dziennik WAL bazy danych może pozostać lokalny, gdy dane są zdalne?

Niektóre układy na to pozwalają, ale semantyka awarii i odzyskiwania staje się bardziej złożona i musi zostać przetestowana.

Czy sieciowy wolumin Docker różni się od montowania NFS na hoście?

Abstrakcja kontenera nie usuwa zachowania leżącego u podstaw sieciowego systemu plików.

W przypadku plików bazy danych w pamięci sieciowej praktyczna odpowiedź nadal zależy od warunków: transakcje pozostają trwałe, a odzyskiwanie kończy się powodzeniem bez uszkodzeń przy docelowym opóźnieniu i opcjach montowania. Gdy baza danych zawiesza się, zgłasza błędy blokad lub fsync albo po awarii wraca do działania z niespójnym stanem, przenieś pliki bazy danych z powrotem do lokalnej trwałej pamięci masowej oraz wykonuj kopie zapasowe lub replikację na poziomie aplikacji; częściowy sukces, który nie wytrzymuje pierwotnego obciążenia, nie oznacza zgodności.