Udostępnij za pośrednictwem

Migrowanie baz danych z programu SQL Server przy użyciu usługi ponownego odtwarzania dzienników — Azure SQL Managed Instance

  • Artykuł

Dotyczy:Azure SQL Managed Instance

W tym artykule wyjaśniono, jak migrować bazy danych do usługi Azure SQL Managed Instance przy użyciu usługi Replay Service (LRS) dziennika. LRS to bezpłatna usługa w chmurze dostępna dla usługi Azure SQL Managed Instance oparta na technologii wysyłania dzienników programu SQL Server.

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
  • Google Compute Engine
  • Cloud SQL for SQL Server — GCP (Google Cloud Platform)

Wymagania wstępne

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.
  • Nie można używać baz danych, które są przywracane za pośrednictwem magazynu LRS do momentu zakończenia procesu migracji.
  • Magazyn LRS nie obsługuje dostępu tylko do odczytu do baz danych podczas migracji.
  • Po zakończeniu migracji proces migracji jest końcowy i nie można go wznowić z dodatkowymi różnicowymi kopiami zapasowymi.

Przed rozpoczęciem należy wziąć pod uwagę wymagania w tej sekcji zarówno dla wystąpienia programu SQL Server, jak i platformy Azure. Uważnie przejrzyj sekcje ograniczeń i najlepszych rozwiązań , aby zapewnić pomyślną migrację.

SQL Server

Upewnij się, że spełniasz następujące wymagania dotyczące programu SQL Server:

  • SQL Server w wersji 2008–2022.
  • Baza danych programu SQL Server korzysta z pełnego modelu odzyskiwania (obowiązkowego).
  • Pełna kopia zapasowa baz danych (jeden lub wiele plików).
  • Różnicowa kopia zapasowa (jeden lub wiele plików).
  • Kopia zapasowa dziennika (nie jest podzielona dla pliku dziennika transakcji).
  • W przypadku programu SQL Server w wersji 2008–2016 utwórz kopię zapasową lokalnie i ręcznie przekaż ją na konto usługi Azure Blob Storage.
  • W przypadku programu SQL Server 2016 lub nowszego możesz wykonać kopię zapasową bezpośrednio na koncie usługi Azure Blob Storage.
  • CHECKSUM Mimo że włączenie obsługi kopii zapasowych nie jest wymagane, zdecydowanie zaleca się zapobieganie przypadkowemu migrowaniu uszkodzonej bazy danych i szybszych operacji przywracania.

Azure

Upewnij się, że spełnisz następujące wymagania dotyczące platformy Azure:

  • Moduł Az.SQL programu PowerShell w wersji 4.0.0 lub nowszej (zainstalowany lub dostępny za pośrednictwem usługi Azure Cloud Shell).
  • Interfejs wiersza polecenia platformy Azure w wersji 2.42.0 lub nowszej (zainstalowany).
  • Aprowizowany kontener usługi Azure Blob Storage.
  • Token zabezpieczający sygnatury dostępu współdzielonego (SAS) z uprawnieniami Read wygenerowanymi List dla kontenera usługi Blob Storage lub tożsamością zarządzaną, która może uzyskiwać dostęp do kontenera. Udzielanie większej liczby uprawnień niż Read i List spowoduje niepowodzenie magazynu LRS.
  • Umieść pliki kopii zapasowej dla pojedynczej bazy danych wewnątrz oddzielnego folderu na koncie magazynu przy użyciu struktury prostego pliku (obowiązkowej). Zagnieżdżanie folderów wewnątrz folderów bazy danych nie jest obsługiwane.

Uprawnienia RBAC platformy Azure

Uruchamianie magazynu LRS za pośrednictwem podanych klientów wymaga jednej z następujących ról kontroli dostępu na podstawie ról (RBAC) platformy Azure:

Najlepsze rozwiązania

W przypadku korzystania z magazynu LRS należy wziąć pod uwagę następujące najlepsze rozwiązania:

  • Uruchom Asystent migracji danych, aby sprawdzić, czy bazy danych są gotowe do migracji do usługi SQL Managed Instance.
  • Podziel pełne i różnicowe kopie zapasowe na wiele plików, zamiast używać jednego pliku.
  • Włącz kompresję kopii zapasowych, aby przyspieszyć transfer sieciowy.
  • Użyj usługi Cloud Shell, aby uruchomić skrypty programu PowerShell lub interfejsu wiersza polecenia, ponieważ zawsze będą aktualizowane tak, aby korzystały z najnowszych wydanych poleceń cmdlet.
  • Skonfiguruj okno obsługi, aby aktualizacje systemu zostały zaplanowane w określonym dniu i o określonej godzinie poza oknem migracji, aby zapobiec opóźnieniu lub przerwaniu migracji.
  • Zaplanuj ukończenie pojedynczego zadania migracji LRS w ciągu maksymalnie 30 dni. Po wygaśnięciu tego przedziału czasu zadanie LRS jest automatycznie anulowane.
  • Aby zapobiec przypadkowemu migracji uszkodzonej bazy danych i szybszego przywracania bazy danych, włącz CHECKSUM je podczas tworzenia kopii zapasowych. Mimo że usługa SQL Managed Instance przeprowadza podstawowe sprawdzanie integralności kopii zapasowych bez CHECKSUM, przechwytywanie wszystkich form uszkodzenia nie jest gwarantowane. Tworzenie kopii zapasowych za pomocą CHECKSUM polecenia to jedyny sposób, aby upewnić się, że kopia zapasowa przywrócona do usługi SQL Managed Instance nie jest uszkodzona. Podstawowe sprawdzanie integralności kopii zapasowych bez CHECKSUM zwiększania czasu przywracania bazy danych.
  • Podczas migracji do warstwy usługi Krytyczne dla działania firmy należy uwzględnić długotrwałe opóźnienie dostępności bazy danych po przejściu jednorazowym, podczas gdy bazy danych są rozmieszczane do replik pomocniczych. W przypadku szczególnie dużych baz danych z minimalnymi wymaganiami dotyczącymi przestojów należy najpierw rozważyć migrację do warstwy usługi Ogólnego przeznaczenia, a następnie uaktualnienie do warstwy usługi Krytyczne dla działania firmy lub użycie linku wystąpienie zarządzane w celu przeprowadzenia migracji danych.
  • Przekazywanie tysięcy plików bazy danych do przywrócenia może prowadzić do nadmiernego czasu migracji, a nawet niepowodzenia. Skonsoliduj bazy danych w mniej plików, aby przyspieszyć proces migracji i zapewnić jej sukces.
  • Aby zminimalizować czas przełączenia i zmniejszyć ryzyko awarii, upewnij się, że ostatnia kopia zapasowa jest możliwie jak najmniejsza.

