Managed Instance csatolásának legjobb gyakorlatai – Azure SQL Managed Instance

A következőre vonatkozik: :Azure SQL Managed Instance

Ez a cikk az ajánlott eljárásokat ismerteti a Managed Instance hivatkozás használatával az adatok replikálásához Azure SQL Managed Instance és a bárhol üzemeltetett SQL Server-példányok között. A kapcsolat közel valós idejű adatreplikálást biztosít a csatolt replikák között.

Naplók biztonsági mentésének rendszeres elvégzése

Ha az SQL Server a kezdeti elsődleges példány, akkor végezze el az első napló biztonsági mentését az SQL Serveren a kezdeti feltöltés befejezése után, ha az adatbázis már nincs a Restoring... állapotában az Azure SQL Managed Instance-on. Ezután rendszeresen mentse a SQL Server tranzakciónaplókat, hogy a tranzakciónapló fájlmérete megfelelő maradjon, miközben az SQL Server a fő funkciójában van.

A hivatkozás funkció az Always On rendelkezésre állási csoportokon alapuló elosztott rendelkezésre állási csoportok technológiájával replikálja az adatokat. Az elosztott rendelkezésre állási csoport adatreplikálása a tranzakciónapló-rekordok replikálásán alapul. Az elsődleges SQL Server példány nem tud csonkolni semmilyen tranzakciónapló-rekordot az adatbázisból, amíg a másodlagos replika adatbázisába nem replikálja őket. Ha a hálózati kapcsolat problémái miatt a tranzakciónapló-rekord replikációja lassú vagy le van tiltva, a naplófájl folyamatosan növekszik az elsődleges példányon. A számítási feladatok intenzitása és a hálózati sebesség határozza meg a növekedési sebességet. Ha a hálózati kapcsolat megszakadása hosszabb, és az elsődleges példány számítási feladatai nagyok, a naplófájl minden rendelkezésre álló tárterületet igénybe vehet.

A tranzakciónapló rendszeres biztonsági mentése csonkolja a tranzakciónaplót, és minimálisra csökkenti annak a kockázatát, hogy a naplófájlok növekedése miatt elfogy a hely az elsődleges SQL Server példányon. Nincs szükség további műveletre, ha a SQL Managed Instance az elsődleges, mivel a napló biztonsági mentései már automatikusan készülnek. Ha rendszeresen készít napló biztonsági mentéseket az SQL Server elsődlegesen, rugalmasabbá teszi az adatbázist a nem tervezett naplónövekedési eseményekkel szemben. Fontolja meg a naplók napi biztonsági mentési feladatainak ütemezését egy SQL Server Agent feladat használatával.

A naplófájlról Transact-SQL (T-SQL) szkripttel készíthet biztonsági másolatot, például az ebben a szakaszban megadott mintát. Cserélje le a mintaszkript helyőrzőit az adatbázis nevére, a biztonsági mentési fájl nevére és elérési útjára, valamint a leírásra.

A tranzakciónapló biztonsági mentéséhez használja a következő Transact-SQL (T-SQL) szkriptet az SQL Serveren:

-- Execute on SQL Server
-- Take log backup
BACKUP LOG [<DatabaseName>]
TO DISK = N'<DiskPathandFileName>'
WITH NOFORMAT, NOINIT,
NAME = N'<Description>', SKIP, NOREWIND, NOUNLOAD, COMPRESSION, STATS = 1

A következő Transact-SQL (T-SQL) paranccsal ellenőrizze az adatbázis által a SQL Serveren használt naplótér méretet:

-- Execute on SQL Server
DBCC SQLPERF(LOGSPACE);

A lekérdezés kimenete a következő példához hasonlít a mintaadatbázis-tpccesetében:

Képernyőkép a parancs eredményeiről, amelyen a naplófájl mérete és a használt terület látható

Ebben a példában az adatbázis az elérhető napló 76%-ját használta, az abszolút naplófájl mérete körülbelül 27 GB (27 971 MB). A művelet küszöbértékei a számítási feladattól függően változnak. Az előző példában a tranzakciónapló mérete és a napló használatának százalékos aránya általában azt jelzi, hogy a tranzakciónapló biztonsági mentésével csonkíthatja a naplófájlt, és szabadíthat fel némi helyet, vagy gyakrabban kell biztonsági másolatot készítenie a naplókról. Azt is jelezheti, hogy a tranzakciónapló csonkolását a nyitott tranzakciók hátráltatják. A tranzakciónaplók SQL Server történő hibaelhárításáról további információt a Tranzakciós napló (SQL Server 9002-as hiba) című témakörben talál. Az Azure SQL Managed Instance tranzakciónaplóinak hibaelhárításáról további információt az Troubleshoot tranzakciónapló-hibák az Azure SQL Managed Instance címen található.

Jegyzet

Ha részt vesz egy hivatkozásban, SQL Managed Instance automatikusan teljes és tranzakciónaplós biztonsági mentést készít, függetlenül attól, hogy az elsődleges replika-e. A rendszer nem készít különbségi biztonsági mentéseket, ami hosszabb visszaállítási időt eredményezhet.

