Tworzenie kopii zapasowej i przywracanie w usłudze Azure Database for MySQL

DOTYCZY: Azure Database for MySQL — pojedynczy serwer

Ważne

Pojedynczy serwer usługi Azure Database for MySQL znajduje się na ścieżce wycofania. Zdecydowanie zalecamy uaktualnienie do serwera elastycznego usługi Azure Database for MySQL. Aby uzyskać więcej informacji na temat migracji do serwera elastycznego usługi Azure Database for MySQL, zobacz Co się dzieje z usługą Azure Database for MySQL — pojedynczy serwer?

Usługa Azure Database for MySQL automatycznie tworzy kopie zapasowe serwera i przechowuje je w skonfigurowanym przez użytkownika magazynie lokalnie nadmiarowym lub magazynie geograficznie nadmiarowym. Kopie zapasowe mogą być używane do przywracania serwera do punktu w czasie. Tworzenie kopii zapasowych i przywracanie jest istotną częścią strategii ciągłości biznesowej, ponieważ chronią dane przed przypadkowym uszkodzeniem lub usunięciem.

Kopie zapasowe

Usługa Azure Database for MySQL wykonuje kopie zapasowe plików danych i dziennika transakcji. Te kopie zapasowe umożliwiają przywrócenie serwera do dowolnego punktu w czasie w skonfigurowanym okresie przechowywania kopii zapasowych. Domyślny okres przechowywania kopii zapasowych wynosi siedem dni. Opcjonalnie można skonfigurować go maksymalnie 35 dni. Wszystkie kopie zapasowe są szyfrowane za pomocą 256-bitowego szyfrowania AES.

Te pliki kopii zapasowej nie są uwidaczniane dla użytkownika i nie można ich wyeksportować. Te kopie zapasowe mogą być używane tylko na potrzeby operacji przywracania w usłudze Azure Database for MySQL. Aby skopiować bazę danych, możesz użyć narzędzia mysqldump .

Typ i częstotliwość tworzenia kopii zapasowej zależy od magazynu zaplecza dla serwerów.

Typ i częstotliwość tworzenia kopii zapasowej

Podstawowe serwery magazynu

Magazyn podstawowy to magazyn zaplecza obsługujący serwery w warstwie Podstawowa. Kopie zapasowe na serwerach magazynu w warstwie Podstawowa są oparte na migawkach. Pełna migawka bazy danych jest wykonywana codziennie. Nie ma różnicowych kopii zapasowych wykonywanych dla podstawowych serwerów magazynu, a wszystkie kopie zapasowe migawek są tylko pełnymi kopiami zapasowymi bazy danych.

Kopie zapasowe dziennika transakcji są wykonywane co pięć minut.

Serwery magazynu ogólnego przeznaczenia w wersji 1 (obsługuje do 4 TB magazynu)

Magazyn ogólnego przeznaczenia to magazyn zaplecza obsługujący serwer warstwy Ogólnego przeznaczenia i Zoptymalizowane pod kątem pamięci. W przypadku serwerów z magazynem ogólnego przeznaczenia do 4 TB pełne kopie zapasowe są wykonywane co tydzień. Różnicowe kopie zapasowe są wykonywane dwa razy dziennie. Kopie zapasowe dziennika transakcji są wykonywane co pięć minut. Kopie zapasowe w magazynie ogólnego przeznaczenia do 4 TB nie są oparte na migawkach i zużywają przepustowość operacji we/wy w czasie tworzenia kopii zapasowej. W przypadku dużych baz danych (> 1 TB) w magazynie o pojemności 4 TB zalecamy rozważenie

  • Aprowizowanie większej liczby operacji we/wy na koncie kopii zapasowych operacji we/wy lub
  • Alternatywnie przeprowadź migrację do magazynu ogólnego przeznaczenia, który obsługuje do 16 TB magazynu, jeśli podstawowa infrastruktura magazynu jest dostępna w preferowanych regionach świadczenia usługi Azure. Nie ma dodatkowych kosztów magazynu ogólnego przeznaczenia, który obsługuje do 16 TB miejsca do magazynowania. Aby uzyskać pomoc dotyczącą migracji do magazynu o pojemności 16 TB, otwórz bilet pomocy technicznej w witrynie Azure Portal.

