Omówienie usługi ponownego odtwarzania dzienników za pomocą usługi Azure SQL Managed Instance

  • Artykuł

Dotyczy:Azure SQL Managed Instance

Ten artykuł zawiera omówienie usługi ponownego odtwarzania dzienników (LRS), której można użyć do migrowania baz danych z programu SQL Server do usługi Azure SQL Managed Instance. LRS to bezpłatna usługa w chmurze dostępna dla usługi Azure SQL Managed Instance i oparta na technologii wysyłania dzienników programu SQL Server.

Aby rozpocząć, zapoznaj się z artykułem Migrowanie baz danych z programu SQL Server do usługi Azure SQL Managed Instance przy użyciu usługi ponownego odtwarzania dziennika.

Kiedy używać usługi ponownego odtwarzania dzienników

Usługa Azure Database Migration Service, rozszerzenie migracji usługi Azure SQL dla programu Azure Data Studio i magazyn LRS używają tej samej podstawowej technologii migracji i interfejsów API. Magazyn LRS dodatkowo umożliwia złożone migracje niestandardowe i architektury hybrydowe między lokalnymi wystąpieniami programu SQL Server i wdrożeniami usługi SQL Managed Instance.

Jeśli nie możesz użyć usługi Azure Database Migration Service lub rozszerzenia Azure SQL do migracji, możesz użyć magazynu LRS bezpośrednio z programem PowerShell, poleceniami cmdlet interfejsu wiersza polecenia platformy Azure lub interfejsami API, aby ręcznie skompilować i zorganizować migracje baz danych do usługi SQL Managed Instance.

Rozważ użycie magazynu LRS w następujących przypadkach, gdy:

  • Potrzebujesz większej kontroli nad projektem migracji bazy danych.
  • Brak tolerancji dla przestojów podczas migracji jednorazowej.
  • Nie można zainstalować pliku wykonywalnego usługi Database Migration Service w środowisku.
  • Plik wykonywalny usługi Database Migration Service nie ma dostępu do plików kopii zapasowych bazy danych.
  • Nie można zainstalować rozszerzenia migracji usługi Azure SQL do środowiska lub nie może uzyskać dostępu do kopii zapasowych bazy danych.
  • Brak dostępu do systemu operacyjnego hosta lub brak uprawnień administratora.
  • Nie można otwierać portów sieciowych ze środowiska do platformy Azure.
  • Ograniczanie przepustowości sieci lub problemy z blokowaniem serwera proxy istnieją w twoim środowisku.
  • Kopie zapasowe są przechowywane bezpośrednio na kontach usługi Azure Blob Storage za pośrednictwem TO URL opcji .
  • Należy użyć różnicowych kopii zapasowych.

Obsługiwane są następujące źródła:

  • Program SQL Server w usłudze Virtual Machines
  • Amazon EC2 (Elastyczna chmura obliczeniowa)
  • Amazon RDS (usługa relacyjnej bazy danych) dla programu SQL Server
  • Aparat obliczeniowy Google
  • Cloud SQL for SQL Server — GCP (Google Cloud Platform)

Uwaga

  • Zalecamy zautomatyzowanie migracji baz danych z programu SQL Server do usługi Azure SQL Managed Instance przy użyciu rozszerzenia migracji usługi Azure SQL dla usługi Azure Data Studio. Rozważ użycie magazynu LRS do organizowania migracji, gdy rozszerzenie migracji usługi Azure SQL nie obsługuje w pełni Twoich scenariuszy.
  • Magazyn LRS to jedyna metoda przywracania różnicowych kopii zapasowych w wystąpieniach zarządzanych. Nie można ręcznie przywrócić różnicowych kopii zapasowych w wystąpieniach zarządzanych ani ręcznie ustawić NORECOVERY trybu przy użyciu języka T-SQL.

Jak działa magazyn LRS

Utworzenie niestandardowego rozwiązania do migrowania baz danych do chmury przy użyciu magazynu LRS wymaga kilku kroków aranżacji, jak pokazano na diagramie i tabeli w dalszej części tej sekcji.

Migracja polega na utworzeniu kopii zapasowych bazy danych w programie SQL Server i skopiowaniu plików kopii zapasowych na konto usługi Azure Blob Storage. Obsługiwane są pełne i różnicowe kopie zapasowe oraz kopie zapasowe dziennika. Następnie użyjesz usługi LRS w chmurze, aby przywrócić pliki kopii zapasowej z konta usługi Azure Blob Storage do usługi SQL Managed Instance. Konto usługi Blob Storage służy jako pośredni magazyn dla plików kopii zapasowych między programem SQL Server i usługą SQL Managed Instance.

