Udostępnij za pośrednictwem

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.

Ponieważ magazyn LRS przywraca standardowe pliki kopii zapasowych programu SQL Server, można go użyć do migracji z programu SQL Server hostowanego w dowolnym miejscu (lokalnie lub w dowolnej chmurze) do usługi Azure SQL Managed Instance.

Aby rozpocząć migrację przy użyciu usługi LRS, zapoznaj się z artykułem Migrowanie baz danych przy użyciu Log Replay Service.

Ważne

Przed migracją baz danych do warstwy usługi Krytyczne dla działania firmy należy wziąć pod uwagę te ograniczenia, które nie mają zastosowania do warstwy usługi Ogólnego przeznaczenia.

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

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

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

Rozważ użycie 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.

Ponieważ LRS działa przy przywracaniu standardowych plików kopii zapasowych programu SQL Server, powinien obsługiwać migracje z dowolnego źródła. Przetestowano następujące źródła:

  • Lokalna/skrzynka programu SQL Server
  • Program SQL Server w usłudze Virtual Machines
  • Amazon EC2 (Elastyczna chmura obliczeniowa)
  • Amazon RDS (usługa relacyjnej bazy danych) dla programu SQL Server
  • Google Compute Engine
  • Cloud SQL for SQL Server — GCP (Google Cloud Platform)
  • Alibaba Cloud RDS dla SQL Servera

Jeśli wystąpią nieoczekiwane problemy z migracją z niewymienionego źródła, zgłoś problem do działu wsparcia technicznego, aby uzyskać pomoc.

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 LRS do koordynowania migracji, gdy rozszerzenie migracji Azure SQL nie w pełni wspiera twoje scenariusze.
  • LRS to jedyna metoda przywracania różnicowych kopii zapasowych na zarządzanych instancjach. Nie można ręcznie przywrócić różnicowych kopii zapasowych w wystąpieniach zarządzanych, ani ręcznie ustawić trybu NORECOVERY przy użyciu T-SQL.

Jak działa LRS

Utworzenie niestandardowego rozwiązania do migrowania baz danych do chmury z użyciem LRS wymaga kilku etapów koordynacji, 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.

LRS monitoruje konto Blob Storage w poszukiwaniu nowych różnicowych lub dziennikowych kopii zapasowych, 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 URI, aby rozdzielić foldery bazy danych na koncie usługi Blob Storage.

Chociaż nie jest konieczne włączenie obsługi kopii zapasowych w CHECKSUM, zdecydowanie to zalecamy. Przywracanie baz danych bez CHECKSUM trwa dłużej, ponieważ usługa SQL Managed Instance przeprowadza kontrolę integralności kopii zapasowych przywracanych bez włączenia CHECKSUM.

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 SQL Server z włączonym CHECKSUM jest zdecydowanie zalecane, ponieważ istnieje ryzyko przywrócenia uszkodzonej bazy danych na platformie Azure bez jego użycia.

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

Można uruchomić LRS w trybie autouzupełniania lub ciągłym.

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 będzie okresowo skanować folder usługi Azure Blob Storage i przywracać wszystkie nowe pliki dziennika lub różnicowej kopii zapasowej, które znajdzie.

Gdy będziesz gotowy do przełączenia, zatrzymaj operacje w instancji SQL Server, wygeneruj ostatni plik kopii zapasowej, a następnie go przekaż. 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ęczne przejście. Ostatni etap przejścia sprawia, że baza danych zostaje uruchomiona i jest dostępna do odczytu/zapisu w usłudze SQL Managed Instance.

Po zatrzymaniu magazynu danych LRS przez autouzupełnianie lub ręcznie przez przycisk zatrzymania, nie można wznowić procesu odtwarzania bazy danych, która została uruchomiona w trybie online w instancji zarządzanej SQL. 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 migracji pracy

Typowy przepływ pracy migracji przedstawiono na ilustracji poniżej, a kroki opisano 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 wymagana jest synchronizacja danych.

Diagram ilustrujący etapy orkiestracji usługi Log Replay Service dla SQL Managed Instance.

Działanie Szczegóły
1. Skopiuj kopie zapasowe bazy danych z wystąpienia programu SQL Server do konta usługi Blob Storage. Skopiuj pełne, różnicowe i kopie zapasowe dziennika z wystąpienia programu SQL Server do kontenera usługi Blob Storage za pomocą AzCopy lub Eksplorator usługi Azure Storage.