Serwery magazynu ogólnego przeznaczenia w wersji 2 (obsługuje do 16 TB magazynu)

W podzestawie regionów platformy Azure wszystkie nowo aprowidowane serwery mogą obsługiwać magazyn ogólnego przeznaczenia do 16 TB. Innymi słowy, magazyn do 16 TB jest domyślnym magazynem ogólnego przeznaczenia dla wszystkich regionów , w których jest obsługiwana. Kopie zapasowe na tych 16 TB serwerów magazynu są oparte na migawkach. Pierwsza kopia zapasowa migawki jest planowana natychmiast po utworzeniu serwera. Kopie zapasowe migawek są wykonywane raz dziennie. Kopie zapasowe dziennika transakcji są wykonywane co pięć minut.

Aby uzyskać więcej informacji na temat magazynu podstawowego i ogólnego przeznaczenia, zapoznaj się z dokumentacją magazynu.

Przechowywanie kopii zapasowej

Kopie zapasowe są zachowywane na podstawie ustawienia okresu przechowywania kopii zapasowych na serwerze. Możesz wybrać okres przechowywania od 7 do 35 dni. Domyślny okres przechowywania wynosi 7 dni. Okres przechowywania można ustawić podczas tworzenia serwera lub nowszego, aktualizując konfigurację kopii zapasowej przy użyciu witryny Azure Portal lub interfejsu wiersza polecenia platformy Azure.

Okres przechowywania kopii zapasowej określa, jak daleko w czasie można pobrać przywracanie do punktu w czasie, ponieważ jest on oparty na dostępnych kopiach zapasowych. Okres przechowywania kopii zapasowej może być również traktowany jako okno odzyskiwania z perspektywy przywracania. Wszystkie kopie zapasowe wymagane do wykonania przywracania do punktu w czasie w okresie przechowywania kopii zapasowych są przechowywane w magazynie kopii zapasowych. Jeśli na przykład okres przechowywania kopii zapasowej jest ustawiony na 7 dni, okno odzyskiwania jest uznawane za ostatnie 7 dni. W tym scenariuszu wszystkie kopie zapasowe wymagane do przywrócenia serwera w ciągu ostatnich 7 dni są zachowywane. W oknie przechowywania kopii zapasowych z siedmiu dni:

  • Serwery magazynu ogólnego przeznaczenia w wersji 1 (obsługujące maksymalnie 4 TB) zachowają maksymalnie 2 pełne kopie zapasowe bazy danych, wszystkie różnicowe kopie zapasowe i kopie zapasowe dziennika transakcji wykonywane od najwcześniejszej pełnej kopii zapasowej bazy danych.
  • Serwery magazynu ogólnego przeznaczenia w wersji 2 (obsługujące do 16 TB magazynu) zachowają pełne migawki bazy danych i kopie zapasowe dziennika transakcji w ciągu ostatnich 8 dni.

Długoterminowe przechowywanie

Długoterminowe przechowywanie kopii zapasowych poza 35 dni nie jest jeszcze natywnie obsługiwane przez usługę. Istnieje możliwość użycia narzędzia mysqldump do tworzenia kopii zapasowych i przechowywania ich na potrzeby długoterminowego przechowywania. Nasz zespół pomocy technicznej blogował artykuł krok po kroku, aby podzielić się tym , jak można to osiągnąć.

Opcje nadmiarowości kopii zapasowej

Usługa Azure Database for MySQL zapewnia elastyczność wyboru między lokalnie nadmiarowym lub geograficznie nadmiarowym magazynem kopii zapasowych w warstwach Ogólnego przeznaczenia i Zoptymalizowane pod kątem pamięci. Gdy kopie zapasowe są przechowywane w magazynie kopii zapasowych geograficznie nadmiarowych, są przechowywane nie tylko w regionie, w którym jest hostowany serwer, ale są również replikowane do sparowanego centrum danych. Ta nadmiarowość geograficzna zapewnia lepszą ochronę i możliwość przywracania serwera w innym regionie w przypadku awarii. Warstwa Podstawowa oferuje tylko lokalnie nadmiarowy magazyn kopii zapasowych.