Magazyn LRS monitoruje konto usługi Blob Storage pod kątem wszelkich nowych kopii zapasowych różnicowych lub kopii zapasowych dziennika, które są dodawane po przywróceniu pełnej kopii zapasowej. Następnie usługa LRS automatycznie przywraca te nowe pliki. Za pomocą usługi można monitorować postęp plików kopii zapasowych, które są przywracane do usługi SQL Managed Instance, i w razie potrzeby zatrzymać proces.

Usługa LRS nie wymaga określonej konwencji nazewnictwa plików kopii zapasowych. Skanuje wszystkie pliki umieszczone na koncie usługi Azure Blob Storage i konstruuje łańcuch kopii zapasowych tylko z odczytywania nagłówków plików. Podczas migracji bazy danych są w stanie przywracania. Bazy danych są przywracane w trybie NORECOVERY , więc nie można ich używać do obciążeń odczytu lub zapisu do momentu zakończenia procesu migracji.

Jeśli migrujesz kilka baz danych, należy wykonać następujące kroki:

  • Umieść pliki kopii zapasowej dla każdej bazy danych w osobnym folderze na koncie usługi Blob Storage w strukturze prostego pliku. Na przykład użyj oddzielnych folderów bazy danych: blobcontainer/database1/files, blobcontainer/database2/files itd.
  • Nie używaj zagnieżdżonych folderów wewnątrz folderów bazy danych, ponieważ struktura zagnieżdżonych folderów nie jest obsługiwana. Na przykład nie używaj podfolderów, takich jak blobcontainer/database1/subfolder/files.
  • Uruchom usługę LRS oddzielnie dla każdej bazy danych.
  • Określ różne ścieżki identyfikatora URI, aby oddzielić foldery bazy danych na koncie usługi Blob Storage.

Mimo że CHECKSUM włączenie obsługi kopii zapasowych nie jest wymagane, zdecydowanie zalecamy. Przywracanie baz danych bez CHECKSUM dłuższego czasu, ponieważ usługa SQL Managed Instance przeprowadza sprawdzanie integralności na kopiach zapasowych, które są przywracane bez CHECKSUM włączenia.

Aby uzyskać więcej informacji, zobacz Migrowanie baz danych z programu SQL Server do usługi SQL Managed Instance przy użyciu usługi ponownego odtwarzania dziennika.

Uwaga

Wykonywanie kopii zapasowych w programie SQL Server z CHECKSUM włączoną obsługą jest zdecydowanie zalecane, ponieważ istnieje ryzyko przywrócenia uszkodzonej bazy danych na platformie Azure bez niej. 

Autouzupełnianie a migracja w trybie ciągłym

Magazyn LRS można uruchomić w trybie autouzupełniania lub ciągłego .

Użyj trybu autouzupełniania , gdy cały łańcuch kopii zapasowych został wygenerowany z wyprzedzeniem, a gdy nie planujesz dodawania kolejnych plików po rozpoczęciu migracji. Ten tryb migracji jest zalecany w przypadku obciążeń pasywnych, które nie wymagają nadrobienia zaległości danych. Przekaż wszystkie pliki kopii zapasowej na konto usługi Blob Storage i uruchom migrację trybu autouzupełniania. Migracja zostanie zakończona automatycznie po przywróceniu ostatniego określonego pliku kopii zapasowej. Zmigrowana baza danych stanie się dostępna do odczytu/zapisu w usłudze SQL Managed Instance.

Jeśli planujesz nadal dodawać nowe pliki kopii zapasowej podczas migracji, użyj trybu ciągłego . Ten tryb zalecamy w przypadku aktywnych obciążeń, które wymagają nadrabiania zaległości danych. Przekaż aktualnie dostępny łańcuch kopii zapasowych do konta usługi Blob Storage, uruchom migrację w trybie ciągłym i w razie potrzeby dodaj nowe pliki kopii zapasowej z obciążenia. System okresowo skanuje folder usługi Azure Blob Storage i przywraca wszystkie znalezione pliki dziennika lub różnicowej kopii zapasowej.

Gdy wszystko będzie gotowe do migracji jednorazowej, zatrzymaj obciążenie w wystąpieniu programu SQL Server, wygeneruj ostatni plik kopii zapasowej, a następnie przekaż go. Upewnij się, że ostatni plik kopii zapasowej został przywrócony, sprawdzając, czy końcowa kopia zapasowa dziennika jest wyświetlana jako przywrócona w usłudze SQL Managed Instance. Następnie zainicjuj ręczną migrację jednorazową. Ostatni krok migracji jednorazowej sprawia, że baza danych jest dostępna w trybie online i jest dostępna do odczytu/zapisu w usłudze SQL Managed Instance.