Teljesítménykapacitás egyeztetése replikák között

A hivatkozás funkció használatakor ellenőrizze, hogy a SQL Server és a SQL Managed Instance teljesítőképessége összhangban van-e. Ez az illeszkedés segít elkerülni a teljesítményproblémákat, ha a másodlagos replika nem tud lépést tartani az elsődleges replikából érkező replikációval, vagy a feladatátvétel után. A teljesítménykapacitás processzormagokat (vagy virtuális magokat Azure), memóriát és I/O-átviteli sebességet tartalmaz.

A replikáció teljesítményét a másodlagos replikán az újradátumazási várólista méretének ellenőrzésével figyelheti. Az újrapróbálkozási várakozási sor mérete azon naplóbejegyzések számát mutatja, amelyek a másodlagos replikán megismétlésre várnak. A redo sor következetesen nagy mérete azt mutatja, hogy a másodlagos replika nem tud lépést tartani az elsődleges replikával. A redo várólista méretét az alábbi módokon ellenőrizheti:

  • Az redo_queue_size dinamikus felügyeleti nézet értéke az elsődleges replikán.
  • Az elsődleges replikán a InstanceRedoLagReplicationSeconds érték a Get-AzSqlInstanceLink-nél.

Ha az újrafeldolgozási sor mérete folyamatosan magas, fontolja meg az erőforrások növelését a másodlagos replikán.

Replikáció késésének figyelése

A replikáció késésének figyelése segít meghatározni, hogy a másodlagos replika milyen sebességgel szinkronizálja az elsődleges replikát. A nagy eltérés azt jelzi, hogy a másodlagos replika nem tud lépést tartani az elsődleges replikával, amelyet általában a két példány közötti kapcsolat lassú hálózati átviteli sebessége, a két replika közötti eltérő erőforrás-kiosztás vagy az elsődleges replika túlzottan magas számítási feladatai okoznak.

A replikáció késésének figyelése különösen fontos egy tervezett feladatátvétel végrehajtásakor, amely megköveteli, hogy a másodlagos replika teljes mértékben szinkronizálva legyen az elsődleges replikával a feladatátvétel végrehajtása előtt. Ha a replikáció késése magas, a feladatátvétel hosszabb időt vehet igénybe, és bizonyos esetekben akár sikertelen is lehet.

A replikák közötti replikáció késésének figyeléséhez használja a következő T-SQL-lekérdezést SQL Server és SQL Managed Instance:

-- Execute on SQL Server and SQL Managed Instance 
USE master
DECLARE @link_name varchar(max) = '<DAGname>'
SELECT
   ag.name [Link name], 
   ars1.role_desc [Link role],
   ars2.connected_state_desc [Link connected state],
   ars2.synchronization_health_desc [Link sync health],
   drs.secondary_lag_seconds [Link replication latency (seconds)]
FROM
   sys.availability_groups ag 
   JOIN sys.dm_hadr_availability_replica_states ars1
   ON ag.group_id = ars1.group_id
   JOIN sys.dm_hadr_availability_replica_states ars2
   ON ag.group_id = ars2.group_id
   JOIN sys.dm_hadr_database_replica_states drs
   ON ars2.replica_id = drs.replica_id
WHERE 
   ag.is_distributed = 1 AND ag.name = @link_name AND ars1.is_local = 1 AND ars2.is_local = 0
GO

Az elforgatás tanúsítványa

Előfordulhat, hogy manuálisan kell megújítania az SQL Szerveren az adatbázis tükrözési végpontjának védelméhez használt tanúsítványt. Mivel a szolgáltatás kezeli és automatikusan frissíti az adatbázis-tükrözési végpont védelméhez használt tanúsítványt a SQL Managed Instance-en, nem kell manuálisan frissítenie.

SQL Server

Az adatbázis-tükrözési végpont SQL Server történő védelméhez használt tanúsítvány lejárhat. Ha a tanúsítvány lejár, az a hivatkozás romlásához vezethet. A probléma elkerülése érdekében forgassa el a tanúsítványt, mielőtt lejár.

Az aktuális tanúsítvány lejárati dátumának ellenőrzéséhez használja a következő Transact-SQL (T-SQL) parancsot:

-- Run on SQL Server
USE MASTER
GO
SELECT * FROM sys.certificates WHERE pvt_key_encryption_type = 'MK'

Ha a tanúsítvány hamarosan lejár, vagy már lejárt, hozzon létre egy új tanúsítványt, majd módosítsa a meglévő végpontot az aktuális tanúsítvány lecseréléséhez.

Miután konfigurálta a végpontot az új tanúsítvány használatára, elvetheti a lejárt tanúsítványt.

SQL Managed Instance

A SQL Managed Instance adatbázis-tükrözési végponttanúsítványa rendszeres időközönként automatikusan forog. Nem kell figyelnie a SQL Managed Instance esetében az adatbázis tükrözési végpont tanúsítványának lejárati dátumát, amíg sikeresen érvényesítheti a tanúsítványláncot a SQL Serveren.