Uwaga

W następujących regionach : Indie Środkowe, Francja Środkowa, Północ ZEA, Republika Południowej Afryki; Magazyn ogólnego przeznaczenia w wersji 2 jest w publicznej wersji zapoznawczej. Jeśli tworzysz serwer źródłowy w magazynie ogólnego przeznaczenia w wersji 2 (obsługa do 16 TB magazynu) w wymienionych powyżej regionach, włączenie geograficznie nadmiarowej kopii zapasowej nie jest obsługiwane.

Przechodzenie z lokalnie nadmiarowego do geograficznie nadmiarowego magazynu kopii zapasowych

Konfigurowanie lokalnie nadmiarowego lub geograficznie nadmiarowego magazynu dla kopii zapasowych jest dozwolone tylko podczas tworzenia serwera. Po aprowizacji serwera nie można zmienić opcji nadmiarowości magazynu kopii zapasowych. Aby przenieść magazyn kopii zapasowych z magazynu lokalnie nadmiarowego do magazynu geograficznie nadmiarowego, utworzenie nowego serwera i migracja danych przy użyciu zrzutu i przywracania jest jedyną obsługiwaną opcją.

Koszt magazynu kopii zapasowych

Usługa Azure Database for MySQL zapewnia do 100% aprowizowanego rozmiaru magazynu na serwerze jako magazynu kopii zapasowych bez dodatkowych kosztów. Opłaty za dodatkowy magazyn kopii zapasowych są naliczane w GB miesięcznie. Jeśli na przykład aprowizujesz serwer z magazynem o rozmiarze 250 GB, masz 250 GB dodatkowego magazynu dostępnego dla kopii zapasowych serwera bez dodatkowych opłat. Opłata za magazyn używany dla kopii zapasowych przekraczających 250 GB jest naliczana zgodnie z modelem cenowym.

Możesz użyć metryki Magazynu kopii zapasowych używanej w usłudze Azure Monitor dostępnej za pośrednictwem witryny Azure Portal, aby monitorować magazyn kopii zapasowych używany przez serwer. Użyta metryka Magazynu kopii zapasowych reprezentuje sumę magazynu używanego przez wszystkie pełne kopie zapasowe bazy danych, różnicowe kopie zapasowe i kopie zapasowe dzienników przechowywane na podstawie okresu przechowywania kopii zapasowych ustawionego dla serwera. Częstotliwość tworzenia kopii zapasowych jest zarządzana przez usługę i objaśniona wcześniej. Duża liczba transakcji na serwerze może powodować zwiększenie użycia magazynu kopii zapasowych niezależnie od całkowitego rozmiaru bazy danych. W przypadku magazynu geograficznie nadmiarowego użycie magazynu kopii zapasowych jest dwa razy większe niż w przypadku magazynu lokalnie nadmiarowego.

Podstawowym sposobem kontrolowania kosztów magazynu kopii zapasowych jest ustawienie odpowiedniego okresu przechowywania kopii zapasowych i wybranie odpowiednich opcji nadmiarowości kopii zapasowych w celu spełnienia żądanych celów odzyskiwania. Możesz wybrać okres przechowywania z zakresu od 7 do 35 dni. Serwery ogólnego przeznaczenia i zoptymalizowane pod kątem pamięci mogą mieć magazyn geograficznie nadmiarowy do tworzenia kopii zapasowych.

Przywracanie

W usłudze Azure Database for MySQL wykonanie przywracania powoduje utworzenie nowego serwera na podstawie kopii zapasowych oryginalnego serwera i przywrócenie wszystkich baz danych znajdujących się na serwerze. Przywracanie nie jest obecnie obsługiwane, jeśli oryginalny serwer jest w stanie zatrzymania.