Użyj dowolnych nazw plików. 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 LRS w chmurze. Usługę można uruchomić za pomocą programu PowerShell (start-azsqlinstancedatabaselogreplay) lub Azure CLI (cmdlet az_sql_midb_log_replay_start). Wybierz tryb autouzupełniania lub ciągłej migracji.

Uruchom usługę LRS oddzielnie dla każdej bazy danych, która wskazuje na 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 systemu LRS w trybie autouzupełniania przywracane są wszystkie kopie zapasowe do 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 system LRS jest uruchamiany w trybie ciągłym, przywraca wszystkie uprzednio przesłane kopie zapasowe, a następnie monitoruje nowe pliki przesłane do folderu. Usługa stale stosuje dzienniki zgodnie z łańcuchem numerów sekwencji dzienników (LSN), dopóki nie zostanie ręcznie zatrzymana. Zalecamy ten tryb dla aktywnych obciążeń, które wymagają nadrabiania zaległości danych.
2.1. Monitorowanie postępu operacji. Postęp trwającej operacji przywracania można monitorować za pomocą programu PowerShell (get-azsqlinstancedatabaselogreplay) lub Azure CLI (az_sql_midb_log_replay_show poleceń cmdlet). Aby śledzić dodatkowe szczegóły dotyczące żądania, które zakończyło się niepowodzeniem, użyj polecenia PowerShell Get-AzSqlInstanceOperation lub polecenia Azure CLI az sql mi op show.
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ć funkcji LRS dla bazy danych. Musisz ponownie uruchomić proces migracji od początku.
3. Przejdź do chmury, kiedy będziesz gotowy. Jeśli magazyn LRS został uruchomiony w trybie autouzupełniania, migracja automatycznie się zakończy po przywróceniu określonego ostatniego pliku kopii zapasowej.

Jeśli usługa LRS została uruchomiona w trybie ciągłym, zatrzymaj aplikację i procesy. Wykonaj ostatnią kopię zapasową końcowej części dziennika i przekaż ją do wdrożenia na platformie Azure Blob Storage. Upewnij się, że ostatnia kopia zapasowa dziennika została przywrócona w wystąpieniu zarządzanym. Zakończ przejście, inicjując operację LRS complete za pomocą programu PowerShell (complete-azsqlinstancedatabaselogreplay) lub narzędzia wiersza poleceń Azure CLI az_sql_midb_log_replay_complete. Ta operacja zatrzymuje LRS i przenosi bazę danych w tryb online w celu obsługi obciążeń odczytu/zapisu w instancji zarządzanej SQL.

Zmień parametry połączenia aplikacji z instancji SQL Server do zarządzanej instancji SQL. Musisz samodzielnie wykonać ten krok, poprzez ręczną zmianę parametru połączenia w aplikacji, lub automatycznie (na przykład, jeśli aplikacja może odczytać parametr połączenia z właściwości aplikacji lub bazy danych).

Ważne

Po przejściu jednorazowym wystąpienie zarządzane SQL z warstwą usługi Krytyczne dla działania firmy może trwać znacznie dłużej niż usługa Ogólnego przeznaczenia, ponieważ dla grupy dostępności muszą być rozmieszczane trzy repliki pomocnicze. Czas trwania operacji zależy od rozmiaru danych. Aby uzyskać więcej informacji, zobacz Czas trwania operacji zarządzania.

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 trwać 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 ustalonym oknie serwisowym.
  • 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

Rozpoczynasz migrację, uruchamiając LRS. Usługę można uruchomić w trybie autouzupełniania lub ciągłym. Aby uzyskać szczegółowe informacje, zobacz Migrowanie z 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 uzupełnianie danych nie jest 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 zgłoszeniu ręcznego przełączenia.

    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 upływie tego okresu, zadanie LRS zostanie anulowane automatycznie.

Uwaga

Podczas migrowania wielu baz danych każda baza danych musi znajdować się we własnym folderze. LRS musi być uruchamiany oddzielnie dla każdej bazy danych, z podaniem pełnej ścieżki URI do kontenera Azure Blob Storage oraz konkretnego folderu bazy danych. Zagnieżdżone foldery wewnątrz folderów bazy danych nie są obsługiwane.

Ograniczenia LRS

Aby uzyskać informacje, zapoznaj się z ograniczeniami dotyczącymi korzystania z magazynu LRS.

Następne kroki