Adatbázisok migrálása AZ SQL Serverről a Log Replay Service használatával – Felügyelt Azure SQL-példány

A következőre vonatkozik: Felügyelt Azure SQL-példány

Ez a cikk azt ismerteti, hogyan migrálhat adatbázisokat felügyelt Azure SQL-példányba a Log Replay Service (LRS) használatával. Az LRS egy ingyenes felhőszolgáltatás, amely az SQL Server naplózási technológiáján alapuló felügyelt Azure SQL-példányhoz érhető el.

Az alábbi források támogatottak:

  • SQL Server on Virtual Machines
  • Amazon EC2 (Elastic Compute Cloud)
  • Amazon RDS (Relációsadatbázis-szolgáltatás) az SQL Serverhez
  • Google Compute Engine
  • Cloud SQL az SQL Serverhez – GCP (Google Cloud Platform)

Előfeltételek

Mielőtt hozzákezdene, fontolja meg a következő követelményeket az SQL Server-példányra és az Azure-ra vonatkozóan is.

SQL Server

Győződjön meg arról, hogy megfelel az SQL Server következő követelményeinek:

  • Az SQL Server 2008–2022-ben készült verziói.
  • Az SQL Server-adatbázis a teljes helyreállítási modellt használja (kötelező).
  • Adatbázisok teljes biztonsági mentése (egy vagy több fájl).
  • Különbségi biztonsági mentés (egy vagy több fájl).
  • Napló biztonsági mentése (tranzakciónapló-fájl esetében nem osztott).
  • Az SQL Server 2008–2016-os verzióihoz készítsen helyi biztonsági másolatot, és töltse fel manuálisan az Azure Blob Storage-fiókba.
  • Az SQL Server 2016-os és újabb verziói esetében a biztonsági mentést közvetlenül az Azure Blob Storage-fiókba is elvégezheti.

CHECKSUM Bár a biztonsági mentések engedélyezésére nincs szükség, javasoljuk, hogy gyorsabb visszaállítási műveletekhez.

Azure

Győződjön meg arról, hogy megfelel az Azure következő követelményeinek:

  • A PowerShell Az.SQL 4.0.0-s vagy újabb modulverziója (az Azure Cloud Shellen keresztül telepítve vagy érhető el).
  • Az Azure CLI 2.42.0-s vagy újabb verziója (telepítve).
  • Kiépített Azure Blob Storage-tároló.
  • A Blob Storage-tárolóhoz létrehozott olvasási és listázási engedélyekkel rendelkező közös hozzáférésű jogosultságkód (SAS) biztonsági jogkivonat, vagy egy felügyelt identitás, amely hozzáfér a tárolóhoz.
  • Helyezzen biztonsági mentési fájlokat egy önálló adatbázishoz egy tárfiók külön mappájába egy egybesimított (kötelező) struktúra használatával. A mappák adatbázismappákba való beágyazása nem támogatott.

Azure RBAC-engedélyek

Az LRS a megadott ügyfeleken keresztül történő futtatásához az alábbi Azure-szerepköralapú hozzáférés-vezérlési (RBAC-) szerepkörök egyikére van szükség:

Ajánlott eljárások

LRS használata esetén vegye figyelembe az alábbi ajánlott eljárásokat:

  • Futtassa a Data Migration Assistantet annak ellenőrzéséhez, hogy az adatbázisok készen állnak-e a felügyelt SQL-példányba való migrálásra.
  • A teljes és különbségi biztonsági mentéseket több fájlra oszthatja egyetlen fájl helyett.
  • Engedélyezze a biztonsági másolatok tömörítését a hálózati átviteli sebesség növelése érdekében.
  • PowerShell- vagy CLI-szkriptek futtatásához használja a Cloud Shellt, mert az mindig a legújabb kiadott parancsmagok használatára lesz frissítve.
  • Konfiguráljon egy karbantartási időszakot , amely lehetővé teszi a rendszerfrissítések ütemezését egy adott napon és időpontban. Ez a konfiguráció segít kiszámíthatóbb időt elérni az adatbázis-áttelepítésekhez, mivel a rendszerfrissítések megszakíthatják a folyamatban lévő migrálásokat.
  • Tervezze meg, hogy egy LRS-áttelepítési feladatot legfeljebb 30 napon belül végrehajt. Ezen időkeret lejártakor a rendszer automatikusan megszakítja az LRS-feladatot.
  • A gyorsabb adatbázis-visszaállítás érdekében engedélyezze CHECKSUM a biztonsági másolatok készítését. A felügyelt SQL-példány integritás-ellenőrzést végez a biztonsági másolatokon CHECKSUManélkül, ami növeli a visszaállítási időt.