Konfigurowanie okna obsługi

Aktualizacje systemu dla usługi SQL Managed Instance mają pierwszeństwo przed migracjami baz danych w toku.

Migracja ma różny wpływ na warstwę usługi:

  • W warstwie usługi Ogólnego przeznaczenia wszystkie oczekujące migracje LRS są zawieszone i wznawiane dopiero po zastosowaniu aktualizacji. To zachowanie systemu może wydłużyć czas migracji, szczególnie w przypadku dużych baz danych.
  • W warstwie usługi Krytyczne dla działania firmy wszystkie oczekujące migracje LRS są anulowane i automatycznie uruchamiane ponownie po zastosowaniu aktualizacji. To zachowanie systemu może wydłużyć czas migracji, szczególnie w przypadku dużych baz danych.

Aby osiągnąć przewidywalny czas migracji bazy danych, rozważ skonfigurowanie okna obsługi w celu zaplanowania aktualizacji systemu dla określonego dnia i godziny oraz uruchomienia i ukończenia zadań migracji poza wyznaczonym przedziałem czasu okna obsługi. Na przykład w przypadku migracji, która rozpoczyna się w poniedziałek, skonfiguruj niestandardowe okno obsługi w niedzielę, aby umożliwić najwięcej czasu na ukończenie migracji.

Konfigurowanie okna obsługi nie jest wymagane, ale jest zdecydowanie zalecane w przypadku dużych baz danych.

Uwaga

Chociaż okno obsługi kontroluje przewidywalność planowanych aktualizacji, nie gwarantuje, że nieplanowane przejścia w tryb failover lub aktualizacje poprawek zabezpieczeń nie zostaną wykonane. Nieplanowane przejście w tryb failover lub poprawka zabezpieczeń (która ma pierwszeństwo przed wszystkimi innymi aktualizacjami) nadal może przerwać migrację.

Migrowanie wielu baz danych

W przypadku migrowania wielu baz danych przy użyciu tego samego kontenera usługi Azure Blob Storage należy umieścić pliki kopii zapasowych dla różnych baz danych w oddzielnych folderach wewnątrz kontenera. Wszystkie pliki kopii zapasowej dla pojedynczej bazy danych muszą być umieszczone w płaskiej strukturze plików w folderze bazy danych, a foldery nie mogą być zagnieżdżone. Zagnieżdżanie folderów wewnątrz folderów bazy danych nie jest obsługiwane.

Oto przykład struktury folderów wewnątrz kontenera usługi Azure Blob Storage, struktury wymaganej do migrowania wielu baz danych przy użyciu magazynu LRS.

-- Place all backup files for database 1 in a separate "database1" folder in a flat-file structure.
-- Don't use nested folders inside the database1 folder.
https://<mystorageaccountname>.blob.core.windows.net/<containername>/<database1>/<all-database1-backup-files>

-- Place all backup files for database 2 in a separate "database2" folder in a flat-file structure.
-- Don't use nested folders inside the database2 folder.
https://<mystorageaccountname>.blob.core.windows.net/<containername>/<database2>/<all-database2-backup-files>

-- Place all backup files for database 3 in a separate "database3" folder in a flat-file structure. 
-- Don't use nested folders inside the database3 folder.
https://<mystorageaccountname>.blob.core.windows.net/<containername>/<database3>/<all-database3-backup-files>

Tworzenie konta magazynu

Konto usługi Azure Blob Storage jest używane jako magazyn pośredniczący dla plików kopii zapasowych między wystąpieniem programu SQL Server a wdrożeniem usługi SQL Managed Instance. Aby utworzyć nowe konto magazynu i kontener obiektów blob na koncie magazynu:

  1. Create a storage account (Tworzenie konta magazynu).
  2. Utwórz kontener obiektów blob na koncie magazynu.

Konfigurowanie usługi Azure Storage za zaporą

Korzystanie z usługi Azure Blob Storage chronionej za zaporą jest obsługiwane, ale wymaga dodatkowej konfiguracji. Aby włączyć dostęp do odczytu/zapisu w usłudze Azure Storage z włączoną usługą Azure Firewall, należy dodać podsieć wystąpienia zarządzanego SQL do reguł zapory sieci wirtualnej dla konta magazynu przy użyciu delegowania podsieci MI i punktu końcowego usługi Storage. Konto magazynu i wystąpienie zarządzane muszą znajdować się w tym samym regionie lub w dwóch sparowanych regionach.

