Erőforrások áthelyezése új régióba – Azure SQL Database és Azure SQL Managed Instance

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

Ez a cikk bemutatja, hogyan helyezheti át az adatbázist vagy a felügyelt példányt egy új régióba.

Áttekintés

Különböző helyzetekben szeretné áthelyezni a meglévő adatbázist vagy felügyelt példányt egyik régióból a másikba. Például egy új régióra bővíti vállalkozását, és az új ügyfélbázishoz szeretné optimalizálni. Vagy megfelelőségi okokból át kell helyeznie a műveleteket egy másik régióba. Vagy az Azure kiadott egy új régiót, amely jobb közelséget biztosít, és javítja az ügyfélélményt.

Ez a cikk általános munkafolyamatot biztosít az erőforrások másik régióba való áthelyezéséhez. A munkafolyamat a következő lépésekből áll:

1. Ellenőrizze az áthelyezés előfeltételeit.
2. Készüljön fel az erőforrások hatókörben való áthelyezésére.
3. Az előkészítési folyamat figyelése.
4. Tesztelje az áthelyezési folyamatot.
5. Indítsa el a tényleges áthelyezést.
6. Távolítsa el az erőforrásokat a forrásrégióból.

Megjegyzés:

Ez a cikk az Azure nyilvános felhőn vagy ugyanazon szuverén felhőn belüli migrálásokra vonatkozik.

Megjegyzés:

Ha az Azure SQL-adatbázisokat és a rugalmas készleteket egy másik Azure-régióba szeretné áthelyezni, használhatja az Azure Resource Movert is (ajánlott). Ebben az oktatóanyagban részletes lépéseket talál a lépések végrehajtásához.

Megjegyzés:

Ez a cikk az Azure Az PowerShell-modult használja, amely az Azure-ral való interakcióhoz ajánlott PowerShell-modul. Az Az PowerShell-modul használatának megkezdéséhez lásd az Azure PowerShell telepítését ismertető szakaszt. To learn how to migrate to the Az PowerShell module, see Migrate Azure PowerShell from AzureRM to Az.

Adatbázis áthelyezése

Verify prerequisites

1. Hozzon létre egy célkiszolgálót minden forráskiszolgálóhoz.

2. Konfigurálja a tűzfalat a megfelelő kivételekkel a PowerShell használatával.

3. Konfigurálja a kiszolgálókat a megfelelő bejelentkezésekkel. Ha nem Ön az előfizetés rendszergazdája vagy az SQL Server rendszergazdája, a rendszergazdával együttműködve rendelje hozzá a szükséges engedélyeket. További információ: Az Azure SQL Database biztonságának kezelése vészhelyreállítás után.

4. Ha az adatbázisok transzparens adattitkosítással (TDE) vannak titkosítva, és saját titkosítási kulcsot (BYOK vagy ügyfél által felügyelt kulcsot) használnak az Azure Key Vaultban, győződjön meg arról, hogy a megfelelő titkosítási anyag ki van építve a célrégiókban.

   • Ennek legegyszerűbb módja, ha hozzáadja a titkosítási kulcsot a meglévő kulcstartóból (amelyet a forráskiszolgálóN TDE Protectorként használnak) a célkiszolgálóhoz, majd állítsa be a kulcsot TDE Protectorként a célkiszolgálón

     Megjegyzés:

     Az egyik régióban lévő kiszolgáló vagy felügyelt példány mostantól bármely más régióban csatlakoztatható egy kulcstartóhoz.

   • Ajánlott eljárás annak biztosítása érdekében, hogy a célkiszolgáló hozzáférhessen a régebbi titkosítási kulcsokhoz (amelyek az adatbázis biztonsági mentésének visszaállításához szükségesek), futtassa a Get-AzSqlServerKeyVaultKey parancsmagot a forráskiszolgálón, vagy a Get-AzSqlInstanceKeyVaultKey parancsmagot a forrás által felügyelt példányon, hogy visszaadja az elérhető kulcsok listáját, és hozzáadja ezeket a kulcsokat a célkiszolgálóhoz.
   • Az ügyfél által felügyelt TDE célkiszolgálón való konfigurálásával kapcsolatos további információkért és ajánlott eljárásokért tekintse meg az Azure SQL transzparens adattitkosítását ügyfél által felügyelt kulcsokkal az Azure Key Vaultban.
   • A kulcstartó áthelyezése az új régióba: Azure-kulcstartó áthelyezése régiók között