A felügyelt SQL-példány rendszerfrissítései elsőbbséget élveznek a folyamatban lévő adatbázis-áttelepítésekkel szemben. Egy példány rendszerfrissítése során a rendszer csak a frissítés alkalmazása után függeszti fel és folytatja az összes függőben lévő LRS-áttelepítést. Ez a rendszer viselkedése meghosszabbíthatja a migrálási időt, különösen a nagy adatbázisok esetében.

Az adatbázis-migrálások kiszámítható idejének elérése érdekében érdemes konfigurálni egy karbantartási időszakot a rendszerfrissítések ütemezéséhez egy adott napra és időpontra, valamint a kijelölt karbantartási időszakon kívüli áttelepítési feladatok futtatására és befejezésére.

Fontos

  • Az LRS-ben visszaállított adatbázisok csak az áttelepítési folyamat befejeződéséig használhatók.
  • Az LRS nem támogatja az adatbázisok írásvédett elérését a migrálás során.
  • Az áttelepítés befejezése után az áttelepítési folyamat végleges, és nem folytatható további különbségi biztonsági mentésekkel.

Több adatbázis migrálása

Ha több adatbázist migrál ugyanazzal az Azure Blob Storage-tárolóval, a tárolón belül külön mappákba kell helyeznie a különböző adatbázisok biztonsági mentési fájljait. Egyetlen adatbázis összes biztonsági mentési fájlját egy egybesimított struktúrába kell helyezni egy adatbázismappában, és a mappák nem ágyazhatók be. A mappák adatbázismappákba való beágyazása nem támogatott.

Íme egy példa egy Azure Blob Storage-tároló mappastruktúrájára, amely több adatbázis LRS használatával történő migrálásához szükséges.

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

Tárfiók létrehozása

Az SQL Server-példány és a felügyelt SQL-példány üzembe helyezése közötti biztonsági mentési fájlokhoz egy Azure Blob Storage-fiókot használ közvetítő tárolóként. Új tárfiók és blobtároló létrehozása a tárfiókon belül:

  1. Tárfiók létrehozása.
  2. Hozzon létre egy blobtárolót a tárfiókban.

Az Azure Storage konfigurálása tűzfal mögött

A tűzfal mögött védett Azure Blob Storage használata támogatott, de további konfigurációt igényel. Ha be van kapcsolva az Azure Storage olvasási/írási hozzáférése az Azure Firewall bekapcsolásával, hozzá kell adnia a felügyelt SQL-példány alhálózatát a tárfiók virtuális hálózatának tűzfalszabályaihoz a MI-alhálózat-delegálás és a Storage szolgáltatásvégpont használatával. A tárfióknak és a felügyelt példánynak ugyanabban a régióban vagy két párosított régióban kell lennie.

Ha az Azure Storage tűzfal mögött található, a következő üzenet jelenhet meg a felügyelt SQL-példány hibanaplójában:

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

Ez létrehoz egy e-mailt, amely értesíti, hogy a felügyelt SQL-példány naplózása nem tud naplókat írni a tárfiókba. Ha ezt a hibát látja, vagy megkapja ezt az e-mailt, kövesse az ebben a szakaszban leírt lépéseket a tűzfal konfigurálásához.