Jeśli usługa Azure Storage znajduje się za zaporą, w dzienniku błędów wystąpienia zarządzanego SQL może zostać wyświetlony następujący komunikat:

Audit: Storage access denied user fault. Creating an email notification:

Spowoduje to wygenerowanie wiadomości e-mail z powiadomieniem o tym, że inspekcja wystąpienia zarządzanego SQL nie może zapisywać dzienników inspekcji na koncie magazynu. Jeśli widzisz ten błąd lub otrzymasz tę wiadomość e-mail, wykonaj kroki opisane w tej sekcji, aby skonfigurować zaporę.

Aby skonfigurować zaporę, wykonaj następujące kroki:

  1. Przejdź do wystąpienia zarządzanego w witrynie Azure Portal i wybierz podsieć, aby otworzyć stronę Podsieci .

    Zrzut ekranu przedstawiający stronę Przegląd wystąpienia zarządzanego SQL w witrynie Azure Portal z wybraną podsiecią.

  2. Na stronie Podsieci wybierz nazwę podsieci, aby otworzyć stronę konfiguracji podsieci.

    Zrzut ekranu przedstawiający stronę Podsieć wystąpienia zarządzanego SQL w witrynie Azure Portal z wybraną podsiecią.

  3. W obszarze Delegowanie podsieci wybierz pozycję Microsoft.Sql/managedInstances z menu rozwijanego Delegowanie podsieci do usługi. Poczekaj około godziny na propagację uprawnień, a następnie w obszarze Punkty końcowe usługi wybierz pozycję Microsoft.Storage z listy rozwijanej Usługi .

    Zrzut ekranu przedstawiający stronę konfiguracji podsieci wystąpienia zarządzanego SQL w witrynie Azure Portal.

  4. Następnie przejdź do konta magazynu w witrynie Azure Portal, wybierz pozycję Sieć w obszarze Zabezpieczenia i sieć , a następnie wybierz kartę Zapory i sieci wirtualne.

  5. Na karcie Zapory i sieci wirtualne dla konta magazynu wybierz pozycję +Dodaj istniejącą sieć wirtualną, aby otworzyć stronę Dodawanie sieci.

    Zrzut ekranu przedstawiający stronę Sieć konta magazynu w witrynie Azure Portal z wybraną pozycją Dodaj istniejącą sieć wirtualną.

  6. Wybierz odpowiednią subskrypcję, sieć wirtualną i podsieć wystąpienia zarządzanego z menu rozwijanych, a następnie wybierz pozycję Dodaj , aby dodać sieć wirtualną wystąpienia zarządzanego SQL do konta magazynu.

Uwierzytelnianie na koncie usługi Blob Storage

Użyj tokenu SAS lub tożsamości zarządzanej, aby uzyskać dostęp do konta usługi Azure Blob Storage.

Ostrzeżenie

Nie można używać zarówno tokenu SAS, jak i tożsamości zarządzanej równolegle na tym samym koncie magazynu. Możesz użyć tokenu SAS lub tożsamości zarządzanej, ale nie obu tych elementów.

Generowanie tokenu uwierzytelniania SAS usługi Blob Storage dla magazynu LRS

Uzyskaj dostęp do konta usługi Azure Blob Storage przy użyciu tokenu SAS.

Możesz użyć konta usługi Azure Blob Storage jako pośredniego magazynu dla plików kopii zapasowych między wystąpieniem programu SQL Server i wdrożeniem usługi SQL Managed Instance. Wygeneruj token uwierzytelniania SAS dla magazynu LRS z uprawnieniami tylko do odczytu i listy. Token umożliwia magazynowi LRS dostęp do konta usługi Blob Storage i używa plików kopii zapasowych do przywrócenia ich do wystąpienia zarządzanego.

Wykonaj następujące kroki, aby wygenerować token:

  1. W witrynie Azure Portal otwórz Eksplorator usługi Storage.

  2. Rozwiń węzeł Kontenery obiektów blob.

  3. Kliknij prawym przyciskiem myszy kontener obiektów blob, a następnie wybierz pozycję Pobierz sygnaturę dostępu współdzielonego.

    Zrzut ekranu przedstawiający opcje generowania tokenu uwierzytelniania SAS.

  4. Wybierz przedział czasu wygaśnięcia tokenu. Upewnij się, że token jest prawidłowy podczas migracji.

  5. Wybierz strefę czasową tokenu: UTC lub czas lokalny.

    Ważne

    Strefa czasowa tokenu i wystąpienie zarządzane mogą być niezgodne. Upewnij się, że token SAS ma odpowiednią ważność czasu, biorąc pod uwagę strefy czasowe. Aby uwzględnić różnice w strefie czasowej, ustaw ważność OD wartości na długo przed rozpoczęciem okna migracji i wartość TO dobrze po zakończeniu migracji.

  6. Wybierz pozycję Tylko uprawnienia do odczytu i listy .

    Ważne

    Nie wybieraj żadnych innych uprawnień. Jeśli to zrobisz, magazyn LRS nie zostanie uruchomiony. To wymaganie dotyczące zabezpieczeń jest zgodnie z projektem.

  7. Wybierz pozycję Utwórz.

    Zrzut ekranu przedstawiający opcje wygaśnięcia tokenu SAS, strefy czasowej i uprawnień wraz z przyciskiem Utwórz.