Dostępne są dwa typy przywracania:

  • Przywracanie do punktu w czasie jest dostępne z jedną z opcji nadmiarowości kopii zapasowych i tworzy nowy serwer w tym samym regionie co oryginalny serwer przy użyciu kombinacji pełnych i transakcyjnych kopii zapasowych dziennika.
  • Przywracanie geograficzne jest dostępne tylko w przypadku skonfigurowania serwera na potrzeby magazynu geograficznie nadmiarowego i umożliwia przywrócenie serwera do innego regionu przy użyciu najnowszej kopii zapasowej.

Szacowany czas odzyskiwania serwera zależy od kilku czynników:

  • Rozmiar baz danych
  • Liczba zaangażowanych dzienników transakcji
  • Ilość działań, które należy odtworzyć w celu odzyskania do punktu przywracania
  • Przepustowość sieci, jeśli przywracanie jest w innym regionie
  • Liczba współbieżnych żądań przywracania przetwarzanych w regionie docelowym
  • Obecność klucza podstawowego w tabelach w bazie danych. Aby przyspieszyć odzyskiwanie, rozważ dodanie klucza podstawowego dla wszystkich tabel w bazie danych. Aby sprawdzić, czy tabele mają klucz podstawowy, możesz użyć następującego zapytania:
select tab.table_schema as database_name, tab.table_name from information_schema.tables tab left join information_schema.table_constraints tco on tab.table_schema = tco.table_schema and tab.table_name = tco.table_name and tco.constraint_type = 'PRIMARY KEY' where tco.constraint_type is null and tab.table_schema not in('mysql', 'information_schema', 'performance_schema', 'sys') and tab.table_type = 'BASE TABLE' order by tab.table_schema, tab.table_name;

W przypadku dużej lub bardzo aktywnej bazy danych przywracanie może potrwać kilka godzin. Jeśli w regionie występuje długotrwała awaria, możliwe jest, że duża liczby żądań przywracania geograficznego zostanie zainicjowana na potrzeby odzyskiwania po awarii. Jeśli istnieje wiele żądań, czas odzyskiwania poszczególnych baz danych może się wydłużyć. Większość operacji przywracania bazy danych kończy się w czasie krótszym niż 12 godzin.

Ważne

Usunięte serwery można przywrócić tylko w ciągu pięciu dni od usunięcia, po którym kopie zapasowe są usuwane. Dostęp do kopii zapasowej bazy danych można uzyskać i przywrócić tylko z subskrypcji platformy Azure hostowanej na serwerze. Aby przywrócić usunięty serwer, zapoznaj się z udokumentowanymi krokami. Aby chronić zasoby serwera, po wdrożeniu przed przypadkowym usunięciem lub nieoczekiwanymi zmianami, administratorzy mogą korzystać z blokad zarządzania.

Przywracanie do punktu w czasie

Niezależnie od opcji nadmiarowości kopii zapasowej można wykonać przywracanie do dowolnego punktu w czasie w okresie przechowywania kopii zapasowej. Nowy serwer jest tworzony w tym samym regionie świadczenia usługi Azure co oryginalny serwer. Jest on tworzony przy użyciu konfiguracji oryginalnego serwera dla warstwy cenowej, generowania obliczeń, liczby rdzeni wirtualnych, rozmiaru magazynu, okresu przechowywania kopii zapasowych i opcji nadmiarowości kopii zapasowych.

Uwaga

Istnieją dwa parametry serwera, które są resetowane do wartości domyślnych (i nie są kopiowane z serwera podstawowego) po operacji przywracania

  • time_zone — ta wartość, aby ustawić wartość DOMYŚLNA SYSTEM
  • event_scheduler — event_scheduler jest ustawiona na wartość WYŁ . na przywróconym serwerze

Należy ustawić te parametry serwera, konfigurując ponownie parametr serwera

Przywracanie do punktu w czasie jest przydatne w wielu scenariuszach. Na przykład gdy użytkownik przypadkowo usunie dane, usunie ważną tabelę lub bazę danych lub jeśli aplikacja przypadkowo zastąpi dobre dane z nieprawidłowymi danymi z powodu wady aplikacji.

