Udostępnij za pośrednictwem

Tworzenie kopii zapasowych i przywracanie w usłudze Azure Database for MySQL — serwer elastyczny

  • Artykuł

DOTYCZY: Azure Database for MySQL — serwer elastyczny

Usługa Azure Database for MySQL — elastyczny serwer automatycznie tworzy kopie zapasowe serwera i bezpiecznie przechowuje je w magazynie lokalnie nadmiarowym w regionie. 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.

Omówienie usługi Backup

Usługa Azure Database for MySQL — elastyczny serwer obsługuje dwa typy kopii zapasowych, co zapewnia większą elastyczność w zakresie obsługi kopii zapasowych danych krytycznych dla działania firmy.

Automatyczne kopie zapasowe

Usługa Azure Database for MySQL — elastyczny serwer tworzy migawki plików danych i przechowuje je w magazynie lokalnie nadmiarowym. Serwer wykonuje również kopie zapasowe dzienników transakcji, a także przechowuje je w magazynie lokalnie nadmiarowym. 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żesz skonfigurować kopię zapasową bazy danych z zakresu od 1 do 35 dni. Wszystkie kopie zapasowe są szyfrowane przy użyciu 256-bitowego szyfrowania AES dla danych przechowywanych w spoczynku.

Kopia zapasowa na żądanie

Usługa Azure Database for MySQL — elastyczny serwer umożliwia również wyzwalanie kopii zapasowych obciążenia produkcyjnego na żądanie, oprócz automatycznych kopii zapasowych wykonanych przez usługę i przechowywania ich zgodnie z zasadami przechowywania kopii zapasowych serwera. Tych kopii zapasowych można użyć jako najszybszego punktu przywracania, aby wykonać przywracanie do punktu w czasie, aby skrócić czas przywracania o maksymalnie 90%. Domyślny okres przechowywania kopii zapasowych wynosi siedem dni. Opcjonalnie możesz skonfigurować kopię zapasową bazy danych z zakresu od 1 do 35 dni. W portalu można wyzwolić łącznie 50 kopii zapasowych na żądanie. Wszystkie kopie zapasowe są szyfrowane przy użyciu 256-bitowego szyfrowania AES dla danych przechowywanych w spoczynku.

Nie można wyeksportować tych plików kopii zapasowych. Kopie zapasowe mogą być używane tylko na potrzeby operacji przywracania na serwerze elastycznym usługi Azure Database for MySQL. Możesz również użyć narzędzia mysqldump z klienta MySQL, aby skopiować bazę danych.

Częstotliwość wykonywania kopii zapasowych

Kopie zapasowe na serwerach elastycznych 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. Jeśli zaplanowana kopia zapasowa nie powiedzie się, nasza usługa spróbuje wykonać kopię zapasową co 20 minut, dopóki nie zostanie ona pomyślnie wykonana. Te błędy tworzenia kopii zapasowej mogą wystąpić z powodu dużych obciążeń produkcyjnych transakcyjnych w wystąpieniu serwera.

Uwaga

  • Jeśli serwer ma duże obciążenie transakcji, co spowoduje szybsze i większe pliki binlog, usługa kopii zapasowej wykona wiele kopii zapasowych dziennie, aby zapewnić niezawodne i szybsze przywracanie przy użyciu tych kopii zapasowych.
  • W przypadku serwerów 5.7 długotrwałe/duże transakcje mogą zapobiec przejęciu blokady na poziomie wystąpienia globalnego, co jest wymagane do pomyślnego codziennego tworzenia kopii zapasowej. W takich scenariuszach codzienne kopie zapasowe mogą zakończyć się niepowodzeniem. Aby rozwiązać ten problem, zakończ długotrwałą transakcję LUB uruchom ponownie serwer. Aby zapewnić bezproblemowe operacje, zaleca się uaktualnienie serwerów MySQL 5.7 do wersji 8.0 przy użyciu uaktualnienia wersji głównej.

Opcje nadmiarowości kopii zapasowej

Usługa Azure Database for MySQL — elastyczny serwer przechowuje wiele kopii kopii zapasowych, dzięki czemu dane są chronione przed zaplanowanymi i nieplanowanymi zdarzeniami, w tym przejściowymi awariami sprzętu, awariami sieci lub zasilania oraz ogromnymi klęskami żywiołowymi. Serwer elastyczny usługi Azure Database for MySQL zapewnia elastyczność wyboru między lokalnie nadmiarowym, strefowo nadmiarowym lub geograficznie nadmiarowym magazynem kopii zapasowych w warstwach Podstawowa, Ogólnego przeznaczenia i Krytyczne dla działania firmy. Domyślnie magazyn kopii zapasowych serwera elastycznego usługi Azure Database for MySQL jest lokalnie nadmiarowy dla serwerów o wysokiej dostępności w tej samej strefie lub bez konfiguracji wysokiej dostępności oraz strefowo nadmiarowej dla serwerów ze strefowo nadmiarową konfiguracją wysokiej dostępności.