Uwierzytelnianie sygnatury dostępu współdzielonego jest generowane z określoną ważnością czasu. Potrzebna jest wersja identyfikatora URI tokenu, jak pokazano na poniższym zrzucie ekranu:

Zrzut ekranu przedstawiający przykład wersji identyfikatora URI tokenu SAS.

Uwaga

Używanie tokenów SAS utworzonych z uprawnieniami ustawionymi przez zdefiniowanie przechowywanych zasad dostępu nie jest obecnie obsługiwane. Postępuj zgodnie z instrukcjami opisanymi w tej procedurze, aby ręcznie określić uprawnienia odczyt i lista dla tokenu SAS.

Kopiowanie parametrów z tokenu SAS

Uzyskaj dostęp do konta usługi Azure Blob Storage przy użyciu tokenu SAS lub tożsamości zarządzanej.

Zanim użyjesz tokenu SAS do uruchomienia magazynu LRS, musisz zrozumieć jego strukturę. Identyfikator URI wygenerowanego tokenu SAS składa się z dwóch części oddzielonych znakiem zapytania (?), jak pokazano w tym przykładzie:

Przykładowy identyfikator URI wygenerowanego tokenu SAS dla usługi ponownego odtwarzania dziennika.

Pierwsza część, zaczynając od https:// znaku zapytania (?), jest używana dla StorageContainerURI parametru, który jest podawany jako dane wejściowe do magazynu LRS. Udostępnia informacje LRS o folderze, w którym są przechowywane pliki kopii zapasowej bazy danych.

Druga część, od znaku zapytania (?) przez koniec ciągu, jest parametrem StorageContainerSasToken . Ta część jest rzeczywistym podpisanym tokenem uwierzytelniania, który jest prawidłowy w określonym czasie. Ta część nie musi zaczynać się od sp= , jak pokazano w przykładzie. Twój scenariusz może się różnić.

Skopiuj parametry w następujący sposób:

  1. Skopiuj pierwszą część tokenu z https:// maksymalnie do, ale nie uwzględniając znaku zapytania (?). Użyj go jako parametru StorageContainerUri w programie PowerShell lub interfejsie wiersza polecenia platformy Azure podczas uruchamiania magazynu LRS.

    Zrzut ekranu pokazujący, gdzie skopiować pierwszą część tokenu.

  2. Skopiuj drugą część tokenu z znaku zapytania (?) na końcu ciągu. Użyj go jako parametru StorageContainerSasToken w programie PowerShell lub interfejsie wiersza polecenia platformy Azure podczas uruchamiania magazynu LRS.

    Zrzut ekranu przedstawiający miejsce kopiowania drugiej części tokenu.

Uwaga

Nie dołączaj znaku zapytania (?) podczas kopiowania żadnej części tokenu.

Weryfikowanie dostępu do magazynu wystąpienia zarządzanego

Sprawdź, czy wystąpienie zarządzane może uzyskać dostęp do konta usługi Blob Storage.

Najpierw przekaż dowolną kopię zapasową bazy danych, taką jak full_0_0.bak, do kontenera usługi Azure Blob Storage.

Następnie połącz się z wystąpieniem zarządzanym i uruchom przykładowe zapytanie testowe, aby określić, czy wystąpienie zarządzane może uzyskać dostęp do kopii zapasowej w kontenerze.

Jeśli używasz tokenu SAS do uwierzytelniania na koncie magazynu, zastąp <sastoken> element tokenem SAS i uruchom następujące zapytanie w wystąpieniu:

CREATE CREDENTIAL [https://mitutorials.blob.core.windows.net/databases] 
WITH IDENTITY = 'SHARED ACCESS SIGNATURE' 
, SECRET = '<sastoken>' 

RESTORE HEADERONLY 
FROM URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/full_0_0.bak'

Przekazywanie kopii zapasowych na konto usługi Blob Storage

Gdy kontener obiektów blob jest gotowy i potwierdzono, że wystąpienie zarządzane może uzyskać dostęp do kontenera, możesz rozpocząć przekazywanie kopii zapasowych na konto usługi Blob Storage. Można:

  • Skopiuj kopie zapasowe na konto usługi Blob Storage.
  • Wykonywanie kopii zapasowych z programu SQL Server bezpośrednio na konto usługi Blob Storage przy użyciu polecenia BACKUP TO URL , jeśli środowisko na to zezwala (począwszy od programu SQL Server w wersji 2012 z dodatkiem SP1 CU2 i programu SQL Server 2014).

Kopiowanie istniejących kopii zapasowych na konto usługi Blob Storage

Jeśli korzystasz z wcześniejszej wersji programu SQL Server lub jeśli środowisko nie obsługuje tworzenia kopii zapasowych bezpośrednio do adresu URL, wykonaj kopie zapasowe w wystąpieniu programu SQL Server tak, jak zwykle, a następnie skopiuj je na konto usługi Blob Storage.

Tworzenie kopii zapasowych w wystąpieniu programu SQL Server

Ustaw bazy danych, które chcesz przeprowadzić migrację do pełnego modelu odzyskiwania, aby umożliwić tworzenie kopii zapasowych dzienników.

-- To permit log backups, before the full database backup, modify the database to use the full recovery
USE master
ALTER DATABASE SampleDB
SET RECOVERY FULL
GO

Aby ręcznie utworzyć pełne, różnicowe i różnicowe kopie zapasowe bazy danych w magazynie lokalnym, użyj poniższych przykładowych skryptów języka T-SQL. CHECKSUM nie jest wymagane, ale zaleca się zapobieganie migrowaniu uszkodzonej bazy danych i skrócenie czasu przywracania.

Poniższy przykład wykonuje pełną kopię zapasową bazy danych na dysku lokalnym:

-- Take full database backup to local disk
BACKUP DATABASE [SampleDB]
TO DISK='C:\BACKUP\SampleDB_full.bak'
WITH INIT, COMPRESSION, CHECKSUM
GO

Poniższy przykład wykonuje różnicową kopię zapasową na dysku lokalnym:

-- Take differential database backup to local disk
BACKUP DATABASE [SampleDB]
TO DISK='C:\BACKUP\SampleDB_diff.bak'
WITH DIFFERENTIAL, COMPRESSION, CHECKSUM
GO

Poniższy przykład wykonuje kopię zapasową dziennika transakcji na dysku lokalnym:

-- Take transactional log backup to local disk
BACKUP LOG [SampleDB]
TO DISK='C:\BACKUP\SampleDB_log.trn'
WITH COMPRESSION, CHECKSUM
GO

Kopiowanie kopii zapasowych na konto usługi Blob Storage

Gdy kopie zapasowe będą gotowe i chcesz rozpocząć migrację baz danych do wystąpienia zarządzanego przy użyciu magazynu LRS, możesz użyć następujących metod kopiowania istniejących kopii zapasowych na konto usługi Blob Storage:

Uwaga

Aby przeprowadzić migrację wielu baz danych przy użyciu tego samego kontenera usługi Azure Blob Storage, umieść wszystkie pliki kopii zapasowej dla pojedynczej bazy danych w oddzielnym folderze wewnątrz kontenera. Użyj struktury plików prostych dla każdego folderu bazy danych. Zagnieżdżanie folderów wewnątrz folderów bazy danych nie jest obsługiwane.

Tworzenie kopii zapasowych bezpośrednio na koncie usługi Blob Storage

Jeśli korzystasz z obsługiwanej wersji programu SQL Server (począwszy od programu SQL Server 2012 z dodatkiem SP1 CU2 i programu SQL Server 2014), a zasady firmowe i sieciowe umożliwiają wykonywanie kopii zapasowych z programu SQL Server bezpośrednio na koncie usługi Blob Storage przy użyciu natywnej opcji KOPIA ZAPASOWA PROGRAMU SQL Server DO ADRESU URL . Jeśli możesz użyć usługi BACKUP TO URL, nie musisz wykonywać kopii zapasowych w magazynie lokalnym i przekazywać je na konto usługi Blob Storage.

W przypadku tworzenia natywnych kopii zapasowych bezpośrednio na koncie usługi Blob Storage należy uwierzytelnić się na koncie magazynu.

Użyj następującego polecenia, aby utworzyć poświadczenia importujące token SAS do wystąpienia programu SQL Server:

CREATE CREDENTIAL [https://<mystorageaccountname>.blob.core.windows.net/<containername>] 
WITH IDENTITY = 'SHARED ACCESS SIGNATURE',  
SECRET = '<SAS_TOKEN>';

Aby uzyskać szczegółowe instrukcje dotyczące pracy z tokenami SAS, zapoznaj się z samouczkiem Używanie usługi Azure Blob Storage z programem SQL Server.

Po utworzeniu poświadczeń w celu uwierzytelnienia wystąpienia programu SQL Server w usłudze Blob Storage możesz użyć polecenia BACKUP TO URL w celu utworzenia kopii zapasowych bezpośrednio na koncie magazynu. CHECKSUM jest zalecana, ale nie jest wymagana.

Poniższy przykład wykonuje pełną kopię zapasową bazy danych pod adresem URL:

-- Take a full database backup to a URL
BACKUP DATABASE [SampleDB]
TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>/SampleDB_full.bak'
WITH INIT, COMPRESSION, CHECKSUM
GO

Poniższy przykład pobiera różnicową kopię zapasową bazy danych do adresu URL:

-- Take a differential database backup to a URL
BACKUP DATABASE [SampleDB]
TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>/SampleDB_diff.bak'  
WITH DIFFERENTIAL, COMPRESSION, CHECKSUM
GO

W poniższym przykładzie kopia zapasowa dziennika transakcji jest pobierana do adresu URL:

-- Take a transactional log backup to a URL
BACKUP LOG [SampleDB]
TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>/SampleDB_log.trn'  
WITH COMPRESSION, CHECKSUM

Zaloguj się do platformy Azure i wybierz subskrypcję

Użyj następującego polecenia cmdlet programu PowerShell, aby zalogować się do platformy Azure:

Login-AzAccount

Wybierz subskrypcję, w której znajduje się wystąpienie zarządzane, przy użyciu następującego polecenia cmdlet programu PowerShell:

Select-AzSubscription -SubscriptionId <subscription ID>

Rozpoczynanie migracji

Rozpocznij migrację, uruchamiając magazyn LRS. Usługę można uruchomić w trybie autouzupełniania lub ciągłym .

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 na konto usługi Blob Storage. Nie zezwala na dodawanie nowych plików kopii zapasowych podczas migracji. Ta opcja wymaga start polecenia , aby określić nazwę pliku ostatniej kopii zapasowej. Zalecamy ten tryb dla obciążeń pasywnych, dla których zaległości danych nie są wymagane.

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 ten tryb dla aktywnych obciążeń, dla których jest wymagany nadrabianie zaległości danych.

Zaplanuj ukończenie pojedynczego zadania migracji LRS w ciągu maksymalnie 30 dni. Po upływie tego czasu 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.

Uruchamianie magazynu LRS w trybie autouzupełniania

Upewnij się, że cały łańcuch kopii zapasowych został przekazany do konta usługi Azure Blob Storage. Ta opcja nie zezwala na dodawanie nowych plików kopii zapasowych podczas migracji.

Aby uruchomić magazyn LRS w trybie autouzupełniania, użyj poleceń programu PowerShell lub interfejsu wiersza polecenia platformy Azure. Określ nazwę ostatniego pliku kopii zapasowej przy użyciu parametru -LastBackupName . Po zakończeniu przywracania ostatniego określonego pliku kopii zapasowej usługa automatycznie inicjuje migrację jednorazową.

Przywróć bazę danych z konta magazynu przy użyciu tokenu SAS lub tożsamości zarządzanej.

Ważne

  • Przed rozpoczęciem migracji w trybie autouzupełniania upewnij się, że cały łańcuch kopii zapasowych został przekazany do konta usługi Azure Blob Storage. Ten tryb nie zezwala na dodawanie nowych plików kopii zapasowej podczas migracji.
  • Upewnij się, że ostatni plik kopii zapasowej został poprawnie określony i że nie przekazano więcej plików po nim. Jeśli system wykryje więcej plików kopii zapasowych poza ostatnim określonym plikiem kopii zapasowej, migracja zakończy się niepowodzeniem.

Poniższy przykład programu PowerShell uruchamia magazyn LRS w trybie autouzupełniania przy użyciu tokenu SAS:

Start-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
    -InstanceName "ManagedInstance01" `
    -Name "ManagedDatabaseName" `
    -Collation "SQL_Latin1_General_CP1_CI_AS" `
    -StorageContainerUri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>" `
    -StorageContainerSasToken "sv=2019-02-02&ss=b&srt=sco&sp=rl&se=2023-12-02T00:09:14Z&st=2019-11-25T16:09:14Z&spr=https&sig=92kAe4QYmXaht%2Fgjocqwerqwer41s%3D" `
    -AutoCompleteRestore `
    -LastBackupName "last_backup.bak"

Poniższy przykład interfejsu wiersza polecenia platformy Azure uruchamia magazyn LRS w trybie autouzupełniania przy użyciu tokenu SAS:

az sql midb log-replay start -g mygroup --mi myinstance -n mymanageddb -a --last-bn "backup.bak"
    --storage-uri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>"
    --storage-sas "sv=2019-02-02&ss=b&srt=sco&sp=rl&se=2023-12-02T00:09:14Z&st=2019-11-25T16:09:14Z&spr=https&sig=92kAe4QYmXaht%2Fgjocqwerqwer41s%3D"

Uruchamianie magazynu LRS w trybie ciągłym

Upewnij się, że został przekazany początkowy łańcuch kopii zapasowych do konta usługi Azure Blob Storage.

Ważne

Po uruchomieniu magazynu LRS w trybie ciągłym będzie można dodawać nowe kopie zapasowe dziennika i różnicowe do konta magazynu do momentu ręcznego przejścia jednorazowego. Po zainicjowaniu ręcznego przełączania jednorazowego nie można dodać ani przywrócić żadnych dodatkowych plików różnicowych.

Poniższy przykład programu PowerShell uruchamia magazyn LRS w trybie ciągłym przy użyciu tokenu SAS:

Start-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
    -InstanceName "ManagedInstance01" `
    -Name "ManagedDatabaseName" `
    -Collation "SQL_Latin1_General_CP1_CI_AS" -StorageContainerUri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>" `
    -StorageContainerSasToken "sv=2019-02-02&ss=b&srt=sco&sp=rl&se=2023-12-02T00:09:14Z&st=2019-11-25T16:09:14Z&spr=https&sig=92kAe4QYmXaht%2Fgjocqwerqwer41s%3D"

Poniższy przykład interfejsu wiersza polecenia platformy Azure uruchamia magazyn LRS w trybie ciągłym:

az sql midb log-replay start -g mygroup --mi myinstance -n mymanageddb
    --storage-uri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>"
    --storage-sas "sv=2019-02-02&ss=b&srt=sco&sp=rl&se=2023-12-02T00:09:14Z&st=2019-11-25T16:09:14Z&spr=https&sig=92kAe4QYmXaht%2Fgjocqwerqwer41s%3D"

Wykonywanie skryptu zadania migracji

Klienci programu PowerShell i interfejsu wiersza polecenia platformy Azure, którzy uruchamiają magazyn LRS w trybie ciągłym, są synchroniczne. W tym trybie program PowerShell i interfejs wiersza polecenia platformy Azure czekają na odpowiedź interfejsu API, aby zgłosić powodzenie lub niepowodzenie przed uruchomieniem zadania.

Podczas tego oczekiwania polecenie nie zwróci kontroli do wiersza polecenia. Jeśli wykonujesz skrypty środowiska migracji i potrzebujesz polecenia uruchamiania LRS, aby natychmiast oddać kontrolę, aby kontynuować resztę skryptu, możesz uruchomić program PowerShell jako zadanie w tle z przełącznikiem -AsJob . Na przykład:

$lrsjob = Start-AzSqlInstanceDatabaseLogReplay <required parameters> -AsJob

Po uruchomieniu zadania w tle obiekt zadania jest zwracany natychmiast, nawet jeśli zadanie zajmuje dłuższy czas. Możesz kontynuować pracę w sesji bez przerwy podczas uruchamiania zadania. Aby uzyskać szczegółowe informacje na temat uruchamiania programu PowerShell jako zadania w tle, zobacz dokumentację zadania uruchamiania programu PowerShell.

Podobnie, aby uruchomić polecenie interfejsu wiersza polecenia platformy Azure w systemie Linux jako proces w tle, użyj znaku ampersand (&) na końcu polecenia uruchamiania LRS:

az sql midb log-replay start <required parameters> &

Monitorowanie postępu migracji

Az.SQL 4.0.0 i nowszych zawiera szczegółowy raport postępu. Przejrzyj szczegóły przywracania zarządzanej bazy danych — pobierz przykładowe dane wyjściowe.

Aby monitorować trwający postęp migracji za pomocą programu PowerShell, użyj następującego polecenia:

Get-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
    -InstanceName "ManagedInstance01" `
    -Name "ManagedDatabaseName"

Aby monitorować trwający postęp migracji za pośrednictwem interfejsu wiersza polecenia platformy Azure, użyj następującego polecenia:

az sql midb log-replay show -g mygroup --mi myinstance -n mymanageddb

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.

Zatrzymaj migrację (opcjonalnie)

Jeśli musisz zatrzymać migrację, użyj programu PowerShell lub interfejsu wiersza polecenia platformy Azure. Zatrzymanie migracji powoduje usunięcie przywracającej bazy danych w wystąpieniu zarządzanym, więc wznowienie migracji nie będzie możliwe.

Aby zatrzymać proces migracji za pomocą programu PowerShell, użyj następującego polecenia:

Stop-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
    -InstanceName "ManagedInstance01" `
    -Name "ManagedDatabaseName"

Aby zatrzymać proces migracji za pośrednictwem interfejsu wiersza polecenia platformy Azure, użyj następującego polecenia:

az sql midb log-replay stop -g mygroup --mi myinstance -n mymanageddb

Ukończ migrację (tryb ciągły)

Jeśli uruchamiasz magazyn LRS w trybie ciągłym, upewnij się, że obciążenie aplikacji i programu SQL Server zostało zatrzymane, aby zapobiec generowaniu nowych plików kopii zapasowych. Upewnij się, że ostatnia kopia zapasowa z wystąpienia programu SQL Server została przekazana na konto usługi Azure Blob Storage. Monitoruj postęp przywracania w wystąpieniu zarządzanym i upewnij się, że ostatnia kopia zapasowa dziennika została przywrócona.

Po przywróceniu ostatniej kopii zapasowej dziennika w wystąpieniu zarządzanym zainicjuj ręczne przejście jednorazowe, aby ukończyć migrację. Po zakończeniu migracji jednorazowej baza danych stanie się dostępna do odczytu i zapisu w wystąpieniu zarządzanym.

Aby ukończyć proces migracji w trybie ciągłym LRS za pomocą programu PowerShell, użyj następującego polecenia:

Complete-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
-InstanceName "ManagedInstance01" `
-Name "ManagedDatabaseName" `
-LastBackupName "last_backup.bak"

Aby ukończyć proces migracji w trybie ciągłym LRS za pośrednictwem interfejsu wiersza polecenia platformy Azure, użyj następującego polecenia:

az sql midb log-replay complete -g mygroup --mi myinstance -n mymanageddb --last-backup-name "backup.bak"

Ograniczenia

Podczas migracji z magazynem LRS należy wziąć pod uwagę następujące ograniczenia:

  • Nie można używać baz danych, które są przywracane za pośrednictwem magazynu LRS do momentu zakończenia procesu migracji.
  • Podczas procesu migracji migrowane bazy danych nie mogą być używane do dostępu tylko do odczytu w usłudze SQL Managed Instance.
  • Po zakończeniu migracji proces migracji jest końcowy i nie można go wznowić z dodatkowymi różnicowymi kopiami zapasowymi.
  • Magazyn LRS obsługuje tylko bazy danych .bak, .logi .diff pliki. Pliki Dacpac i bacpac nie są obsługiwane.
  • Należy skonfigurować okno obsługi, aby zaplanować aktualizacje 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 CHECKSUMpolecenia :
    • potencjalnie może migrować uszkodzone bazy danych.
    • przywracanie kopii zapasowych bazy danych z włączoną obsługą CHECKSUM trwa dłużej.
  • 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ć Read tylko uprawnienia i List . Jeśli na przykład przyznasz Readuprawnienia , Listi Write , nie można uruchomić magazynu LRS z powodu dodatkowych Write uprawnień.
  • 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.
  • Przekazywanie tysięcy plików bazy danych do przywrócenia może prowadzić do nadmiernego czasu migracji, a nawet niepowodzenia. Skonsoliduj bazy danych w mniej plików, aby przyspieszyć proces migracji i zapewnić jej sukces.
  • Istnieją dwa scenariusze, na początku i na końcu procesu migracji, w których migracja jest przerywana w przypadku przejścia w tryb failover, a zadanie migracji musi zostać ręcznie uruchomione ponownie od początku, ponieważ baza danych jest usuwana z Zarządzanych wystąpień SQL.
    • Jeśli przejście w tryb failover nastąpi, gdy pierwsza pełna kopia zapasowa bazy danych jest w trakcie przywracania do usługi SQL Managed Instance po pierwszym uruchomieniu zadania migracji, zadanie migracji musi zostać ręcznie uruchomione ponownie od początku.
    • Jeśli przełączenie na tryb awaryjny nastąpi po zainicjowaniu przełączenia migracji, zadanie migracji musi zostać ręcznie uruchomione ponownie od początku. Upewnij się, że ostatni plik kopii zapasowej jest tak mały, jak to możliwe, aby zminimalizować czas przełączenia i zmniejszyć ryzyko awarii w trybie failover podczas procesu przełączenia.

Uwaga

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 wystąpienia zarządzanego jako zalecanego rozwiązania do migracji.

Ograniczenia dotyczące migracji do warstwy usługi Krytyczne dla działania firmy

Podczas migracji do usługi SQL Managed Instance w warstwie usługi Krytyczne dla działania firmy należy wziąć pod uwagę następujące ograniczenia:

  • Podczas migracji dużych baz danych może wystąpić znaczny przestój, ponieważ bazy danych są niedostępne po przejściu jednorazowym, podczas gdy bazy danych są rozmieszczane do replik pomocniczych warstwy usługi Krytyczne dla działania firmy. Obejścia są wymienione w dłuższej sekcji migracji jednorazowej.
  • Migracja jest automatycznie uruchamiana ponownie od początku, jeśli migracja zostanie przerwana przez nieplanowane przejście w tryb failover, aktualizację systemu lub poprawkę zabezpieczeń, co utrudnia zaplanowanie przewidywalnej migracji bez niespodzianek z ostatniej chwili.

Ważne

Te ograniczenia mają zastosowanie tylko w przypadku migracji do warstwy usługi Krytyczne dla działania firmy, a nie do warstwy usługi Ogólnego przeznaczenia.

Dłuższe przecięcie w warstwie usługi Krytyczne dla działania firmy

Jeśli przeprowadzasz migrację do wystąpienia zarządzanego SQL w warstwie usługi Krytyczne dla działania firmy, należy uwzględnić opóźnienie przenoszenia baz danych w tryb online na replikę podstawową podczas ich rozmieszczania do replik pomocniczych. Dotyczy to szczególnie większych baz danych.

Migracja do wystąpienia zarządzanego SQL w warstwie usługi Krytyczne dla działania firmy trwa dłużej niż w warstwie usługi Ogólnego przeznaczenia. Po zakończeniu migracji jednorazowej na platformę Azure bazy danych są niedostępne, dopóki nie zostaną rozstawione z repliki podstawowej do trzech replik pomocniczych, co może zająć dłuższy czas w zależności od rozmiaru bazy danych. Większa baza danych, dłuższe rozmieszczanie replik pomocniczych trwa - potencjalnie do kilku godzin.

Jeśli ważne jest, aby bazy danych są dostępne zaraz po zakończeniu migracji jednorazowej, rozważ następujące obejścia:

  • Najpierw przeprowadź migrację do warstwy usługi Ogólnego przeznaczenia, a następnie uaktualnij ją do warstwy usługi Krytyczne dla działania firmy. Uaktualnienie warstwy usługi to operacja online, która utrzymuje bazy danych w trybie online do czasu krótkiego przejścia w tryb failover jako ostatniego kroku operacji uaktualniania.
  • Użyj linku wystąpienia zarządzanego, aby przeprowadzić migrację online do wystąpienia Krytyczne dla działania firmy bez konieczności oczekiwania na dostępność baz danych po zakończeniu migracji jednorazowej.

Rozwiązywanie problemów z magazynem LRS

Po uruchomieniu magazynu LRS użyj jednego z następujących poleceń cmdlet monitorowania, aby wyświetlić stan trwającej operacji:

  • W przypadku programu PowerShell: get-azsqlinstancedatabaselogreplay
  • W przypadku interfejsu wiersza polecenia platformy Azure: az_sql_midb_log_replay_show

Aby przejrzeć szczegółowe informacje o operacji, która zakończyła się niepowodzeniem:

Jeśli nie można uruchomić magazynu LRS po pewnym czasie i wystąpi błąd, sprawdź, czy występują najczęstsze problemy:

  • Czy istniejąca baza danych w wystąpieniu zarządzanym ma taką samą nazwę jak baza danych, którą próbujesz przeprowadzić migrację z wystąpienia programu SQL Server? Rozwiąż ten konflikt, zmieniając nazwę jednej z baz danych.
  • Czy uprawnienia są przyznawane tylko dla tokenu sygnatury dostępu współdzielonego tylko do odczytu i listy? Udzielanie większej liczby uprawnień niż Read i List spowoduje niepowodzenie magazynu LRS.
  • Czy skopiowano token SAS dla magazynu LRS po znaku zapytania (?) z zawartością, która wygląda następująco sv=2020-02-10...?
  • Czy czas ważności tokenu SAS jest odpowiedni dla przedziału czasu rozpoczęcia i zakończenia migracji? Mogą wystąpić niezgodności z powodu różnych stref czasowych używanych do wdrożenia usługi SQL Managed Instance i tokenu SAS. Spróbuj ponownie wygenerować token SAS i przedłużyć ważność tokenu przedziału czasu przed bieżącą datą i po tej dacie.
  • Podczas uruchamiania wielu operacji ponownego odtwarzania dziennika równolegle przeznaczonych dla tego samego kontenera magazynu upewnij się, że dla każdej operacji przywracania jest udostępniany ten sam prawidłowy token SAS.
  • Czy nazwa bazy danych, nazwa grupy zasobów i nazwa wystąpienia zarządzanego są poprawne?
  • Jeśli uruchomiono magazyn LRS w trybie autouzupełniania, czy określono prawidłową nazwę pliku dla ostatniego pliku kopii zapasowej?
  • Czy ścieżka identyfikatora URI kopii zapasowej zawiera słowa kluczowe backup lub backups? Zmień nazwę kontenera lub folderów, których używasz backup , lub backups ponieważ są to zastrzeżone słowa kluczowe.

Następne kroki