A tűzfal konfigurálásához kövesse az alábbi lépéseket:

  1. Nyissa meg a felügyelt példányt az Azure Portalon , és válassza ki az alhálózatot az Alhálózatok lap megnyitásához.

    Screenshot of the SQL managed instance Overview page of the Azure portal, with the subnet selected.

  2. Az Alhálózatok lapon válassza ki az alhálózat nevét az alhálózat konfigurációs lapjának megnyitásához.

    Screenshot of the SQL managed instance Subnet page of the Azure portal, with the subnet selected.

  3. Az Alhálózat-delegálás csoportban válassza a Microsoft.Sql/managedInstances elemet a Delegált alhálózatból egy szolgáltatás legördülő menüjébe. Várjon körülbelül egy órát az engedélyek propagálására, majd a Szolgáltatásvégpontok területen válassza a Microsoft.Storage lehetőséget a Szolgáltatások legördülő listából.

    Screenshot of the SQL managed instance Subnet configuration page of the Azure portal.

  4. Ezután nyissa meg a tárfiókot az Azure Portalon, válassza a Hálózatkezelés lehetőséget a Biztonság + hálózatkezelés területen, majd válassza a Tűzfalak és virtuális hálózatok lapot.

  5. A tárfiók Tűzfalak és virtuális hálózatok lapján válassza a +Meglévő virtuális hálózat hozzáadása lehetőséget a Hálózatok hozzáadása lap megnyitásához.

    Screenshot of the Storage Account Networking page of the Azure portal, with Add existing virtual network selected.

  6. Válassza ki a megfelelő előfizetést, virtuális hálózatot és felügyelt példány alhálózatot a legördülő menüből, majd válassza a Hozzáadás lehetőséget a felügyelt SQL-példány virtuális hálózatának a tárfiókhoz való hozzáadásához.

Hitelesítés a Blob Storage-fiókban

Sas-jogkivonat vagy felügyelt identitás használata az Azure Blob Storage-fiók eléréséhez.

Figyelmeztetés

Nem használhat sas-jogkivonatot és felügyelt identitást párhuzamosan ugyanazon a tárfiókon. SAS-jogkivonatot vagy felügyelt identitást is használhat, de mindkettőt nem.

Blob Storage SAS hitelesítési jogkivonat létrehozása LRS-hez

Az Azure Blob Storage-fiók elérése SAS-jogkivonat használatával.

Egy Azure Blob Storage-fiókot használhat közbenső tárolóként az SQL Server-példány és a felügyelt SQL-példány üzembe helyezése közötti biztonsági mentési fájlokhoz. Hozzon létre egy SAS-hitelesítési jogkivonatot az LRS-hez csak olvasási és listázási engedélyekkel. A jogkivonat lehetővé teszi az LRS számára, hogy hozzáférjen a Blob Storage-fiókhoz, és a biztonsági mentési fájlokkal visszaállítja őket a felügyelt példányra.

A jogkivonat létrehozásához kövesse az alábbi lépéseket:

  1. Az Azure Portalon nyissa meg a Storage Explorert.

  2. Bontsa ki a Blob-tárolókat.

  3. Kattintson a jobb gombbal a blobtárolóra, majd válassza a Közös hozzáférésű jogosultságkód lekérése lehetőséget.

    Screenshot that shows selections for generating a SAS authentication token.

  4. Válassza ki a jogkivonat lejáratának időkeretét. Győződjön meg arról, hogy a jogkivonat érvényes a migrálás során.

  5. Válassza ki a jogkivonat időzónáját: UTC vagy helyi idő.

    Fontos

    Előfordulhat, hogy a jogkivonat és a felügyelt példány időzónája nem egyezik. Győződjön meg arról, hogy az SAS-jogkivonat érvényessége megfelelő, figyelembe véve az időzónákat. Az időzóna eltéréseinek figyelembe vételéhez állítsa be a FROM értéket jóval a migrálási időszak kezdete előtt, a TO értéket pedig jóval az áttelepítés befejezése után.

  6. Csak olvasási és listaengedélyek kiválasztása.

    Fontos

    Ne válasszon ki más engedélyeket. Ha igen, az LRS nem indul el. Ez a biztonsági követelmény eleve így van megtervezve.

  7. Válassza a Létrehozás lehetőséget.

    Screenshot that shows selections for SAS token expiration, time zone, and permissions, along with the Create button.

A SAS-hitelesítés a megadott időtartammal jön létre. Szüksége van a jogkivonat URI-verziójára, ahogyan az az alábbi képernyőképen látható:

Screenshot that shows an example of the URI version of a SAS token.

Feljegyzés

A tárolt hozzáférési szabályzat definiálásával beállított engedélyekkel létrehozott SAS-jogkivonatok használata jelenleg nem támogatott. Kövesse az eljárás utasításait az SAS-jogkivonat olvasási és listázási engedélyeinek manuális megadásához.