Nadmiarowość kopii zapasowych zapewnia, że baza danych spełnia jej cele dostępności i trwałości nawet w przypadku awarii, a serwer elastyczny usługi Azure Database for MySQL rozszerza trzy opcje dla użytkowników —

  • Lokalnie nadmiarowy magazyn kopii zapasowych: gdy kopie zapasowe są przechowywane w lokalnie nadmiarowym magazynie kopii zapasowych, wiele kopii kopii zapasowych jest przechowywanych w tym samym centrum danych. Ta opcja chroni dane przed awariami stojaka serwera i stacji dysków. Ponadto zapewnia to co najmniej 99,99999999999% (11 9) trwałości obiektów Kopii zapasowych w danym roku. Domyślnie magazyn kopii zapasowych dla serwerów z wysoką dostępnością w tej samej strefie lub żadna konfiguracja wysokiej dostępności nie jest ustawiona na lokalnie nadmiarową.

  • Magazyn kopii zapasowych strefowo nadmiarowych: gdy kopie zapasowe są przechowywane w magazynie kopii zapasowych strefowo nadmiarowych, wiele kopii nie jest przechowywanych tylko w strefie dostępności, w której jest hostowany serwer, ale są również replikowane do innej strefy dostępności w tym samym regionie. Tę opcję można wykorzystać w scenariuszach wymagających wysokiej dostępności lub ograniczenia replikacji danych do kraju/regionu w celu spełnienia wymagań dotyczących przechowywania danych. Ponadto zapewnia to co najmniej 99,999999999999% (12 9) trwałości obiektów Kopii zapasowych w danym roku. Można wybrać opcję Strefowo nadmiarowa wysoka dostępność w czasie tworzenia serwera, aby zapewnić strefowo nadmiarowy magazyn kopii zapasowych. Wysoka dostępność serwera można wyłączyć po utworzeniu, ale magazyn kopii zapasowych pozostaje strefowo nadmiarowy.

  • Magazyn kopii zapasowych geograficznie nadmiarowych: gdy kopie zapasowe są przechowywane w geograficznie nadmiarowym magazynie kopii zapasowych, wiele kopii nie jest przechowywanych tylko w regionie, w którym jest hostowany serwer, ale są również replikowane do regionu sparowanego geograficznie. Zapewnia to lepszą ochronę i możliwość przywrócenia serwera w innym regionie w przypadku awarii. Ponadto zapewnia to co najmniej 99,999999999999999999% (16 9) trwałości obiektów Kopii zapasowych w danym roku. Można włączyć opcję nadmiarowości geograficznej w czasie tworzenia serwera, aby zapewnić geograficznie nadmiarowy magazyn kopii zapasowych. Ponadto można przenieść magazyn lokalnie nadmiarowy do magazynu geograficznie nadmiarowego po utworzeniu serwera. Nadmiarowość geograficzna jest obsługiwana w przypadku serwerów hostowanych w dowolnym ze sparowanych regionów platformy Azure.

Uwaga

Strefowo nadmiarowa wysoka dostępność do obsługi nadmiarowości strefy jest obecnie dostępna tylko jako operacja tworzenia czasu. Obecnie dla strefowo nadmiarowej nadmiarowości geograficznej serwera wysokiej dostępności można włączyć/wyłączyć tylko w czasie tworzenia serwera.

Przenoszenie z innych opcji magazynu kopii zapasowych do magazynu kopii zapasowych geograficznie nadmiarowego

