Udostępnij za pomocą

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.

Uwaga

Teraz możesz migrować instancję SQL Server obsługiwaną przez Azure Arc do Azure SQL Managed Instance bezpośrednio za pośrednictwem portalu Azure. Aby uzyskać więcej informacji, zobacz Migrowanie do usługi Azure SQL Managed Instance.

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ę z użyciem LRS, zapoznaj się z artykułem Migrowanie baz danych z SQL Server 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:

  • 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.
  • Nie masz dostępu do systemu operacyjnego hosta ani uprawnień administratora.
  • Nie można otwierać portów sieciowych ze środowiska do platformy Azure.
  • Problemy z ograniczaniem przepustowości sieci lub blokowaniem serwera proxy istnieją w danym ś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ż system przechowywania LRS działa poprzez przywracanie standardowych plików kopii zapasowych programu SQL Server, obsługuje 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

  • LRS to jedyna metoda przywracania różnicowych kopii zapasowych na zarządzanych wystąpieniach SQL. 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 języka 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. LRS obsługuje pełne, dzienników i różnicowe kopie zapasowe. 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 Twoje konto Blob Storage w poszukiwaniu wszelkich nowych kopii zapasowych różnicowych lub kopii zapasowych dzienników, które dodasz 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. Magazyn LRS przywraca bazy danych w trybie NORECOVERY, więc nie można ich używać do odczytu ani zapisu, dopóki proces migracji nie zostanie zakończony.

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 przy użyciu usługi ponownego odtwarzania dziennika.

Uwaga

Wykonywanie kopii zapasowych w programie SQL Server z CHECKSUM włączonym ustawieniem jest zdecydowanie zalecane, ponieważ istnieje ryzyko przywrócenia uszkodzonej bazy danych na platformę Azure bez niej.

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 już dodawać 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. Migrowana baza danych staje się dostępna na potrzeby dostępu 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 w usłudze Azure Blob Storage i przywraca wszystkie nowe pliki dzienników lub różnicowe kopie zapasowe, 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 LRS, albo automatycznie za pośrednictwem automatycznego zakończenia, albo ręcznie przez przełączenie, nie można wznowić procesu przywracania dla bazy danych, która została włączona do trybu online w 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 migracji pracy

Obraz w tej sekcji przedstawia typowy przepływ pracy migracji, natomiast tabela wymienia kroki.

Używaj trybu autouzupełniania tylko wtedy, gdy wszystkie pliki łańcucha kopii zapasowych są dostępne z wyprzedzeniem. Zalecamy ten tryb dla obciążeń pasywnych, które nie wymagają nadrobienia 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. Ten tryb zalecamy w przypadku aktywnych obciążeń, które wymagają nadrabiania zaległości danych.

Diagram ilustrujący kroki 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. Uruchom usługę przy użyciu programu PowerShell (start-azsqlinstancedatabaselogreplay) lub Azure CLI (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.

pl-PL: Po uruchomieniu LRS w trybie automatycznego przywracania, przywraca wszystkie kopie zapasowe na podstawie wskazanego ostatniego pliku kopii zapasowej. Musisz wcześniej przekazać wszystkie pliki kopii zapasowej i nie można dodać żadnych nowych plików kopii zapasowych, gdy migracja jest w toku. Ten tryb jest zalecany w przypadku obciążeń pasywnych, które nie wymagają nadrobienia zaległości danych.

Po uruchomieniu usługi LRS w trybie ciągłym, przywracane są wszystkie kopie zapasowe, które zostały początkowo przesłane, a następnie monitorowane są wszelkie nowe pliki przesył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. Ten tryb zalecamy w przypadku aktywnych obciążeń, które wymagają nadrabiania zaległości danych.
2.1. Monitorowanie postępu operacji. Monitoruj postęp trwającej operacji przywracania za pomocą programu PowerShell (get-azsqlinstancedatabaselogreplay) lub interfejsu wiersza polecenia Azure CLI (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 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 uruchomisz LRS w trybie automatycznego uzupełniania, migracja zostanie automatycznie zakończona po przywróceniu ostatniego określonego pliku kopii zapasowej.

Jeśli uruchamiasz LRS w trybie ciągłym, zatrzymaj aplikację i procesy obciążenia. 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 końcówki dziennika została przywrócona na zarządzanym wystąpieniu SQL. 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 mogą przerywać i przedłużać zadania migracji. Zdecydowanie zalecamy użycie okna obsługi do zaplanowanych aktualizacji systemu. Zaplanuj migrację w ustalonym oknie serwisowym.
  • Zadania migracji, które są przerywane przez aktualizacje systemu, automatycznie wstrzymują i wznawiają działanie dla wystąpień zarządzanych SQL ogólnego przeznaczenia oraz uruchamiają się ponownie dla wystąpień zarządzanych SQL krytycznych dla działania biznesowego. Te aktualizacje wpływają 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

Rozpocznij migrację, uruchamiając system LRS. Usługę można uruchomić w trybie autouzupełniania lub ciągłym. Aby uzyskać szczegółowe informacje, zobacz Migrowanie baz danych z programu SQL Server przy użyciu usługi ponownego odtwarzania dziennika.

  • Tryb autouzupełniania. W przypadku korzystania z trybu autouzupełniania migracja zostanie zakończona automatycznie po przywróceniu ostatniego 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 zażądaniu ręcznego przejścia jednorazowego.

    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 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. Uruchom LRS oddzielnie dla każdej bazy danych, wskazując pełną ścieżkę identyfikatora URI kontenera Azure Blob Storage i folder poszczególnej 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, czego dotyczy korzystanie z LRS.

Treści powiązane

  • Last updated on