Po zatrzymaniu magazynu LRS automatycznie za pośrednictwem autouzupełniania lub ręcznie przez migrację jednorazową nie można wznowić procesu przywracania bazy danych, która została przeniesiona w tryb online w usłudze SQL Managed Instance. Na przykład po zakończeniu migracji nie można już przywrócić większej liczby różnicowych kopii zapasowych dla bazy danych online. Aby przywrócić więcej plików kopii zapasowych po zakończeniu migracji, musisz usunąć bazę danych z wystąpienia zarządzanego i ponownie uruchomić migrację od początku.

Przepływ pracy migracji

Typowy przepływ pracy migracji przedstawiono na poniższej ilustracji, a kroki zostały opisane w tabeli.

Należy użyć trybu autouzupełniania tylko wtedy, gdy wszystkie pliki łańcucha kopii zapasowych są dostępne z wyprzedzeniem. Zalecamy ten tryb dla obciążeń pasywnych, dla których nie jest wymagany nadrabianie zaległości danych.

Użyj migracji w trybie ciągłym, jeśli nie masz z wyprzedzeniem całego łańcucha kopii zapasowych, a gdy planujesz dodać nowe pliki kopii zapasowej po zakończeniu migracji. Zalecamy ten tryb dla aktywnych obciążeń, dla których jest wymagany nadrabianie zaległości danych.

Diagram ilustrujący kroki aranżacji usługi Replay Service dla usługi SQL Managed Instance.

Działanie Details
1. Skopiuj kopie zapasowe bazy danych z wystąpienia programu SQL Server do konta usługi Blob Storage. Skopiuj pełne, różnicowe i dziennika kopie zapasowe z wystąpienia programu SQL Server do kontenera usługi Blob Storage przy użyciu narzędzia AzCopy lub Eksplorator usługi Azure Storage.

Użyj dowolnych nazw plików. Magazyn LRS nie wymaga określonej konwencji nazewnictwa plików.

Użyj oddzielnego folderu dla każdej bazy danych podczas migracji kilku baz danych.
2. Uruchom magazyn LRS w chmurze. Usługę można uruchomić za pomocą programu PowerShell (start-azsqlinstancedatabaselogreplay) lub interfejsu wiersza polecenia platformy Azure (az_sql_midb_log_replay_start poleceń cmdlet). Wybierz tryb autouzupełniania lub ciągłej migracji.

Uruchom magazyn LRS oddzielnie dla każdej bazy danych wskazującej folder kopii zapasowej na koncie usługi Blob Storage.

Po uruchomieniu usługi wykonuje kopie zapasowe z kontenera usługi Blob Storage i rozpoczyna przywracanie ich do usługi SQL Managed Instance.

Po uruchomieniu magazynu LRS w trybie autouzupełniania przywraca wszystkie kopie zapasowe za pomocą określonego ostatniego pliku kopii zapasowej. Wszystkie pliki kopii zapasowej muszą zostać przekazane z wyprzedzeniem i nie można dodać żadnych nowych plików kopii zapasowych, gdy migracja jest w toku. Ten tryb jest zalecany dla obciążeń pasywnych, w przypadku których nie jest wymagane nadrabianie zaległości danych.

Gdy magazyn LRS jest uruchamiany w trybie ciągłym, przywraca wszystkie kopie zapasowe, które zostały początkowo przekazane, a następnie obserwuje wszystkie nowe pliki, które zostały przekazane do folderu. Usługa stale stosuje dzienniki na podstawie łańcucha numerów sekwencji dzienników (LSN), dopóki nie zostanie zatrzymana ręcznie. Zalecamy ten tryb dla aktywnych obciążeń, dla których jest wymagany nadrabianie zaległości danych.
2.1. Monitorowanie postępu operacji. Postęp operacji przywracania można monitorować za pomocą programu PowerShell (get-azsqlinstancedatabaselogreplay) lub interfejsu wiersza polecenia platformy Azure (az_sql_midb_log_replay_show poleceń cmdlet).
2.2. Zatrzymaj operację, jeśli jest to wymagane (opcjonalnie). Jeśli musisz zatrzymać proces migracji, użyj programu PowerShell (stop-azsqlinstancedatabaselogreplay) lub interfejsu wiersza polecenia platformy Azure (az_sql_midb_log_replay_stop).