Istniejące magazyny kopii zapasowych można przenieść do magazynu geograficznie nadmiarowego, korzystając z następujących sugerowanych sposobów:

  • Przejście z lokalnie nadmiarowego do geograficznie nadmiarowego magazynu kopii zapasowych — aby przenieść magazyn kopii zapasowych z magazynu lokalnie nadmiarowego do magazynu geograficznie nadmiarowego, możesz zmienić konfigurację serwera Compute + Storage z witryny Azure Portal, aby włączyć nadmiarowość geograficzną dla lokalnie nadmiarowego serwera źródłowego. Te same serwery strefowo nadmiarowej wysokiej dostępności można również przywrócić jako serwer geograficznie nadmiarowy w podobny sposób, jak podstawowy magazyn kopii zapasowych jest lokalnie nadmiarowy dla tego samego.

  • Przejście ze strefowo nadmiarowego do geograficznie nadmiarowego magazynu kopii zapasowych — serwer elastyczny usługi Azure Database for MySQL nie obsługuje magazynu strefowo nadmiarowego do geograficznie nadmiarowej konwersji magazynu za pomocą ustawień obliczeń i magazynu po aprowizacji serwera. Aby przenieść magazyn kopii zapasowych z magazynu strefowo nadmiarowego do magazynu geograficznie nadmiarowego, dostępne są dwie opcje: a) Przywracanie do punktu w czasie (punkt w czasie) w celu przywrócenia serwera z odpowiednią konfiguracją. b) Utwórz nowy serwer z żądaną konfiguracją i zmigruj dane przy użyciu zrzutu i przywracania.

Przechowywanie kopii zapasowej

Kopie zapasowe są zachowywane na podstawie ustawienia okresu przechowywania kopii zapasowych na serwerze. Możesz wybrać okres przechowywania od 1 do 35 dni z domyślnym okresem przechowywania wynosi siedem dni. Okres przechowywania można ustawić podczas tworzenia serwera lub nowszego, aktualizując konfigurację kopii zapasowej przy użyciu witryny Azure Portal.

Okres przechowywania kopii zapasowych określa, jak daleko w czasie może być wykonywana operacja przywracania do punktu w czasie, ponieważ jest oparta 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. Na przykład — jeśli okres przechowywania kopii zapasowej jest ustawiony na siedem dni, okno odzyskiwania jest uznawane za ostatnie siedem dni. W tym scenariuszu wszystkie kopie zapasowe wymagane do przywrócenia serwera w ciągu ostatnich siedmiu dni są zachowywane. W oknie przechowywania kopii zapasowych z siedmiu dni migawki bazy danych i kopie zapasowe dziennika transakcji są przechowywane przez ostatnie osiem dni (1 dzień przed oknem).

Koszt magazynu kopii zapasowych

Usługa Azure Database for MySQL — elastyczny serwer zapewnia do 100% aprowizowanego magazynu serwera jako magazyn 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 miejsca do magazynowania dostępnego dla kopii zapasowych serwera bez dodatkowych opłat. Jeśli dzienne użycie kopii zapasowej wynosi 25 GB, możesz mieć do 10 dni bezpłatnego magazynu kopii zapasowych. 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 w witrynie Azure Portal, aby monitorować magazyn kopii zapasowych używany przez serwer. Użyta metryka Magazyn kopii zapasowych reprezentuje sumę magazynu używanego przez wszystkie kopie zapasowe bazy danych i kopie zapasowe dzienników przechowywane na podstawie okresu przechowywania kopii zapasowych ustawionego dla serwera. Duża liczba transakcji na serwerze może powodować zwiększenie użycia magazynu kopii zapasowych niezależnie od całkowitego rozmiaru bazy danych. Magazyn kopii zapasowych używany na serwerze geograficznie nadmiarowym jest dwa razy większy niż serwer lokalnie nadmiarowy.

Podstawowym sposobem kontrolowania kosztów magazynu kopii zapasowych jest ustawienie odpowiedniego okresu przechowywania kopii zapasowych. Możesz wybrać okres przechowywania z zakresu od 1 do 35 dni.

Ważne

Kopie zapasowe z serwera bazy danych skonfigurowanego w strefie nadmiarowej konfiguracji wysokiej dostępności są wykonywane z podstawowego serwera bazy danych, ponieważ obciążenie jest minimalne w przypadku kopii zapasowych migawek.

Wyświetl dostępne pełne kopie zapasowe

Blok Kopia zapasowa i przywracanie w witrynie Azure Portal zawiera pełną listę pełnych kopii zapasowych dostępnych w dowolnym momencie. Obejmuje to automatyczne kopie zapasowe, a także kopie zapasowe na żądanie. Można użyć tego bloku, aby wyświetlić znaczniki czasu ukończenia dla wszystkich dostępnych pełnych kopii zapasowych w okresie przechowywania serwera i wykonać operacje przywracania przy użyciu tych pełnych kopii zapasowych. Lista dostępnych kopii zapasowych zawiera wszystkie pełne kopie zapasowe w okresie przechowywania, sygnaturę czasową pokazującą pomyślne ukończenie, sygnaturę czasową wskazującą, jak długo zostanie zachowana kopia zapasowa, oraz akcję przywracania.

Przywracanie

