Ulepszone skrypty prepostu dla migawki spójnej z bazą danych
Usługa Azure Backup udostępnia już strukturę skryptów prepost w celu zapewnienia spójności aplikacji na maszynach wirtualnych z systemem Linux przy użyciu usługi Azure Backup. Ten proces polega na wywołaniu skryptu wstępnego (w celu wstrzymania aplikacji) przed wykonaniem migawki dysków i wywołaniem skryptu post-script (polecenia w celu odblokowania aplikacji) po zakończeniu tworzenia migawki w celu zwrócenia aplikacji do trybu normalnego.
Tworzenie, debugowanie i obsługa skryptów przed/post może być trudne. Aby usunąć tę złożoność, usługa Azure Backup zapewnia uproszczone środowisko przed/po utworzeniu skryptu dla baz danych markizy, aby uzyskać spójną migawkę aplikacji z najmniejszym obciążeniem.
Nowa rozszerzona platforma skryptów wstępnych ma następujące kluczowe korzyści:
- Te skrypty wstępne są instalowane bezpośrednio na maszynach wirtualnych platformy Azure wraz z rozszerzeniem kopii zapasowej, co pomaga wyeliminować tworzenie i pobieranie ich z lokalizacji zewnętrznej.
- Możesz wyświetlić definicję i zawartość skryptów wstępnych w usłudze GitHub, nawet przesyłać sugestie i zmiany. Możesz nawet przesyłać sugestie i zmiany za pośrednictwem usługi GitHub, które zostaną sklasyfikowane i dodane w celu skorzystania z szerszej społeczności.
- Możesz nawet dodać nowe skrypty wstępne dla innych baz danych za pośrednictwem usługi GitHub, które zostaną sklasyfikowane i skierowane do szerszej społeczności.
- Niezawodna struktura jest wydajna do obsługi scenariuszy, takich jak niepowodzenie wykonywania skryptu wstępnego lub awarie. W każdym przypadku skrypt wykonywany po skrypie jest uruchamiany automatycznie, aby wycofać wszystkie zmiany wprowadzone w skryfcie wstępnym.
- Platforma udostępnia również kanał obsługi komunikatów dla narzędzi zewnętrznych do pobierania aktualizacji i przygotowywania własnego planu działania dla dowolnego komunikatu/zdarzenia.
Przepływ rozwiązania
Diagram pomocy technicznej
Poniższa lista baz danych jest objęta rozszerzoną strukturą:
- Oracle (ogólnie dostępna) - Link do macierzy obsługi
- MySQL (wersja zapoznawcza)
Wymagania wstępne
Wystarczy zmodyfikować plik konfiguracji workload.conf w /etc/azurepliku , aby podać szczegóły połączenia. Dzięki temu usługa Azure Backup może łączyć się z odpowiednią aplikacją i wykonywać skrypty wstępne i po jego wykonaniu. Plik konfiguracji ma następujące parametry.
[workload]
# valid values are mysql, oracle
workload_name =
command_path =
linux_user =
credString =
ipc_folder =
timeout =
W poniższej tabeli opisano parametry:
| Parametr | Obowiązkowy | Wyjaśnienie |
|---|---|---|
| workload_name | Tak | Będzie to zawierać nazwę bazy danych, dla której potrzebna jest spójna kopia zapasowa aplikacji. Bieżące obsługiwane wartości to oracle lub mysql. |
| command_path/configuration_path | Będzie to zawierać ścieżkę do pliku binarnego obciążenia. Nie jest to pole obowiązkowe, jeśli plik binarny obciążenia jest ustawiony jako zmienna ścieżki. | |
| linux_user | Tak | Będzie to zawierać nazwę użytkownika systemu Linux z dostępem do logowania użytkownika bazy danych. Jeśli ta wartość nie jest ustawiona, użytkownik root jest traktowany jako użytkownik domyślny. |
| credString | Oznacza to ciąg poświadczeń umożliwiający nawiązanie połączenia z bazą danych. Będzie to zawierać cały ciąg logowania. | |
| ipc_folder | Obciążenie może zapisywać tylko w określonych ścieżkach systemu plików. Należy podać tutaj tę ścieżkę folderu, aby skrypt wstępny mógł zapisać stany do tej ścieżki folderu. | |
| timeout | Tak | Jest to maksymalny limit czasu, dla którego baza danych będzie w stanie spoczynku. Wartość domyślna to 90 (sekund). Nie zaleca się ustawiania wartości mniejszej niż 60 sekund. |
Uwaga
Definicja JSON to szablon, który usługa Azure Backup może modyfikować tak, aby odpowiadała określonej bazie danych. Aby poznać plik konfiguracji dla każdej bazy danych, zapoznaj się z instrukcjami poszczególnych baz danych.
Ogólne środowisko korzystania z rozszerzonej struktury skryptów wstępnych wygląda następująco:
- Przygotowywanie środowiska bazy danych
- Edytowanie pliku konfiguracji
- Wyzwalanie kopii zapasowej maszyny wirtualnej
- Przywróć maszyny wirtualne lub dyski/pliki z spójnego punktu odzyskiwania aplikacji zgodnie z potrzebami.
Tworzenie strategii tworzenia kopii zapasowej bazy danych
Używanie migawek zamiast przesyłania strumieniowego
Zazwyczaj kopie zapasowe przesyłania strumieniowego (takie jak pełne, różnicowe lub przyrostowe) i dzienniki są używane przez administratorów bazy danych w strategii tworzenia kopii zapasowych. Poniżej przedstawiono niektóre kluczowe elementy przestawne w projekcie.
- Wydajność i koszty: codzienne pełne i dzienniki byłyby najszybsze podczas przywracania, ale wiąże się ze znacznymi kosztami. Uwzględnienie różnicowego/przyrostowego typu kopii zapasowej przesyłania strumieniowego zmniejsza koszt, ale może mieć wpływ na wydajność przywracania. Jednak migawki zapewniają najlepszą kombinację wydajności i kosztów. Ponieważ migawki są z natury przyrostowe, mają one najmniejszy wpływ na wydajność podczas tworzenia kopii zapasowej, są przywracane szybko, a także oszczędzają koszty.
- Wpływ na bazę danych/infrastrukturę: wydajność kopii zapasowej przesyłania strumieniowego zależy od podstawowej liczby operacji we/wy na sekundę magazynu i przepustowości sieci dostępnej, gdy strumień jest przeznaczony dla lokalizacji zdalnej. Migawki nie mają tej zależności, a zapotrzebowanie na liczbę operacji we/wy na sekundę i przepustowość sieci jest znacznie zmniejszone.
- Ponowne użyteczność: polecenia wyzwalania różnych typów kopii zapasowych przesyłania strumieniowego są różne dla każdej bazy danych. Dlatego skrypty nie mogą być łatwo używane ponownie. Ponadto, jeśli używasz różnych typów kopii zapasowych, upewnij się, że ocenisz łańcuch zależności w celu zachowania cyklu życia. W przypadku migawek można łatwo napisać skrypt, ponieważ nie ma łańcucha zależności.
- Długoterminowe przechowywanie: pełne kopie zapasowe są zawsze korzystne dla długoterminowego przechowywania, ponieważ można je niezależnie przenosić i odzyskiwać. Jednak w przypadku kopii zapasowych operacyjnych z krótkoterminowym przechowywaniem migawki są korzystne.
W związku z tym codzienna migawka i dzienniki z okazjonalnymi pełnymi kopiami zapasowymi na potrzeby długoterminowego przechowywania to najlepsze zasady tworzenia kopii zapasowych baz danych.
Strategia tworzenia kopii zapasowych dzienników
Rozszerzona struktura skryptów wstępnych jest oparta na kopii zapasowej maszyny wirtualnej platformy Azure, która planuje tworzenie kopii zapasowych raz dziennie. Dlatego okno utraty danych z celem punktu odzyskiwania (RPO) jako 24 godziny nie jest odpowiednie dla produkcyjnych baz danych. To rozwiązanie jest uzupełniane strategią tworzenia kopii zapasowej dziennika, w której kopie zapasowe dzienników są przesyłane strumieniowo jawnie.
System plików NFS w obiektach blob i NFS w usłudze AFS (wersja zapoznawcza) ułatwia instalowanie woluminów bezpośrednio na maszynach wirtualnych bazy danych i używanie klientów baz danych do transferu kopii zapasowych dziennika. Okno utraty danych, które jest celem punktu odzyskiwania, spada do częstotliwości tworzenia kopii zapasowych dziennika. Ponadto elementy docelowe systemu plików NFS nie muszą być wysoce wydajne, ponieważ może nie być konieczne wyzwalanie regularnego przesyłania strumieniowego (pełne i przyrostowe) na potrzeby kopii zapasowych operacyjnych po utworzeniu migawek spójnych na poziomie bazy danych.
Uwaga
Ulepszony skrypt wstępny zwykle dba o opróżnianie wszystkich transakcji dziennika przesyłanych do miejsca docelowego kopii zapasowej dziennika, zanim przełączysz bazę danych w stan spoczynku w celu utworzenia migawki. W związku z tym migawki są spójne i niezawodne podczas odzyskiwania.
Strategia odzyskiwania
Po utworzeniu migawek spójnych na poziomie bazy danych i strumieniu kopii zapasowych dziennika do woluminu NFS strategia odzyskiwania bazy danych może korzystać z funkcji odzyskiwania kopii zapasowych maszyn wirtualnych platformy Azure. Możliwość tworzenia kopii zapasowych dzienników jest dodatkowo stosowana do niej przy użyciu klienta bazy danych. Poniżej przedstawiono kilka opcji strategii odzyskiwania:
- Utwórz nowe maszyny wirtualne na podstawie punktu odzyskiwania spójnego z bazą danych. Maszyna wirtualna powinna już mieć połączony punkt instalacji dziennika. Użyj klientów bazy danych, aby uruchamiać polecenia odzyskiwania na potrzeby odzyskiwania do punktu w czasie.
- Utwórz dyski z punktu odzyskiwania spójnego z bazą danych i dołącz je do innej docelowej maszyny wirtualnej. Następnie zainstaluj miejsce docelowe dziennika i użyj klientów bazy danych do uruchamiania poleceń odzyskiwania na potrzeby odzyskiwania do punktu w czasie
- Użyj opcji odzyskiwania plików i wygeneruj skrypt. Uruchom skrypt na docelowej maszynie wirtualnej i dołącz punkt odzyskiwania jako dyski iSCSI. Następnie użyj klientów bazy danych, aby uruchomić funkcje weryfikacji specyficzne dla bazy danych na dołączonych dyskach i zweryfikować dane kopii zapasowej. Ponadto należy użyć klientów bazy danych, aby wyeksportować/odzyskać kilka tabel/plików zamiast odzyskać całą bazę danych.
- Funkcja przywracania między regionami umożliwia wykonywanie powyższych akcji z sparowanego regionu pomocniczego podczas awarii regionalnej.
Podsumowanie
Korzystając z kopii zapasowych migawek i dzienników spójnych na poziomie bazy danych przy użyciu rozwiązania niestandardowego, możesz utworzyć wydajne i ekonomiczne rozwiązanie do tworzenia kopii zapasowych baz danych, korzystając z zalet tworzenia kopii zapasowych maszyn wirtualnych platformy Azure, a także ponownego korzystania z możliwości klientów baz danych.