A tanúsítványlánc ellenőrzése a SQL Server

Jegyzet

Rendszeresen ellenőrizze a tanúsítványláncot a meglévő hivatkozásokhoz, vagy hárítsa el a csökkentett teljesítményű hivatkozásokkal kapcsolatos problémákat. Ha új kapcsolatot konfigurál, vagy nemrég fejezte be a A tanúsítvány nyilvános kulcsának megszerzése SQL Managed Instance-ból és annak importálása SQL Serverbe és Az Azure által megbízhatónak tartott főtanúsítvány-kulcsok importálása az SQL Serverbe szakasz lépéseit, hagyja ki ezt a szakaszt.

A tanúsítványláncgal kapcsolatos problémák ronthatják a hivatkozást. A probléma elkerülése érdekében regularisan ellenőrizze a tanúsítványláncot SQL Server.

A következő forgatókönyvek problémákat okozhatnak a tanúsítványláncgal SQL Server:

  • Ütemezett tanúsítványok cseréje a SQL Managed Instance esetén.
  • A tanúsítványok nem szándékos vagy véletlen módosítása a SQL Serveren, például az adatbázis tükrözési végpontjának védelméhez használt tanúsítvány elvetése vagy módosítása.

Először határozza meg az importált MI-végponttanúsítvány certificate_id értékét a <ManagedInstanceFQDN> értékének cseréjével, majd futtassa a következő lekérdezést a SQL Server:

-- Run on SQL Server 
USE master 
SELECT name, subject, certificate_id, start_date, expiry_date 
FROM sys.certificates 
WHERE issuer_name LIKE '%Microsoft Corporation%' AND name = '<ManagedInstanceFQDN>' 
GO

Ezután ellenőrizze a tanúsítványt úgy, hogy lecseréli a <certificate_id> értékét az előző lekérdezés eredményéből, majd futtassa a következő lekérdezést SQL Server:

-- Run on SQL Server 
USE master
EXEC sp_validate_certificate_ca_chain <certificate_id> 
GO

A válasz Commands completed successfully. Completion time: ... azt jelzi, hogy a MI-végpont tanúsítványa sikeresen érvényesítve van.

Fontos

A tárolt eljárás sp_validate_certificate_ca_chain a gazdagép operációsrendszer-szolgáltatásaira támaszkodik a tanúsítványérvényesítés végrehajtásához, ami online tanúsítvány-visszavonási ellenőrzést is magában foglalhat. Ha a gazdagép operációs rendszere nincs az internet elérésére konfigurálva, a végrehajtás akkor is meghiúsul, ha a tanúsítványlánc érvényes.

Ha hibát tapasztal, a legmegbízhatóbb megoldás a tanúsítványlánc visszaállítása, ha először törli azokat a tanúsítványokat, amelyeket a A tanúsítvány nyilvános kulcsának beszerzése a SQL Managed Instance-ból és importálása az SQL Server-be és Az Azure-megbízható gyökér tanúsítványhitelesítő kulcsainak importálása az SQL Server-be szakaszokban létrehozott, majd újból importálja őket.

Indítási nyomkövetési jelzők hozzáadása

A SQL Server két nyomkövetési jelző (-T1800 és -T9567) található, amelyek indítási paraméterekként hozzáadva optimalizálhatják az adatreplikálás teljesítményét a hivatkozáson keresztül. További információ: Indítási nyomkövetési jelzők engedélyezése.

A szinkron véglegesítést használja óvatosan

A hivatkozás alapértelmezett véglegesítési módja aszinkron. Bár a véglegesítési mód szinkronizálásra módosítható, nem ajánlott, és nem szükséges a lehetséges adatvesztés elleni védelemhez.

Egy tervezett csatolt feladatátvétel során a replikáció ideiglenesen szinkron véglegesítési módra vált, amíg a feladatátvétel befejeződik. A feladatátvétel után a véglegesítési mód aszinkron módra vált, még akkor is, ha a feladatátvétel előtt explicit módon szinkron véglegesítési módra van beállítva.

A csatolás szinkron véglegesítési módjának használata befolyásolhatja az elsődleges replika teljesítményét, különösen akkor, ha a replikák között nagy a hálózati késés. Szinkron véglegesítési módban az elsődleges replikán lévő tranzakcióknak meg kell várniuk annak megerősítését, hogy a tranzakciónapló rekordjai meg vannak erősítve a másodlagos replikán, mielőtt a tranzakció véglegesíthető lenne az elsődleges replikán. Ez a várakozási idő nagyobb hálózati késéssel nő, ami megnövelheti a tranzakciók válaszidejének számát, és csökkentheti az elsődleges replika átviteli sebességét.

Kapcsolódó tartalom

A hivatkozás használata:

További információ a hivatkozásról:

Egyéb replikációs és migrálási forgatókönyvek esetén fontolja meg a következő szempontokat:

  • Last updated on