Paraméterek másolása az SAS-jogkivonatból

Az Azure Blob Storage-fiók elérése SAS-jogkivonat vagy felügyelt identitás használatával.

Mielőtt az SAS-jogkivonatot használné az LRS elindításához, ismernie kell annak szerkezetét. A létrehozott SAS-jogkivonat URI-ja két részből áll, egy kérdőjellel (?) elválasztva, ahogyan az ebben a példában látható:

Example URI for a generated SAS token for Log Replay Service.

Az első rész, kezdve https:// a kérdőjel (?) használatával az StorageContainerURI LRS bemeneteként táplált paraméterhez. LRS-információkat ad arról a mappáról, amelyben az adatbázis biztonsági mentési fájljai találhatók.

A második rész a kérdőjel (?) utántól a sztring végéig a StorageContainerSasToken paraméter. Ez a rész a tényleges aláírt hitelesítési jogkivonat, amely a megadott idő alatt érvényes. Ennek a résznek nem feltétlenül kell a példában látható módon sp= kezdődnie. A forgatókönyv eltérhet.

Másolja ki a paramétereket az alábbiak szerint:

  1. Másolja ki a jogkivonat első részét a kérdőjel (?) kimásolásávalhttps://. Használja paraméterként a StorageContainerUri PowerShellben vagy az Azure CLI-ben az LRS indításakor.

    Screenshot that shows where to copy the first part of the token.

  2. Másolja ki a jogkivonat második részét a kérdőjel (?) után a sztring végéig. Használja paraméterként a StorageContainerSasToken PowerShellben vagy az Azure CLI-ben az LRS indításakor.

    Screenshot that shows where to copy the second part of the token.

Feljegyzés

Ne vegye fel a kérdőjelet (?) a jogkivonat egyik részének másolásakor.

Felügyelt példány tárhozzáférésének ellenőrzése

Ellenőrizze, hogy a felügyelt példány hozzáfér-e a Blob Storage-fiókhoz.

Először töltse fel az adatbázis biztonsági mentését, például full_0_0.bakaz Azure Blob Storage-tárolóba.

Ezután csatlakozzon a felügyelt példányhoz, és futtasson egy mintateszt-lekérdezést annak megállapításához, hogy a felügyelt példány hozzáfér-e a tárolóban lévő biztonsági mentéshez.

Ha SAS-jogkivonatot használ a tárfiók hitelesítéséhez, cserélje le az <sastoken> SAS-jogkivonatot, és futtassa a következő lekérdezést a példányon:

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' 

Biztonsági másolatok feltöltése Blob Storage-fiókba

Ha a blobtároló készen áll, és megerősítette, hogy a felügyelt példány hozzáfér a tárolóhoz, megkezdheti a biztonsági másolatok feltöltését a Blob Storage-fiókba. A következő lehetőségek közül választhat:

  • Másolja a biztonsági másolatokat a Blob Storage-fiókba.
  • Készítsen biztonsági másolatot az SQL Serverről közvetlenül a Blob Storage-fiókba a BACKUP TO URL paranccsal, ha a környezet engedélyezi (az SQL Server 2012 SP1 CU2 és AZ SQL Server 2014-től kezdve).

Meglévő biztonsági másolatok másolása a Blob Storage-fiókba

Ha az SQL Server egy korábbi verzióján dolgozik, vagy ha a környezete nem támogatja közvetlenül az URL-címre történő biztonsági mentést, készítsen biztonsági másolatot az SQL Server-példányról, ahogyan azt általában tenné, majd másolja őket a Blob Storage-fiókjába.

Biztonsági mentések készítése SQL Server-példányon

Állítsa be a teljes helyreállítási modellbe migrálni kívánt adatbázisokat a naplók biztonsági mentésének engedélyezéséhez.

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

Az adatbázis teljes, differenciált és naplóalapú biztonsági mentésének helyi tárolóba történő manuális létrehozásához használja az alábbi T-SQL-példaszkripteket. CHECKSUM nem kötelező, de javasoljuk.

Az alábbi példa teljes adatbázis-biztonsági mentést készít a helyi lemezre:

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

Az alábbi példa egy különbségi biztonsági másolatot készít a helyi lemezről:

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