Zatrzymanie operacji powoduje usunięcie bazy danych, którą przywracasz do usługi SQL Managed Instance. Po zatrzymaniu operacji nie można wznowić magazynu LRS dla bazy danych. Musisz ponownie uruchomić proces migracji od początku.
3. Wyciąć się do chmury, gdy wszystko będzie gotowe. Jeśli magazyn LRS został uruchomiony w trybie autouzupełniania, migracja zostanie automatycznie zakończona po przywróceniu określonego ostatniego pliku kopii zapasowej.

Jeśli magazyn LRS został uruchomiony w trybie ciągłym, zatrzymaj aplikację i obciążenie. Wykonaj ostatnią kopię zapasową zaplecza dziennika i przekaż ją do wdrożenia usługi Azure Blob Storage. Upewnij się, że ostatnia kopia zapasowa dziennika została przywrócona w wystąpieniu zarządzanym. Wykonaj migrację jednorazową, inicjując operację LRS complete za pomocą programu PowerShell (complete-azsqlinstancedatabaselogreplay) lub interfejsu wiersza polecenia platformy Azure az_sql_midb_log_replay_complete. Ta operacja zatrzymuje magazyn LRS i przenosi bazę danych w tryb online na potrzeby obciążeń odczytu/zapisu w usłudze SQL Managed Instance.

Ponownie należy wskazać parametry połączenia aplikacji z wystąpienia programu SQL Server na wystąpienie zarządzane SQL. Musisz samodzielnie zorganizować ten krok za pomocą ręcznej parametry połączenia zmiany w aplikacji lub automatycznie (na przykład jeśli aplikacja może odczytać parametry połączenia z właściwości lub bazy danych).

Migrowanie dużych baz danych

W przypadku migrowania dużych baz danych o rozmiarze kilku terabajtów należy wziąć pod uwagę następujące kwestie:

  • Pojedyncze zadanie LRS może być uruchamiane przez maksymalnie 30 dni. Po wygaśnięciu tego okresu zadanie zostanie automatycznie anulowane.
  • W przypadku długotrwałych zadań aktualizacje systemu przerywają i przedłużają zadania migracji. Zdecydowanie zalecamy użycie okna obsługi do zaplanowanych aktualizacji systemu. Zaplanuj migrację w zaplanowanym oknie obsługi.
  • Zadania migracji przerywane przez aktualizacje systemu są automatycznie zawieszane i wznawiane dla wystąpień zarządzanych ogólnego przeznaczenia i są uruchamiane ponownie dla wystąpień zarządzanych Krytyczne dla działania firmy. Te aktualizacje będą mieć wpływ na przedział czasu migracji.
  • Aby zwiększyć szybkość przekazywania plików kopii zapasowych programu SQL Server do konta usługi Blob Storage, jeśli infrastruktura ma wystarczającą przepustowość sieci, rozważ użycie równoległości z wieloma wątkami.

Rozpoczynanie migracji

Migrację należy rozpocząć, uruchamiając magazyn LRS. Usługę można uruchomić w trybie autouzupełniania lub ciągłym. Aby uzyskać szczegółowe informacje, zobacz Migrowanie za pomocą magazynu LRS.

  • Tryb autouzupełniania. W przypadku korzystania z trybu autouzupełniania migracja zostanie zakończona automatycznie po przywróceniu ostatniej z określonych plików kopii zapasowej. Ta opcja:

    • Wymaga wcześniejszego udostępnienia całego łańcucha kopii zapasowych i przekazania go do konta usługi Azure Blob Storage.
    • Nie zezwala na dodawanie nowych plików kopii zapasowej, gdy migracja jest w toku.
    • Wymaga polecenia start, aby określić nazwę pliku ostatniej kopii zapasowej.

    Zalecamy używanie trybu autouzupełniania dla obciążeń pasywnych, dla których zaległości danych nie są wymagane.

  • Tryb ciągły. Gdy używasz trybu ciągłego, usługa stale skanuje folder usługi Azure Blob Storage i przywraca wszystkie nowe pliki kopii zapasowej, które są dodawane podczas migracji w toku.

    Migracja kończy się dopiero po zażądaniu ręcznego przejścia jednorazowego.

    Należy użyć migracji w trybie ciągłym, gdy nie masz z wyprzedzeniem całego łańcucha kopii zapasowych, a gdy planujesz dodać nowe pliki kopii zapasowej po zakończeniu migracji.

    Zalecamy używanie trybu ciągłego dla aktywnych obciążeń, dla których wymagane jest nadrabianie zaległości danych.

