Ulepszone skrypty wstępne dla migawki spójnej z bazą danych

usługa Azure Backup udostępnia już strukturę skryptów wstępnych w celu zapewnienia spójności aplikacji na maszynach wirtualnych z systemem Linux przy użyciu Azure Backup. Obejmuje to wywołanie skryptu wstępnego (w celu przełączenia aplikacji w stan spoczynku) przed utworzeniem migawki dysków i wywołaniem skryptu post-script (polecenia w celu wyrejeścia aplikacji) po zakończeniu tworzenia migawki w celu zwrócenia aplikacji do trybu normalnego.

Tworzenie, debugowanie i konserwacja skryptów wstępnych/postów e może być trudne. Aby usunąć tę złożoność, Azure Backup zapewnia uproszczone środowisko przed/po skryscie dla baz danych markizy, aby uzyskać spójną migawkę aplikacji z najmniejszym obciążeniem.

Nowa rozszerzona struktura 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. Pomaga to wyeliminować tworzenie i pobieranie ich z lokalizacji zewnętrznej.
• Definicję i zawartość skryptów wstępnych można wyświetlić 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 w celu skorzystania z szerszej społeczności.
• Niezawodna struktura jest wydajna do obsługi scenariuszy, takich jak niepowodzenie wykonywania skryptu wstępnego lub awarie. W każdym razie skrypt wykonywany po skryfcie jest uruchamiany automatycznie, aby wycofać wszystkie zmiany wprowadzone w skryfcie wstępnym.
• Platforma udostępnia również kanał obsługi komunikatów dla zewnętrznych narzędzi do pobierania aktualizacji i przygotowywania własnego planu działania dla dowolnego komunikatu/zdarzenia.

Przepływ rozwiązania

Tabela obsługi

Poniższa lista baz danych jest objęta rozszerzoną strukturą:

• Oracle (ogólnie dostępna) - Łącze 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 Azure Backup nawiązywać połączenie z odpowiednią aplikacją i wykonywać skrypty wstępne i wykonywane 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 główny 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 w tej ścieżce 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 jest szablonem, 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 przed postem wygląda następująco:

• Przygotowywanie środowiska bazy danych
• Edytowanie pliku konfiguracji
• Wyzwalanie kopii zapasowej maszyny wirtualnej
• W razie potrzeby przywróć maszyny wirtualne lub dyski/pliki z punktu odzyskiwania spójnego na poziomie aplikacji.

Tworzenie strategii tworzenia kopii zapasowych bazy danych

Używanie migawek zamiast przesyłania strumieniowego

Zwykle 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 koszt: 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. Migawki zapewniają jednak najlepszą kombinację wydajności i kosztów. Ponieważ migawki są z natury przyrostowe, mają 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 wyzwalające różne typy kopii zapasowych przesyłania strumieniowego są różne dla każdej bazy danych. Dlatego nie można łatwo ponownie używać skryptów. Ponadto, jeśli używasz różnych typów kopii zapasowych, pamiętaj, aby ocenić ł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 przechowywaniem krótkoterminowym migawki są korzystne.

W związku z tym codzienna migawka i dzienniki z okazjonalną pełną kopią zapasową na potrzeby przechowywania długoterminowego 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 zapasowej raz dziennie. Dlatego okno utraty danych z obiektem RPO jako 24 godziny nie jest odpowiednie dla produkcyjnych baz danych. To rozwiązanie jest uzupełniane strategią tworzenia kopii zapasowych dzienników, w której kopie zapasowe dzienników są jawnie przesyłane strumieniowo.

System plików NFS na 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 bazy danych do transferu kopii zapasowych dziennika. Okno utraty danych, czyli cel 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óżnienie wszystkich transakcji dziennika podczas przesyłania do miejsca docelowego kopii zapasowej dziennika przed przełączenie bazy 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, a kopie zapasowe dzienników są przesyłane strumieniowo 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 do uruchamiania poleceń odzyskiwania na potrzeby odzyskiwania do punktu w czasie.
• Utwórz dyski na podstawie 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.
• Użyj funkcji przywracania między regionami, aby wykonać powyższe akcje z regionu pomocniczego sparowanego podczas awarii regionalnej.

Podsumowanie

Korzystając ze spójnych migawek baz danych i dzienników kopii zapasowych przy użyciu rozwiązania niestandardowego, można utworzyć wydajne i ekonomiczne rozwiązanie do tworzenia kopii zapasowej bazy danych, korzystając z zalet tworzenia kopii zapasowych maszyn wirtualnych platformy Azure, a także ponownego korzystania z możliwości klientów bazy danych.