Na serwerze elastycznym usługi Azure Database for MySQL wykonanie przywracania powoduje utworzenie nowego serwera na podstawie kopii zapasowych oryginalnego serwera. 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.
  • Przywracanie geograficzne: jest dostępne tylko wtedy, gdy serwer został skonfigurowany pod kątem magazynu geograficznie nadmiarowego i umożliwia przywrócenie serwera do regionu sparowanego geograficznie lub dowolnego innego regionu pomoc techniczna platformy Azure, w którym dostępny jest serwer elastyczny.

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.

Uwaga

Serwer z obsługą wysokiej dostępności stanie się niedostępny (wysoka dostępność wyłączona) po przywróceniu zarówno do przywracania do punktu w czasie, jak i przywracania geograficznego.

Przywracanie do punktu w czasie

Na serwerze elastycznym usługi Azure Database for MySQL wykonywanie przywracania do punktu w czasie powoduje utworzenie nowego serwera z kopii zapasowych serwera elastycznego w tym samym regionie co serwer źródłowy. Jest on tworzony przy użyciu konfiguracji oryginalnego serwera dla warstwy obliczeniowej, liczby rdzeni wirtualnych, rozmiaru magazynu, okresu przechowywania kopii zapasowych i opcji nadmiarowości kopii zapasowych. Ponadto tagi i ustawienia, takie jak sieć wirtualna i zapora, są dziedziczone z serwera źródłowego. Przywrócona warstwa obliczeniowa i warstwa magazynowania serwera, konfiguracja i ustawienia zabezpieczeń można zmienić po zakończeniu przywracania.

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ść jest ustawiana na wartość domyślną SYSTEM
  • event_scheduler — w przypadku serwerów MySQL w wersji 5.7 parametr serwera jest automatycznie wyłączany po zainicjowaniu kopii zapasowej, a parametr event_scheduler event_scheduler serwera jest przywracany jako włączony po pomyślnym zakończeniu tworzenia kopii zapasowej. W programie MySQL w wersji 8.0 dla usługi Azure Database for MySQL — serwer elastyczny event_scheduler pozostaje nienaruszony podczas tworzenia kopii zapasowych. Aby zapewnić bezproblemowe operacje, zaleca się uaktualnienie serwerów MySQL 5.7 do wersji 8.0 przy użyciu uaktualnienia wersji głównej.

Przywracanie do punktu w czasie jest przydatne w wielu scenariuszach. Niektóre typowe przypadki użycia:

  • Gdy użytkownik przypadkowo usunie dane w bazie danych
  • Użytkownik odrzuca ważną tabelę lub bazę danych
  • Aplikacja użytkownika przypadkowo zastępuje dobre dane z nieprawidłowymi danymi z powodu wady aplikacji.

Możesz wybrać między najnowszym punktem przywracania, niestandardowym punktem przywracania i najszybszym punktem przywracania (przywracanie przy użyciu pełnej kopii zapasowej) za pośrednictwem witryny Azure Portal.

  • Najnowszy punkt przywracania: najnowsza opcja punktu przywracania pomaga przywrócić serwer do znacznika czasu po wyzwoleniu operacji przywracania. Ta opcja jest przydatna do szybkiego przywracania serwera do najbardziej zaktualizowanego stanu.
  • Niestandardowy punkt przywracania: ta opcja umożliwia wybranie dowolnego punktu w czasie w okresie przechowywania zdefiniowanym dla tego serwera. Ta opcja jest przydatna do przywrócenia serwera w dokładnym punkcie w czasie w celu odzyskania sprawności po błędzie użytkownika.
  • Najszybszy punkt przywracania: ta opcja umożliwia użytkownikom przywrócenie serwera w najszybszym czasie w danym dniu w okresie przechowywania zdefiniowanym dla serwera. Najszybsze przywracanie jest możliwe, wybierając punkt przywracania, w którym jest ukończona pełna kopia zapasowa. Ta operacja przywracania po prostu przywraca pełną kopię zapasową migawki i nie gwarantuje przywracania ani odzyskiwania dzienników, co sprawia, że jest to szybkie. Zalecamy wybranie sygnatury czasowej pełnej kopii zapasowej, która jest większa niż najwcześniejszy punkt przywracania w czasie dla pomyślnej operacji przywracania.

Szacowany czas odzyskiwania zależy od kilku czynników, takich jak rozmiary bazy danych, rozmiar kopii zapasowej dziennika transakcji, rozmiar obliczeniowy jednostki SKU oraz czas przywracania. Odzyskiwanie dziennika transakcji jest najbardziej czasochłonną częścią procesu przywracania. Jeśli czas przywracania zostanie wybrany bliżej harmonogramu tworzenia kopii zapasowej migawki, operacje przywracania są szybsze, ponieważ aplikacja dziennika transakcji jest minimalna. Aby oszacować dokładny czas odzyskiwania serwera, zdecydowanie zalecamy przetestowanie go w środowisku, ponieważ ma zbyt wiele zmiennych specyficznych dla środowiska.