5. Ha az adatbázisszintű naplózás engedélyezve van, tiltsa le, és engedélyezze inkább a kiszolgálószintű naplózást. A feladatátvétel után az adatbázisszintű naplózás megköveteli a régiók közötti forgalmat, ami az áthelyezés után nem kívánatos vagy lehetséges.

6. Kiszolgálószintű naplózás esetén győződjön meg arról, hogy:

   • A tároló, a Log Analytics vagy az eseményközpont a meglévő naplózási naplókkal a célrégióba kerül.
   • A naplózás a célkiszolgálón van konfigurálva. További információ: Ismerkedés az SQL Database naplózásával.

7. Ha a példány hosszú távú adatmegőrzési szabályzattal (LTR) rendelkezik, a meglévő LTR biztonsági másolatok továbbra is az aktuális kiszolgálóhoz lesznek társítva. Mivel a célkiszolgáló eltérő, a forráskiszolgáló használatával hozzáférhet a forrásrégió régebbi LTR-biztonsági másolataihoz, még akkor is, ha a kiszolgálót törölték.

   Megjegyzés:

   Ez nem elegendő a szuverén felhő és egy nyilvános régió közötti váltáshoz. Az ilyen migráláshoz az LTR biztonsági másolatait a célkiszolgálóra kell áthelyezni, amely jelenleg nem támogatott.

Erőforrások előkészítése

1. Hozzon létre egy feladatátvételi csoportot a forrás kiszolgálója és a célkiszolgáló között.

2. Adja hozzá a feladatátvételi csoportba áthelyezni kívánt adatbázisokat.

   Az összes hozzáadott adatbázis replikálása automatikusan elindul. További információ: Feladatátvételi csoportok használata az SQL Database-ben.

Az előkészítési folyamat figyelése

A Get-AzSqlDatabaseFailoverGroup rendszeres időközönként meghívható az adatbázisok forrásból a célba történő replikációjának figyeléséhez. A kimeneti objektum Get-AzSqlDatabaseFailoverGroup tartalmazza a ReplicationState tulajdonságát:

• A ReplicationState = 2 (CATCH_UP) azt jelzi, hogy az adatbázis szinkronizálva van, és biztonságosan feladatátvételt végezhet.
• A ReplicationState = 0 (Standard kiadás EDING) azt jelzi, hogy az adatbázis még nincs beadva, és a feladatátvételi kísérlet sikertelen lesz.

Szinkronizálás tesztelése

A ReplicationState 2után csatlakozzon az adatbázisokhoz vagy az adatbázisok részhalmazaihoz a másodlagos végpont <fog-name>.secondary.database.windows.net használatával, és végezzen minden lekérdezést az adatbázisokon, hogy biztosítsa a kapcsolatot, a megfelelő biztonsági konfigurációt és az adatreplikálást.

Az áthelyezés kezdeményezése

1. Csatlakozás a célkiszolgálóra a másodlagos végpont <fog-name>.secondary.database.windows.nethasználatával.
2. A Switch-AzSqlDatabaseFailoverGroup használatával állítsa át a másodlagos felügyelt példányt elsődlegesként teljes szinkronizálással. Ez a művelet sikeres lesz, vagy vissza fog gördülni.
3. Ellenőrizze, hogy a parancs sikeresen nslook up <fog-name>.secondary.database.windows.net befejeződött-e annak megállapításával, hogy a DNS CNAME bejegyzés a célrégió IP-címére mutat-e. Ha a kapcsolóparancs sikertelen, a CNAME nem frissül.