Az alábbi példa egy tranzakciónapló biztonsági mentését végzi a helyi lemezre:

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

Biztonsági másolatok másolása a Blob Storage-fiókba

Miután elkészültek a biztonsági másolatok, és megkezdheti az adatbázisok felügyelt példányba való migrálását az LRS használatával, a következő módszerekkel másolhatja a meglévő biztonsági másolatokat a Blob Storage-fiókba:

Feljegyzés

Ha több adatbázist szeretne migrálni ugyanazzal az Azure Blob Storage-tárolóval, helyezze az egyes adatbázisok biztonsági mentési fájljait egy külön mappába a tárolón belül. Használjon egy-egy fájlstruktúrát az egyes adatbázismappákhoz. A mappák adatbázismappákba való beágyazása nem támogatott.

Biztonsági másolatok készítése közvetlenül a Blob Storage-fiókba

Ha az SQL Server támogatott verzióján dolgozik (az SQL Server 2012 SP1 CU2-vel és az SQL Server 2014-zel kezdve), és a vállalati és hálózati házirendek engedélyezik, a natív SQL Server BACKUP TO URL-beállítással közvetlenül a Blob Storage-fiókba készíthet biztonsági másolatot az SQL Serverről. Ha használhatja BACKUP TO URL, nem kell biztonsági másolatot készítenie a helyi tárterületre, és fel kell töltenie őket a Blob Storage-fiókjába.

Ha közvetlenül a Blob Storage-fiókba készít natív biztonsági mentéseket, hitelesítést kell végeznie a tárfiókban.

Az alábbi paranccsal hozzon létre egy hitelesítő adatot, amely importálja az SAS-jogkivonatot az SQL Server-példányba:

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

Az SAS-jogkivonatokkal kapcsolatos részletes utasításokért tekintse át az Azure Blob Storage használata az SQL Serverrel című oktatóanyagot.

Miután létrehozta a hitelesítő adatokat az SQL Server-példány Blob Storage-nal való hitelesítéséhez, a BACKUP TO URL paranccsal közvetlenül a tárfiókba készíthet biztonsági másolatot. CHECKSUM ajánlott, de nem kötelező.

Az alábbi példa teljes adatbázis-biztonsági mentést készít egy URL-címre:

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

Az alábbi példa egy különbségi adatbázis biztonsági mentését hajtja végre egy URL-címre:

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

Az alábbi példa egy tranzakciónapló url-címére készít biztonsági másolatot:

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

Jelentkezzen be az Azure-ba, és válasszon egy előfizetést

A következő PowerShell-parancsmaggal jelentkezzen be az Azure-ba:

Login-AzAccount

Válassza ki azt az előfizetést, amelyben a felügyelt példány található a következő PowerShell-parancsmag használatával:

Select-AzSubscription -SubscriptionId <subscription ID>

Az áttelepítés elindítása

Indítsa el az áttelepítést az LRS elindításával. A szolgáltatást automatikus kiegészítés vagy folyamatos módban is elindíthatja.

Ha automatikus kiegészítési módot használ, az áttelepítés automatikusan befejeződik, amikor a megadott biztonsági mentési fájlok utolsó fájlját visszaállították. Ehhez a beállításhoz a teljes biztonsági mentési láncnak előre elérhetővé kell lennie, és fel kell töltenie a Blob Storage-fiókjába. Ez nem teszi lehetővé az új biztonsági mentési fájlok hozzáadását, amíg a migrálás folyamatban van. Ehhez a beállításhoz a start parancsnak meg kell adnia az utolsó biztonsági mentési fájl fájlnevét. Ezt a módot olyan passzív számítási feladatokhoz ajánljuk, amelyekhez nincs szükség adatfelzárkózásra.

Folyamatos mód használata esetén a szolgáltatás folyamatosan ellenőrzi az Azure Blob Storage mappát, és visszaállítja a migrálás során hozzáadott új biztonsági mentési fájlokat. A migrálás csak a manuális átállás kérése után fejeződik be. Folyamatos módú migrálást kell használnia, ha még nem rendelkezik a teljes biztonsági mentési lánccal, és ha az áttelepítést követően új biztonsági mentési fájlokat szeretne hozzáadni. Ezt az üzemmódot olyan aktív számítási feladatokhoz ajánljuk, amelyekhez adatfelzárkózásra van szükség.