Ważne

Jeśli przywracasz wystąpienie serwera elastycznego usługi Azure Database for MySQL skonfigurowane ze strefowo nadmiarową wysoką dostępnością, przywrócony serwer jest skonfigurowany w tym samym regionie i strefie co serwer podstawowy i wdrożony jako pojedynczy serwer w trybie innej niż wysoka dostępność. Zapoznaj się z strefowo nadmiarową wysoką dostępnością dla serwera elastycznego.

Ważne

Usunięty zasób serwera elastycznego usługi Azure Database for MySQL można odzyskać w ciągu 5 dni od momentu usunięcia serwera. Aby uzyskać szczegółowy przewodnik dotyczący przywracania usuniętego serwera, 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 geograficzne

Serwer można przywrócić do sparowanego geograficznie regionu, w którym usługa jest dostępna, jeśli skonfigurowano serwer na potrzeby geograficznie nadmiarowych kopii zapasowych lub dowolnego innego regionu pomoc techniczna platformy Azure, w którym jest dostępny serwer elastyczny usługi Azure Database for MySQL. Możliwość przywracania do dowolnego nie sparowanego regionu pomoc techniczna platformy Azure (z wyjątkiem Brazil South, USGov Virginia i West US 3) jest nazywana "uniwersalnym przywracaniem geograficznym".

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 utworzeniem kopii zapasowej a replikacją do innego regionu. To opóźnienie może potrwać do godziny, więc jeśli wystąpi awaria, może wystąpić do jednej godziny utraty danych.

Przywracanie geograficzne można również wykonać na zatrzymanym serwerze korzystającym z interfejsu wiersza polecenia platformy Azure. Przeczytaj artykuł Restore Azure Database for MySQL Flexible Server with Azure CLI (Przywracanie serwera elastycznego usługi Azure Database for MySQL za pomocą interfejsu wiersza polecenia platformy Azure), aby dowiedzieć się więcej na temat przywracania geograficznego serwera za pomocą interfejsu wiersza polecenia platformy Azure.

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.

Uwaga

Jeśli przywracasz geograficznie wystąpienie serwera elastycznego usługi Azure Database for MySQL skonfigurowane ze strefowo nadmiarową wysoką dostępnością, przywrócony serwer jest skonfigurowany w regionie sparowanym geograficznie i tej samej strefie co serwer podstawowy i wdrożony jako pojedyncze wystąpienie serwera elastycznego usługi Azure Database for MySQL w trybie innej niż wysoka dostępność. Zapoznaj się z strefowo nadmiarową wysoką dostępnością dla usługi Azure Database for MySQL — serwer elastyczny.

Ważne

Gdy region podstawowy nie działa, nie można utworzyć serwerów geograficznie nadmiarowych w odpowiednim regionie sparowanym geograficznie, ponieważ nie można aprowizować magazynu w regionie podstawowym. Musisz poczekać, aż region podstawowy będzie w stanie aprowizować serwery geograficznie nadmiarowe w regionie sparowanym geograficznie. Po wyłączeniu regionu podstawowego nadal można przywrócić geograficznie serwer źródłowy do sparowanego geograficznie regionu, wyłączając opcję nadmiarowości geograficznej w ustawieniach obliczeniowych i magazynu Konfiguruj serwer w środowisku portalu przywracania i przywracając go jako lokalnie nadmiarowy serwer, aby zapewnić ciągłość działalności biznesowej.

Wykonywanie zadań po przywróceniu

Po przywróceniu z najnowszego punktu przywracania lub niestandardowego mechanizmu odzyskiwania punktu przywracania należy wykonać następujące zadania, aby umożliwić użytkownikom i aplikacjom tworzenie kopii zapasowej i uruchamianie:

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

Długoterminowe przechowywanie (wersja zapoznawcza)