A forrásadatbázisok eltávolítása

Miután az áthelyezés befejeződött, távolítsa el az erőforrásokat a forrásrégióban a szükségtelen díjak elkerülése érdekében.

1. Törölje a feladatátvételi csoportot a Remove-AzSqlDatabaseFailoverGroup használatával.
2. Törölje az egyes forrásadatbázisokat a Remove-AzSqlDatabase használatával a forráskiszolgálón lévő összes adatbázishoz. Ez automatikusan leállítja a georeplikációs kapcsolatokat.
3. Törölje a forráskiszolgálót a Remove-AzSqlServer használatával.
4. Távolítsa el a kulcstartót, a tárolók naplózását, az eseményközpontot, a Microsoft Entra-példányt és más függő erőforrásokat, hogy ne kelljen fizetniük.

Rugalmas készletek áthelyezése

Verify prerequisites

1. Hozzon létre egy célkiszolgálót minden forráskiszolgálóhoz.

2. Konfigurálja a tűzfalat a megfelelő kivételekkel a PowerShell használatával.

3. Konfigurálja a kiszolgálókat a megfelelő bejelentkezésekkel. Ha nem Ön az előfizetés rendszergazdája vagy a kiszolgáló rendszergazdája, a rendszergazdával együttműködve rendelje hozzá a szükséges engedélyeket. További információ: Az Azure SQL Database biztonságának kezelése vészhelyreállítás után.

4. Ha az adatbázisok transzparens adattitkosítással vannak titkosítva, és saját titkosítási kulcsot használnak az Azure Key Vaultban, győződjön meg arról, hogy a megfelelő titkosítási anyag ki van építve a célrégióban.

5. Hozzon létre egy cél rugalmas készletet minden forrás rugalmas készlethez, hogy a készlet ugyanabban a szolgáltatási szinten legyen létrehozva, ugyanazzal a névvel és mérettel.

6. Ha egy adatbázisszintű naplózás engedélyezve van, tiltsa le, és engedélyezze inkább a kiszolgálószintű naplózást. A feladatátvételt követően az adatbázisszintű naplózás régióközi forgalmat igényel, ami nem kívánatos, vagy az áthelyezés után lehetséges.

7. Kiszolgálószintű naplózás esetén győződjön meg arról, hogy:

   • A tároló, a Log Analytics vagy az eseményközpont a meglévő naplózási naplókkal a célrégióba kerül.
   • A naplózási konfiguráció a célkiszolgálón van konfigurálva. További információ: SQL Database-naplózás.

8. Ha a példány hosszú távú adatmegőrzési szabályzattal (LTR) rendelkezik, a meglévő LTR biztonsági másolatok továbbra is az aktuális kiszolgálóhoz lesznek társítva. Mivel a célkiszolgáló eltérő, a forráskiszolgáló használatával hozzáférhet a forrásrégió régebbi LTR-biztonsági másolataihoz, még akkor is, ha a kiszolgálót törölték.

   Megjegyzés:

   Ez nem elegendő a szuverén felhő és egy nyilvános régió közötti váltáshoz. Az ilyen migráláshoz az LTR biztonsági másolatait a célkiszolgálóra kell áthelyezni, amely jelenleg nem támogatott.

Felkészülés az áthelyezésre

1. Hozzon létre egy külön feladatátvételi csoportot a forráskiszolgáló minden rugalmas készlete és a célkiszolgáló megfelelő rugalmas készlete között.