Może być konieczne poczekanie na wykonanie następnej kopii zapasowej dziennika transakcji, zanim będzie można przywrócić do punktu w czasie w ciągu ostatnich pięciu minut.

Przywracanie geograficzne

Serwer można przywrócić do innego regionu świadczenia usługi Azure, w którym usługa jest dostępna, jeśli skonfigurowano serwer pod kątem geograficznie nadmiarowych kopii zapasowych.

  • Serwery magazynu ogólnego przeznaczenia w wersji 1 (obsługujące maksymalnie 4 TB magazynu) można przywrócić do sparowanego geograficznie regionu lub dowolnego regionu świadczenia usługi Azure, który obsługuje usługę Azure Database for MySQL — pojedynczy serwer.
  • Serwery magazynu ogólnego przeznaczenia w wersji 2 (obsługujące maksymalnie 16 TB magazynu) można przywrócić tylko do regionów świadczenia usługi Azure, które obsługują infrastrukturę serwerów magazynu ogólnego przeznaczenia w wersji 2. Przejrzyj warstwy cenowe Azure Database for MySQL, aby zapoznać się z listą obsługiwanych regionów.

Przywracanie geograficzne to domyślna opcja odzyskiwania, gdy serwer jest niedostępny z powodu zdarzenia w regionie, w którym jest hostowany serwer. Jeśli zdarzenie na dużą skalę w regionie powoduje niedostępność aplikacji bazy danych, możesz przywrócić serwer z geograficznie nadmiarowych kopii zapasowych do serwera w dowolnym innym regionie. Przywracanie geograficzne wykorzystuje najnowszą kopię zapasową serwera. Występuje opóźnienie między wykonaniem kopii zapasowej a replikacją do innego regionu. To opóźnienie może potrwać do godziny, więc w przypadku wystąpienia awarii może wystąpić nawet jedna godzina utraty danych.

Ważne

Jeśli przywracanie geograficzne jest wykonywane dla nowo utworzonego serwera, początkowa synchronizacja kopii zapasowej może potrwać ponad 24 godziny w zależności od rozmiaru danych, ponieważ początkowy pełny czas kopiowania kopii zapasowej migawki jest znacznie wyższy. Kolejne kopie zapasowe migawek są kopiami przyrostowymi, dlatego przywracanie jest szybsze po 24 godzinach tworzenia serwera. Jeśli oceniasz operacje przywracania geograficznego w celu zdefiniowania celu czasu odzyskiwania, zalecamy odczekanie i ocenę przywracania geograficznego dopiero po 24 godzinach tworzenia serwera w celu uzyskania lepszych szacunków.

Podczas przywracania geograficznego konfiguracje serwerów, które można zmienić, obejmują generację obliczeń, rdzeń wirtualny, okres przechowywania kopii zapasowych oraz opcje nadmiarowości kopii zapasowych. Zmiana warstwy cenowej (Podstawowa, Ogólnego przeznaczenia lub Zoptymalizowana pod kątem pamięci) lub rozmiaru magazynu podczas przywracania geograficznego nie jest obsługiwana.

Szacowany czas odzyskiwania zależy od wielu czynników, w tym rozmiaru bazy danych, rozmiaru dziennika transakcji, przepustowości sieci oraz łącznej liczby jednocześnie odzyskiwanych baz danych w tym samym regionie. Odzyskiwanie trwa zwykle mniej niż 12 godzin.

Wykonywanie zadań po przywróceniu

Po przywróceniu z dowolnego mechanizmu odzyskiwania należy wykonać następujące zadania, aby umożliwić użytkownikom i aplikacjom tworzenie kopii zapasowych i uruchamianie ich:

  • Jeśli nowy serwer ma zastąpić oryginalny serwer, przekieruj klientów i aplikacje klienckie na nowy serwer
  • Upewnij się, że istnieją odpowiednie reguły sieci wirtualnej, aby użytkownicy nawiązywali połączenie. Te reguły nie są kopiowane z oryginalnego serwera.
  • Upewnij się, że obowiązują odpowiednie identyfikatory logowania i uprawnienia na poziomie bazy danych
  • W razie potrzeby skonfiguruj alerty

Następne kroki