Usługi Azure Backup i Azure Database for MySQL — elastyczny serwer stworzyły długoterminowe rozwiązanie do tworzenia kopii zapasowych klasy korporacyjnej dla wystąpień serwera elastycznego usługi Azure Database for MySQL, które przechowuje kopie zapasowe przez maksymalnie 10 lat. Przechowywanie długoterminowe można używać niezależnie lub oprócz zautomatyzowanego rozwiązania do tworzenia kopii zapasowych oferowanego przez usługę Azure Database for MySQL — elastyczny serwer, który oferuje okres przechowywania do 35 dni. Automatyczne kopie zapasowe to kopie zapasowe migawek odpowiednie do odzyskiwania operacji, szczególnie w przypadku przywracania z najnowszych kopii zapasowych. Długoterminowe kopie zapasowe ułatwiają spełnienie wymagań dotyczących zgodności i potrzeb inspekcji. Oprócz długoterminowego przechowywania rozwiązanie oferuje następujące możliwości:

  • Kopie zapasowe zaplanowane i na żądanie kontrolowane przez klienta
  • Zarządzanie wszystkimi operacjami i zadaniami związanymi z tworzeniem kopii zapasowych oraz ich monitorowanie na serwerach, grupach zasobów, lokalizacjach, subskrypcjach i dzierżawach z jednego okienka o nazwie Centrum kopii zapasowych.
  • Kopie zapasowe są przechowywane w oddzielnych domenach zabezpieczeń i błędów. W przypadku naruszenia zabezpieczeń serwera źródłowego lub subskrypcji kopie zapasowe pozostaną bezpieczne w magazynie kopii zapasowych (na zarządzanych kontach magazynu usługi Azure Backup).

Ograniczenia i istotne zagadnienia

  • W wersji zapoznawczej przywracanie LTR jest obecnie dostępne jako RestoreasFiles na kontach magazynu. Funkcja RestoreasServer zostanie dodana w przyszłości.
  • Obsługa tworzenia LTR i zarządzania nimi za pośrednictwem interfejsu wiersza polecenia platformy Azure nie jest obecnie obsługiwana.

Aby uzyskać więcej informacji na temat wykonywania długoterminowych kopii zapasowych, odwiedź przewodnik z instrukcjami

Tworzenie i eksportowanie kopii zapasowych na żądanie (wersja zapoznawcza)

Usługa Azure Database for MySQL — elastyczny serwer oferuje teraz możliwość wyzwalania fizycznej kopii zapasowej serwera na żądanie i eksportowania go do konta usługi Azure Storage (Azure Blob Storage). Po wyeksportowaniu te kopie zapasowe mogą być używane do odzyskiwania, migracji i nadmiarowości danych. Te wyeksportowane fizyczne pliki kopii zapasowej mogą służyć do przywracania z powrotem do lokalnego serwera MySQL, aby ułatwić spełnienie wymagań inspekcji/zgodności/archiwizacji organizacji. Ta funkcja jest obecnie dostępna w publicznej wersji zapoznawczej i dostępna tylko w regionach chmury publicznej.

Aby uzyskać więcej informacji na temat eksportowania kopii zapasowej, odwiedź przewodnik z instrukcjami