2. Adja hozzá a készlet összes adatbázisát a feladatátvételi csoporthoz.

   A hozzáadott adatbázisok replikálása automatikusan elindul. További információ: Feladatátvételi csoportok használata az SQL Database-ben.

   Megjegyzés:

   Bár létrehozhat egy több rugalmas készletet tartalmazó feladatátvételi csoportot, javasoljuk, hogy minden készlethez külön feladatátvételi csoportot hozzon létre. Ha sok adatbázissal rendelkezik több rugalmas készletben, amelyeket át kell helyeznie, párhuzamosan futtathatja az előkészítési lépéseket, majd párhuzamosan kezdeményezheti az áthelyezési lépést. Ez a folyamat jobban skálázható, és kevesebb időt vesz igénybe ahhoz képest, hogy több rugalmas készlet van ugyanabban a feladatátvételi csoportban.

Az előkészítési folyamat figyelése

A Get-AzSqlDatabaseFailoverGroup rendszeres időközönként meghívható az adatbázisok forrásból a célba történő replikációjának figyeléséhez. A kimeneti objektum Get-AzSqlDatabaseFailoverGroup tartalmazza a ReplicationState tulajdonságát:

• A ReplicationState = 2 (CATCH_UP) azt jelzi, hogy az adatbázis szinkronizálva van, és biztonságosan feladatátvételt végezhet.
• A ReplicationState = 0 (Standard kiadás EDING) azt jelzi, hogy az adatbázis még nincs beadva, és a feladatátvételi kísérlet sikertelen lesz.

Szinkronizálás tesztelése

Miután a ReplicationState megtörtént 2, csatlakozzon az adatbázisok minden adatbázisához vagy részhalmazához a másodlagos végpont <fog-name>.secondary.database.windows.net használatával, és végezzen lekérdezéseket az adatbázisokon a kapcsolat, a megfelelő biztonsági konfiguráció és az adatreplikálás biztosítása érdekében.

Az áthelyezés kezdeményezése

1. Csatlakozás a célkiszolgálóra a másodlagos végpont <fog-name>.secondary.database.windows.nethasználatával.
2. A Switch-AzSqlDatabaseFailoverGroup használatával állítsa át a másodlagos felügyelt példányt elsődlegesként teljes szinkronizálással. Ez a művelet sikeres lesz, vagy vissza fog gördülni.
3. Ellenőrizze, hogy a parancs sikeresen nslook up <fog-name>.secondary.database.windows.net befejeződött-e annak megállapításával, hogy a DNS CNAME bejegyzés a célrégió IP-címére mutat-e. Ha a kapcsolóparancs sikertelen, a CNAME nem frissül.

A forrás rugalmas készleteinek eltávolítása

Miután az áthelyezés befejeződött, távolítsa el az erőforrásokat a forrásrégióban a szükségtelen díjak elkerülése érdekében.

1. Törölje a feladatátvételi csoportot a Remove-AzSqlDatabaseFailoverGroup használatával.
2. Törölje a forráskiszolgáló minden rugalmas forráskészletét a Remove-AzSqlElasticPool használatával.
3. Törölje a forráskiszolgálót a Remove-AzSqlServer használatával.
4. Távolítsa el a kulcstartót, a tárolók naplózását, az eseményközpontot, a Microsoft Entra-bérlőt és más függő erőforrásokat, hogy ne kelljen fizetniük.

Felügyelt példány áthelyezése

Verify prerequisites

1. Minden forrás által felügyelt példányhoz hozzon létre egy azonos méretű felügyelt SQL-példányt a célrégióban.
2. Konfigurálja a hálózatot egy felügyelt példányhoz. További információ: hálózati konfiguráció.
3. Konfigurálja a céladatbázist master a megfelelő bejelentkezésekkel. Ha nem Ön az előfizetés vagy a felügyelt SQL-példány rendszergazdája, a rendszergazdával együttműködve rendelje hozzá a szükséges engedélyeket.
4. Ha az adatbázisok transzparens adattitkosítással vannak titkosítva, és saját titkosítási kulcsot használnak az Azure Key Vaultban, győződjön meg arról, hogy az azonos titkosítási kulcsokkal rendelkező Azure Key Vault a forrás- és célrégiókban is létezik. További információ: Transzparens adattitkosítás ügyfél által felügyelt kulcsokkal az Azure Key Vaultban.
5. Ha a naplózás engedélyezve van a felügyelt példányon, győződjön meg arról, hogy:
   • A tároló vagy az eseményközpont a meglévő naplókkal a célrégióba kerül.
   • A naplózás a célpéldányon van konfigurálva. További információ: Naplózás felügyelt SQL-példányokkal.