Zaplanuj ukończenie pojedynczego zadania migracji LRS w ciągu maksymalnie 30 dni. Po wygaśnięciu tego okresu zadanie LRS zostanie automatycznie anulowane.

Uwaga

Podczas migrowania wielu baz danych magazyn LRS musi być uruchamiany oddzielnie dla każdej bazy danych wskazującej pełną ścieżkę identyfikatora URI kontenera usługi Azure Blob Storage i pojedynczego folderu bazy danych.

Ograniczenia usługi LRS

Rozważ następujące ograniczenia magazynu LRS:

  • Magazyn LRS obsługuje tylko bazy danych .bak, .logi .diff pliki. Pliki Dacpac i bacpac nie są obsługiwane.
  • Podczas procesu migracji migrowane bazy danych nie mogą być używane do dostępu tylko do odczytu w usłudze SQL Managed Instance.
  • Należy skonfigurować okno obsługi, aby umożliwić planowanie aktualizacji systemu w określonym dniu i o określonej godzinie. Zaplanuj uruchamianie i kończenie migracji poza zaplanowanym oknem obsługi.
  • Kopie zapasowe bazy danych, które są wykonywane bez CHECKSUM konieczności przywracania dłużej niż kopie zapasowe bazy danych z włączoną obsługą CHECKSUM .
  • Token sygnatury dostępu współdzielonego (SAS), którego używa LRS, musi być generowany dla całego kontenera usługi Azure Blob Storage i musi mieć tylko uprawnienia do odczytu i listy. Jeśli na przykład przyznasz uprawnienia odczyt, lista i zapis, magazyn LRS nie będzie mógł uruchomić się z powodu dodatkowych uprawnień do zapisu.
  • Używanie tokenów SAS utworzonych z uprawnieniami ustawionymi za pomocą definiowania przechowywanych zasad dostępu nie jest obsługiwane. Postępuj zgodnie z instrukcjami w tym artykule, aby ręcznie określić uprawnienia odczyt i lista dla tokenu SAS.
  • Pliki kopii zapasowych dla różnych baz danych należy umieścić w osobnych folderach na koncie usługi Blob Storage w strukturze plików prostych. Zagnieżdżanie folderów wewnątrz folderów bazy danych nie jest obsługiwane.
  • Jeśli używasz trybu autouzupełniania, cały łańcuch kopii zapasowych musi być dostępny z wyprzedzeniem na koncie usługi Blob Storage. Nie można dodać nowych plików kopii zapasowej w trybie autouzupełniania. Użyj trybu ciągłego, jeśli chcesz dodać nowe pliki kopii zapasowej podczas migracji w toku.
  • Musisz uruchomić magazyn LRS oddzielnie dla każdej bazy danych, która wskazuje pełną ścieżkę identyfikatora URI zawierającą pojedynczy folder bazy danych.
  • Ścieżka identyfikatora URI kopii zapasowej, nazwa kontenera lub nazwy folderów nie powinny zawierać backup ani backups , ponieważ są to zastrzeżone słowa kluczowe.
  • Podczas równoległego uruchamiania wielu operacji ponownego odtwarzania dziennika dla tego samego kontenera magazynu upewnij się, że dla każdej operacji przywracania jest udostępniany ten sam prawidłowy token SAS.
  • Magazyn LRS może obsługiwać maksymalnie 100 równoczesnych procesów przywracania na pojedyncze wystąpienie zarządzane.
  • Pojedyncze zadanie LRS można uruchomić przez maksymalnie 30 dni, po którym zostanie automatycznie anulowane.
  • Chociaż możliwe jest użycie konta usługi Azure Storage za zaporą, wymagana jest dodatkowa konfiguracja, a konto magazynu i wystąpienie zarządzane muszą znajdować się w tym samym regionie lub w dwóch sparowanych regionach. Zapoznaj się z artykułem Konfigurowanie zapory , aby dowiedzieć się więcej.
  • Maksymalna liczba baz danych, które można przywrócić równolegle, wynosi 200 na jedną subskrypcję. W niektórych przypadkach można zwiększyć ten limit, otwierając bilet pomocy technicznej.

Napiwek

Jeśli chcesz, aby baza danych była dostępna tylko do odczytu podczas migracji, z znacznie dłuższym przedziałem czasu na przeprowadzenie migracji i minimalnym przestojem, rozważ użycie funkcji linku usługi Azure SQL Managed Instance jako zalecanego rozwiązania do migracji.

Następne kroki