Często zadawane pytania (FAQ)

  • Jak mogę utworzyć kopię zapasową serwera?

    Domyślnie usługa Azure Database for MySQL — elastyczny serwer umożliwia automatyczne tworzenie kopii zapasowych całego serwera (obejmujące wszystkie utworzone bazy danych) z domyślnym 7-dniowym okresem przechowywania. Możesz również wyzwolić ręczną kopię zapasową przy użyciu funkcji tworzenia kopii zapasowej na żądanie. Innym sposobem ręcznego tworzenia kopii zapasowej jest użycie narzędzi społeczności, takich jak mysqldump, jak opisano tutaj lub mydumper, jak opisano tutaj. Jeśli chcesz utworzyć kopię zapasową wystąpienia serwera elastycznego usługi Azure Database for MySQL w usłudze Blob Storage, zapoznaj się z naszym blogiem społeczności technicznej Tworzenie kopii zapasowej usługi Azure Database for MySQL — elastyczny serwer do usługi Blob Storage.

  • Czy można skonfigurować automatyczne kopie zapasowe do przechowywania przez długi czas?

    Nie, obecnie obsługujemy tylko maksymalnie 35 dni automatycznego przechowywania kopii zapasowych. Możesz wykonać ręczne kopie zapasowe i użyć ich w przypadku wymagań dotyczących przechowywania długoterminowego.

  • Jakie są okna kopii zapasowej serwera? Czy mogę go dostosować?

    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. Okna tworzenia kopii zapasowych są z natury zarządzane przez platformę Azure i nie można ich dostosowywać.

  • Czy moje kopie zapasowe są szyfrowane?

    Wszystkie dane serwera elastycznego usługi Azure Database for MySQL, kopie zapasowe i pliki tymczasowe utworzone podczas wykonywania zapytania są szyfrowane przy użyciu 256-bitowego szyfrowania AES. Szyfrowanie magazynu jest zawsze włączone i nie można go wyłączyć.

  • Czy mogę przywrócić jedną/kilka baz danych?

    Przywracanie jednej/kilku baz danych lub tabel nie jest obsługiwane. Jeśli chcesz przywrócić określone bazy danych, wykonaj przywracanie do punktu w czasie, a następnie wyodrębnij potrzebne tabele lub bazy danych.

  • Czy mój serwer jest dostępny w oknie tworzenia kopii zapasowej?

    Tak. Kopie zapasowe to operacje online i są oparte na migawkach. Operacja migawki trwa tylko kilka sekund i nie zakłóca obciążeń produkcyjnych, zapewniając wysoką dostępność serwera.

  • Czy podczas konfigurowania okna obsługi serwera należy uwzględnić okno tworzenia kopii zapasowej?

    Nie, kopie zapasowe są wyzwalane wewnętrznie w ramach usługi zarządzanej i nie mają wpływu na okno obsługi zarządzanej.

  • Gdzie są przechowywane automatyczne kopie zapasowe i jak mogę zarządzać ich przechowywaniem?

    Serwer elastyczny usługi Azure Database for MySQL automatycznie tworzy kopie zapasowe serwera i przechowuje je w magazynie skonfigurowanym przez użytkownika, lokalnie nadmiarowym lub w magazynie geograficznie nadmiarowym. Tych plików kopii zapasowych nie można eksportować. Domyślny okres przechowywania kopii zapasowych wynosi siedem dni. Opcjonalnie możesz skonfigurować kopię zapasową bazy danych z zakresu od 1 do 35 dni.

  • Jak mogę zweryfikować kopie zapasowe?

    Najlepszym sposobem weryfikacji dostępności pomyślnie ukończonych kopii zapasowych jest wyświetlenie pełnych automatycznych kopii zapasowych wykonanych w okresie przechowywania w bloku Tworzenie kopii zapasowych i przywracanie. Jeśli tworzenie kopii zapasowej zakończy się niepowodzeniem, nie zostanie wyświetlona na liście dostępnych kopii zapasowych, a usługa kopii zapasowej spróbuje co 20 minut, aby wykonać kopię zapasową do momentu pomyślnego utworzenia kopii zapasowej. Te błędy tworzenia kopii zapasowych są spowodowane dużymi obciążeniami produkcyjnymi transakcyjnymi na serwerze.

  • Gdzie mogę zobaczyć użycie kopii zapasowej?

    W witrynie Azure Portal na karcie Monitorowanie — Metryki znajduje się metryka Użyta usługa Backup Storage, która może pomóc w monitorowaniu całkowitego użycia kopii zapasowych.

  • Co się stanie z moimi kopiami zapasowymi w przypadku usunięcia serwera?

    Jeśli usuniesz serwer, wszystkie kopie zapasowe należące do tego serwera zostaną również usunięte i nie będzie można ich odzyskać. Aby chronić zasoby serwera po wdrożeniu przed przypadkowym usunięciem lub nieoczekiwanymi zmianami, administratorzy mogą używać blokad zarządzania.

  • Co się stanie z moimi kopiami zapasowymi po przywróceniu serwera?

    Jeśli przywracasz serwer, zawsze powoduje utworzenie nowego serwera sieci, który został przywrócony przy użyciu kopii zapasowych oryginalnego serwera. Stara kopia zapasowa z oryginalnego serwera nie jest kopiowana na nowo przywrócony serwer i pozostaje z oryginalnym serwerem. Jednak w przypadku nowo utworzonego serwera pierwsza kopia zapasowa migawki jest zaplanowana natychmiast po utworzeniu serwera, a usługa zapewnia wykonywanie codziennych automatycznych kopii zapasowych i przechowywanie ich zgodnie ze skonfigurowanym okresem przechowywania serwera.

  • Jak są naliczane opłaty i naliczane opłaty za korzystanie z kopii zapasowych?

    Usługa Azure Database for MySQL — elastyczny serwer zapewnia do 100% aprowizowanego magazynu serwera jako magazyn kopii zapasowych bez dodatkowych kosztów. Opłaty za użycie magazynu kopii zapasowych są naliczane w GB miesięcznie zgodnie z modelem cenowym. Rozliczanie magazynu kopii zapasowych jest również zależne od wybranego okresu przechowywania kopii zapasowych i wybranej opcji nadmiarowości kopii zapasowych, oprócz działań transakcyjnych na serwerze, co ma wpływ na łączną ilość używanego bezpośrednio magazynu kopii zapasowych.

  • W jaki sposób kopie zapasowe są przechowywane dla zatrzymanych serwerów?

    Dla zatrzymanych serwerów nie są wykonywane żadne nowe kopie zapasowe. Wszystkie starsze kopie zapasowe (w oknie przechowywania) w momencie zatrzymania serwera są zachowywane do czasu ponownego uruchomienia serwera, po którym przechowywanie kopii zapasowej dla aktywnego serwera jest zarządzane przez okno przechowywania kopii zapasowych.

  • Jak będą naliczane opłaty za kopie zapasowe zatrzymanego serwera?

    Podczas zatrzymywania wystąpienia serwera są naliczane opłaty za aprowizowany magazyn (w tym aprowizowane operacje we/wy na sekundę) i magazyn kopii zapasowych (kopie zapasowe przechowywane w określonym oknie przechowywania). Bezpłatny magazyn kopii zapasowych jest ograniczony do rozmiaru aprowizowanej bazy danych i dotyczy tylko aktywnych serwerów.

  • Jak są chronione moje dane kopii zapasowej?

    Usługa Azure Database for MySQL — elastyczny serwer chroni dane kopii zapasowej, blokując wszelkie operacje, które mogą prowadzić do utraty punktów odzyskiwania przez czas trwania skonfigurowanego okresu przechowywania. Kopie zapasowe wykonywane w okresie przechowywania mogą być odczytywane tylko w celu przywrócenia i są usuwane po okresie przechowywania. Ponadto wszystkie kopie zapasowe w usłudze Azure Database for MySQL — elastyczny serwer są szyfrowane przy użyciu 256-bitowego szyfrowania AES dla danych przechowywanych w spoczynku.

  • Jak operacja przywracania do punktu w czasie (PITR) wpływa na użycie operacji we/wy na sekundę?

    Podczas operacji pitr w usłudze Azure Database for MySQL — serwer elastyczny jest tworzony, a dane są kopiowane z magazynu serwera źródłowego do magazynu nowego serwera. Ten proces powoduje zwiększenie użycia operacji we/wy na sekundę na serwerze źródłowym. Ten wzrost użycia operacji we/wy na sekundę jest normalnym wystąpieniem i nie wskazuje żadnych problemów z serwerem źródłowym ani operacją PITR. Po zakończeniu operacji PITR użycie operacji we/wy na sekundę na serwerze źródłowym powróci do zwykłych poziomów.

  • Jak mogę przywrócić mój serwer? Witryna Azure Portal obsługuje przywracanie do punktu w czasie dla wszystkich serwerów, co umożliwia użytkownikom przywracanie do najnowszych lub niestandardowych punktów przywracania. Aby ręcznie przywrócić serwer z kopii zapasowych wykonanych przez narzędzie mysqldump/myDumper, zobacz Przywracanie bazy danych przy użyciu narzędzia myLoader.

  • Dlaczego przywracanie trwa tyle czasu?

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

    • Rozmiar baz danych. W ramach procesu odzyskiwania baza danych musi być nawodniona z ostatniej fizycznej kopii zapasowej, dlatego czas potrzebny do odzyskania będzie proporcjonalny do rozmiaru bazy danych.
    • Aktywna część działania transakcji, która musi zostać odtworzona w celu odzyskania. Odzyskiwanie może trwać dłużej w zależności od dodanego działania transakcji z ostatniego pomyślnego punktu kontrolnego.
    • Przepustowość sieci, jeśli przywracanie jest przeprowadzane do innego regionu.
    • Liczba współbieżnych żądań przywracania przetwarzanych w regionie docelowym.
    • Obecność kluczy podstawowych w tabelach w bazie danych. Aby przyspieszyć odzyskiwanie, rozważ dodanie kluczy podstawowych dla wszystkich tabel w bazie danych.

  • Czy modyfikowanie zmiennych bazy danych na poziomie sesji będzie miało wpływ na przywrócenie?

    Modyfikowanie zmiennych na poziomie sesji i uruchamianie instrukcji DML w sesji klienta MySQL może mieć wpływ na operację przywracania do punktu w czasie (do punktu w czasie), ponieważ te modyfikacje nie są rejestrowane w dzienniku binarnym używanym do operacji tworzenia kopii zapasowej i przywracania. Na przykład foreign_key_checks są jedną z takich zmiennych na poziomie sesji, która jeśli jest wyłączona na potrzeby uruchamiania instrukcji DML, która narusza ograniczenie klucza obcego powoduje niepowodzenie przywracania do punktu w czasie (punkt w czasie). Jedynym obejściem w takim scenariuszu byłoby wybranie czasu pitr wcześniej niż czas, w którym foreign_key_checks zostały wyłączone. Zalecamy, aby nie modyfikować żadnych zmiennych sesji dla pomyślnej operacji PITR.

Następne kroki