Migrowanie baz danych z programu SQL Server przy użyciu usługi ponownego odtwarzania dzienników — Azure SQL Managed Instance
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
- Aparat obliczeniowy Google
- Cloud SQL for SQL Server — GCP (Google Cloud Platform)
Wymagania wstępne
Przed rozpoczęciem należy wziąć pod uwagę następujące wymagania dotyczące zarówno wystąpienia programu SQL Server, jak i platformy Azure.
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.
Mimo że CHECKSUM włączenie obsługi kopii zapasowych nie jest wymagane, zdecydowanie zalecamy jej szybsze operacje 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 do odczytu i listy wygenerowanymi dla kontenera usługi Blob Storage lub tożsamością zarządzaną, która może uzyskiwać dostęp do kontenera.
- 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:
- Rola Wystąpienie zarządzane SQL — współautor
- Rola z następującym uprawnieniem:
Microsoft.Sql/managedInstances/databases/*
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 umożliwić planowanie aktualizacji systemu w określonym dniu i o określonej godzinie. Ta konfiguracja pomaga osiągnąć bardziej przewidywalny czas migracji bazy danych, ponieważ uaktualnienia systemu mogą przerywać migracje w toku.
- 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 przyspieszyć przywracanie bazy danych, włącz
CHECKSUMje podczas tworzenia kopii zapasowych. Usługa SQL Managed Instance przeprowadza sprawdzanie integralności kopii zapasowych bezCHECKSUMfunkcji , co zwiększa czas przywracania.
Aktualizacje systemu dla usługi SQL Managed Instance mają pierwszeństwo przed migracjami baz danych w toku. Podczas aktualizacji systemu w wystąpieniu 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.
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.
Ważne
- 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.
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:
- Create a storage account (Tworzenie konta magazynu).
- 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:
Przejdź do wystąpienia zarządzanego w witrynie Azure Portal i wybierz podsieć, aby otworzyć stronę Podsieci .
Na stronie Podsieci wybierz nazwę podsieci, aby otworzyć stronę konfiguracji podsieci.
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 .
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.
Na karcie Zapory i sieci wirtualne dla konta magazynu wybierz pozycję +Dodaj istniejącą sieć wirtualną, aby otworzyć stronę Dodawanie sieci.
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:
W witrynie Azure Portal otwórz Eksplorator usługi Storage.
Rozwiń węzeł Kontenery obiektów blob.
Kliknij prawym przyciskiem myszy kontener obiektów blob, a następnie wybierz pozycję Pobierz sygnaturę dostępu współdzielonego.
Wybierz przedział czasu wygaśnięcia tokenu. Upewnij się, że token jest prawidłowy podczas migracji.
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.
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.
Wybierz pozycję 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:
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:
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:
Skopiuj pierwszą część tokenu z
https://maksymalnie do, ale nie uwzględniając znaku zapytania (?). Użyj go jako parametruStorageContainerUriw programie PowerShell lub interfejsie wiersza polecenia platformy Azure podczas uruchamiania magazynu LRS.
Skopiuj drugą część tokenu z znaku zapytania (
?) na końcu ciągu. Użyj go jako parametruStorageContainerSasTokenw programie PowerShell lub interfejsie wiersza polecenia platformy Azure podczas uruchamiania magazynu LRS.
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 zalecamy.
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:
- Pobierz i zainstaluj narzędzie AzCopy.
- Pobierz i zainstaluj Eksplorator usługi Azure Storage.
- Użyj Eksplorator usługi Storage w witrynie Azure Portal.
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 migracji wielu baz danych magazyn LRS musi być uruchamiany oddzielnie dla każdej bazy danych i wskazywać pełną ścieżkę identyfikatora URI kontenera usługi Azure Blob Storage i pojedynczego folderu bazy danych.
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ć postęp migracji za pomocą programu PowerShell, użyj następującego polecenia:
Get-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
-InstanceName "ManagedInstance01" `
-Name "ManagedDatabaseName"
Aby monitorować 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
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"
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 operacji:
- W przypadku programu PowerShell:
get-azsqlinstancedatabaselogreplay - W przypadku interfejsu wiersza polecenia platformy Azure:
az_sql_midb_log_replay_show
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?
- Czy skopiowano token SAS dla magazynu LRS po znaku zapytania (
?) z zawartością, która wygląda następującosv=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
backuplubbackups? Zmień nazwę kontenera lub folderów, których używaszbackup, lubbackupsponieważ są to zastrzeżone słowa kluczowe.
Następne kroki
- Dowiedz się więcej na temat migracji do usługi Azure SQL Managed Instance przy użyciu funkcji linku.
- Dowiedz się więcej o migracji z programu SQL Server do usługi Azure 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.
Opinia
Dostępne już wkrótce: W 2024 r. będziemy stopniowo wycofywać zgłoszenia z serwisu GitHub jako mechanizm przesyłania opinii na temat zawartości i zastępować go nowym systemem opinii. Aby uzyskać więcej informacji, sprawdź: https://aka.ms/ContentUserFeedback.
Prześlij i wyświetl opinię dla