Tervezze meg, hogy egy LRS-áttelepítési feladatot legfeljebb 30 napon belül végrehajt. Ha ez az idő lejár, a rendszer automatikusan megszakítja az LRS-feladatot.

Feljegyzés

Ha több adatbázist migrál, az LRS-t külön kell elindítani minden adatbázishoz, és az Azure Blob Storage-tároló és az egyes adatbázismappák teljes URI-útvonalára kell mutatnia.

LRS indítása automatikus kiegészítési módban

Győződjön meg arról, hogy a teljes biztonsági mentési lánc fel lett töltve az Azure Blob Storage-fiókba. Ez a beállítás nem teszi lehetővé az új biztonsági mentési fájlok hozzáadását a migrálás során.

Ha automatikus kiegészítési módban szeretné elindítani az LRS-t, használja a PowerShell vagy az Azure CLI parancsait. Adja meg az utolsó biztonsági mentési fájl nevét a -LastBackupName paraméterrel. Miután az utolsó megadott biztonsági mentési fájl visszaállítása befejeződött, a szolgáltatás automatikusan kezdeményezi az átállást.

Állítsa vissza az adatbázist a tárfiókból az SAS-jogkivonat vagy egy felügyelt identitás használatával.

Fontos

  • Győződjön meg arról, hogy a teljes biztonsági mentési lánc fel lett töltve az Azure Blob Storage-fiókba, mielőtt automatikus kiegészítési módban kezdené el az áttelepítést. Ez a mód nem teszi lehetővé az új biztonsági mentési fájlok hozzáadását, amíg az áttelepítés folyamatban van.
  • Győződjön meg arról, hogy helyesen adta meg az utolsó biztonsági mentési fájlt, és hogy nem töltött fel több fájlt utána. Ha a rendszer több biztonsági mentési fájlt észlel az utolsó megadott biztonsági mentési fájlon túl, az áttelepítés sikertelen lesz.

Az alábbi PowerShell-példa automatikus kiegészítési módban indítja el az LRS-t EGY SAS-jogkivonat használatával:

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"

Az alábbi Azure CLI-példa automatikus kiegészítési módban indítja el az LRS-t EGY SAS-jogkivonat használatával:

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"

LRS indítása folyamatos módban

Győződjön meg arról, hogy feltöltötte a kezdeti biztonsági mentési láncot az Azure Blob Storage-fiókjába.

Fontos

Miután elindította az LRS-t folyamatos módban, a manuális átállásig új naplókat és különbségi biztonsági másolatokat adhat hozzá a tárfiókhoz. A manuális átállás kezdeményezése után nem lehet további különbségfájlokat hozzáadni vagy visszaállítani.

Az alábbi PowerShell-példa egy SAS-jogkivonat használatával indítja el az LRS-t folyamatos módban:

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"

Az alábbi Azure CLI-példa folyamatos módban indítja el az LRS-t:

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"

Az áttelepítési feladat szkriptje

A folyamatos módban LRS-t kezdő PowerShell- és Azure CLI-ügyfelek szinkronban vannak. Ebben a módban a PowerShell és az Azure CLI megvárja, amíg az API-válasz sikeres vagy sikertelen lesz a feladat megkezdése előtt.

A várakozás során a parancs nem adja vissza a vezérlőt a parancssornak. Ha a migrálási felületet szkripteli, és az LRS indítási parancsára van szüksége ahhoz, hogy azonnal visszavezhesse az irányítást a szkript többi részével való folytatáshoz, a Kapcsolóval háttérfeladatként futtathatja a -AsJob PowerShellt. Példa:

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

Háttérfeladat indításakor a feladatobjektum azonnal visszatér, még akkor is, ha a feladat hosszabb időt vesz igénybe. A munkamenetben megszakítás nélkül folytathatja a munkát, amíg a feladat fut. A PowerShell háttérfeladatként való futtatásával kapcsolatos részletekért tekintse meg a PowerShell Start-Job dokumentációját.

Hasonlóképpen, ha háttérfolyamatként szeretne elindítani egy Azure CLI-parancsot Linuxon, használja az ampersand (&) parancsot az LRS indítási parancsának végén:

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