6. Ha a példány hosszú távú adatmegőrzési szabályzattal (LTR) rendelkezik, a meglévő LTR-biztonsági másolatok továbbra is az aktuális példányhoz lesznek társítva. Mivel a célpéldány eltérő, akkor is hozzáférhet a forrásrégió régebbi LTR-biztonsági másolataihoz a forráspéldány használatával, még akkor is, ha a példányt törölték.

Megjegyzés:

Ez nem elegendő a szuverén felhő és egy nyilvános régió közötti váltáshoz. Az ilyen migráláshoz az LTR biztonsági másolatait a célpéldányra kell áthelyezni, amely jelenleg nem támogatott.

Erőforrások előkészítése

Hozzon létre egy feladatátvételi csoportot az egyes felügyelt forráspéldányok és a felügyelt SQL-példány megfelelő célpéldánya között.

Az egyes példányokon lévő összes adatbázis replikálása automatikusan elindul. További információ: Feladatátvételi csoportok.

Az előkészítési folyamat figyelése

A Get-AzSqlDatabaseInstanceFailoverGroup rendszeres időközönként meghívható az adatbázisok forrásból a célba történő replikációjának figyeléséhez. A kimeneti objektum Get-AzSqlDatabaseInstanceFailoverGroup tartalmazza a ReplicationState tulajdonságát:

• ReplicationState = CATCH_UP azt jelzi, hogy az adatbázis szinkronizálva van, és biztonságosan feladatátvételt végezhet.
• ReplicationState = Standard kiadás EDING azt jelzi, hogy az adatbázis még nincs bevetve, és a feladatátvételi kísérlet sikertelen lesz.

Szinkronizálás tesztelése

Miután a ReplicationState elkészült CATCH_UP, csatlakozzon a másodlagos végponttal <fog-name>.secondary.<zone_id>.database.windows.net a geo-másodlagoshoz, és végezzen lekérdezéseket az adatbázisokon a kapcsolat, a megfelelő biztonsági konfiguráció és az adatreplikálás biztosítása érdekében.

Az áthelyezés kezdeményezése

1. Csatlakozás a cél felügyelt példányhoz a másodlagos végpont <fog-name>.secondary.<zone_id>.database.windows.nethasználatával.
2. A Switch-AzSqlDatabaseInstanceFailoverGroup használatával állítsa át a másodlagos felügyelt példányt elsődlegesként teljes szinkronizálással. Ez a művelet sikeres lesz, vagy vissza fog gördülni.
3. Ellenőrizze, hogy a parancs sikeresen nslook up <fog-name>.secondary.<zone_id>.database.windows.net befejeződött-e annak megállapításával, hogy a DNS CNAME bejegyzés a célrégió IP-címére mutat-e. Ha a kapcsolóparancs sikertelen, a CNAME nem frissül.

A forrás által felügyelt példányok eltávolítása

Miután az áthelyezés befejeződött, távolítsa el az erőforrásokat a forrásrégióban a szükségtelen díjak elkerülése érdekében.

1. Törölje a feladatátvételi csoportot a Remove-AzSqlDatabaseInstanceFailoverGroup használatával. Ezzel törli a feladatátvételi csoport konfigurációját, és megszünteti a georeplikációs kapcsolatokat a két példány között.
2. Törölje a forrás által felügyelt példányt a Remove-AzSqlInstance használatával.
3. Távolítsa el az erőforráscsoport további erőforrásait, például a virtuális hálózatot és a biztonsági csoportot.

További lépések

Az adatbázis kezelése a migrálás után.