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

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 magazynu LRS, zapoznaj się z artykułem Migrowanie baz danych przy użyciu usługi ponownego odtwarzania dziennika.

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 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.

Ponieważ magazyn LRS działa przez przywrócenie 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 for SQL Server

Jeśli wystąpią nieoczekiwane problemy z migracją z nieznajdującego się na liście źródłowej, otwórz bilet pomocy technicznej, 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 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.

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 trwającej operacji przywracania można monitorować za pomocą programu PowerShell (get-azsqlinstancedatabaselogreplay) lub interfejsu wiersza polecenia platformy Azure (az_sql_midb_log_replay_show polecenia cmdlet). Aby śledzić dodatkowe szczegóły dotyczące żądania, które zakończyło się niepowodzeniem, użyj polecenia programu PowerShell Get-AzSqlInstanceOperation lub użyj polecenia interfejsu wiersza polecenia platformy Azure 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ć 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).

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 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 każda baza danych musi znajdować się we własnym folderze. Magazyn LRS musi być uruchamiany oddzielnie dla każdej bazy danych, wskazując pełną ścieżkę identyfikatora URI kontenera usługi Azure Blob Storage i pojedynczy folder bazy danych. Zagnieżdżone foldery wewnątrz folderów bazy danych nie są obsługiwane.

Ograniczenia usługi LRS

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

Następne kroki

• 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.

• Dowiedz się więcej na temat migrowania baz danych do usługi SQL Managed Instance przy użyciu funkcji linku.

• Dowiedz się więcej o migrowaniu baz danych z programu SQL Server do usługi SQL Managed Instance.

• Dowiedz się więcej o różnicach między programem SQL Server i usługą SQL Managed Instance.

• Dowiedz się więcej o najlepszych rozwiązaniach dotyczących kosztów i rozmiarów obciążeń migrowanych na platformę Azure.