A migrálás előrehaladásának monitorozása

Az.SQL 4.0.0-s és újabb verziói részletes állapotjelentést nyújtanak. A felügyelt adatbázis-visszaállítás részleteinek áttekintése – Mintakimenet lekérése .

Az áttelepítési folyamat PowerShell-lel történő monitorozásához használja a következő parancsot:

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

A migrálás előrehaladásának az Azure CLI-vel való monitorozásához használja a következő parancsot:

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

Az áttelepítés leállítása (nem kötelező)

Ha le kell állítania a migrálást, használja a PowerShellt vagy az Azure CLI-t. Az áttelepítés leállítása törli a helyreállító adatbázist a felügyelt példányon, így az áttelepítés folytatása nem lehetséges.

Az áttelepítési folyamat PowerShell-lel való leállításához használja a következő parancsot:

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

A migrálási folyamat Azure CLI-vel történő leállításához használja a következő parancsot:

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

A migrálás befejezése (folyamatos mód)

Ha folyamatos módban indítja el az LRS-t, győződjön meg arról, hogy az alkalmazás és az SQL Server számítási feladatai le lettek állítva, hogy megakadályozzák az új biztonsági mentési fájlok létrehozásának megakadályozását. Győződjön meg arról, hogy az SQL Server-példány legutóbbi biztonsági mentése fel lett töltve az Azure Blob Storage-fiókba. Monitorozza a felügyelt példány visszaállítási állapotát, és győződjön meg arról, hogy az utolsó naplófájl biztonsági mentése vissza lett állítva.

Ha az utolsó naplószéles biztonsági mentést visszaállították a felügyelt példányon, indítsa el a manuális átállást az áttelepítés befejezéséhez. Az átállás befejezése után az adatbázis elérhetővé válik olvasási és írási hozzáféréshez a felügyelt példányon.

Ha az áttelepítési folyamatot folyamatos LRS módban szeretné végrehajtani a PowerShell-lel, használja a következő parancsot:

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

A migrálási folyamat folyamatos LRS-módban való befejezéséhez az Azure CLI-vel hajtsa végre a következő parancsot:

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

LRS-problémák elhárítása

Az LRS elindítása után a következő monitorozási parancsmagok egyikével tekintheti meg a művelet állapotát:

  • PowerShell esetén: get-azsqlinstancedatabaselogreplay
  • Az Azure CLI esetében: az_sql_midb_log_replay_show

Ha az LRS egy idő után nem indul el, és hibaüzenet jelenik meg, ellenőrizze a leggyakoribb problémákat:

  • A felügyelt példányon lévő meglévő adatbázis neve megegyezik az SQL Server-példányról migrálni kívánt adatbázis nevével? Ezt az ütközést az egyik adatbázis átnevezésével oldhatja fel.
  • Az SAS-jogkivonat csak olvasási és listázási engedélyekkel rendelkezik?
  • Kimásolta az LRS SAS-jogkivonatát a kérdőjel (?) után a következő sv=2020-02-10...tartalommal? 
  • Az SAS-jogkivonat érvényességi ideje megfelelő a migrálás megkezdésének és befejezésének időkeretéhez? A felügyelt SQL-példány üzembe helyezéséhez használt különböző időzónák és az SAS-jogkivonat eltérőek lehetnek. Próbálja meg újragenerálni az SAS-jogkivonatot, és kiterjeszteni az aktuális dátum előtti és utáni időablak jogkivonat-érvényességét.
  • Ha egyszerre több naplóvisszajátszási visszaállítást indít ugyanazon tárolóval párhuzamosan, győződjön meg arról, hogy minden visszaállítási művelethez ugyanaz az érvényes SAS-jogkivonat van megadva.
  • Helyesen írja be az adatbázis nevét, az erőforráscsoport nevét és a felügyelt példány nevét?
  • Ha automatikus kiegészítési módban indította el az LRS-t, a legutóbbi biztonsági mentési fájl érvényes fájlneve volt?
  • A biztonsági mentési URI elérési útja tartalmaz kulcsszavakat backup vagy backups? Nevezze át a használt backup tárolót vagy mappákat, vagy backups mivel ezek fenntartott kulcsszavak.

Következő lépések