Delen via

Best practices voor het koppelen van beheerde instanties - Azure SQL Managed Instance

  • Artikel

van toepassing op:Azure SQL Managed Instance

In dit artikel vindt u een overzicht van de aanbevolen procedures bij het gebruik van de koppeling Managed Instance om gegevens te repliceren tussen Azure SQL Managed Instance en uw SQL Server-exemplaren die overal worden gehost, wat bijna realtime gegevensreplicatie tussen de gekoppelde replica's biedt.

Maak regelmatig logboekback-ups

Als SQL Server je eerste primaire server is, is het belangrijk om de eerste logboekback-up op SQL Server uit te voeren nadat de initiële seeding is voltooid, wanneer de database zich niet meer in de herstelfase ... bevindt op Azure SQL Managed Instance. Neem vervolgens regelmatig back-ups van SQL Server-transactielogboeken om een gezonde grootte van het transactielogboekbestand te behouden terwijl SQL Server de primaire verantwoordelijkheid heeft.

De koppelingsfunctie repliceert gegevens met behulp van de gedistribueerde beschikbaarheidsgroepen technologie op basis van AlwaysOn-beschikbaarheidsgroepen. Gegevensreplicatie met gedistribueerde beschikbaarheidsgroepen is gebaseerd op het repliceren van transactielogboekrecords. Er kunnen geen transactielogboekrecords worden afgekapt vanuit de database op het primaire SQL Server-exemplaar totdat ze worden gerepliceerd naar de database op de secundaire replica. Als de replicatie van transactielogboekrecords traag of geblokkeerd is vanwege problemen met de netwerkverbinding, blijft het logboekbestand groeien op het primaire exemplaar. De groeisnelheid is afhankelijk van de intensiteit van de werkbelasting en de netwerksnelheid. Als er sprake is van een langdurige netwerkverbindingsstoring en zware werkbelasting op het primaire exemplaar, kan het logboekbestand alle beschikbare opslagruimte in beslag nemen.

Het maken van regelmatige back-ups van transactielogboeken kapt het transactielogboek af en minimaliseert het risico dat er onvoldoende ruimte beschikbaar is op het primaire SQL Server-exemplaar vanwege de groei van logboekbestanden. Er is geen extra actie nodig wanneer SQL Managed Instance de primaire is, omdat logboekback-ups al automatisch worden uitgevoerd. Door regelmatig logboekback-ups op uw PRIMAIRE SQL Server te maken, maakt u uw database toleranter voor ongeplande logboekgroeigebeurtenissen. Overweeg dagelijkse back-uptaken voor logboeken te plannen met behulp van een SQL Server Agent-taak.

U kunt een Transact-SQL (T-SQL)-script gebruiken om een back-up te maken van het logboekbestand, zoals het voorbeeld in deze sectie. Vervang de tijdelijke aanduidingen in het voorbeeldscript door de naam van uw database, de naam en het pad van het back-upbestand en de beschrijving.

Als u een back-up van uw transactielogboek wilt maken, gebruikt u het volgende voorbeeldscript Transact-SQL (T-SQL) op SQL Server:

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

Gebruik de volgende Transact-SQL (T-SQL)-opdracht om de door uw database in SQL Server gebruikte logboekruimte te controleren.

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

De queryuitvoer ziet eruit als in het volgende voorbeeld voor de voorbeelddatabase tpcc:

Schermopname met resultaten van de opdracht die de grootte van de logboekbestanden en de gebruikte ruimte toont

In dit voorbeeld heeft de database 76% van het beschikbare logboek gebruikt, met een absolute grootte van ongeveer 27 GB (27.971 MB). De drempelwaarden voor actie variëren op basis van uw workload. In het vorige voorbeeld is de grootte van het transactielogboek en het gebruikspercentage van het logboek doorgaans een indicatie dat u een back-up van het transactielogboek moet maken om het logboekbestand af tekappen en wat ruimte vrij te maken, of u moet vaker logboekback-ups maken. Het kan ook een indicatie zijn dat de afkapping van het transactielogboek wordt geblokkeerd door openstaande transacties. Zie Problemen met een volledig transactielogboek (SQL Server-fout 9002) oplossenvoor meer informatie over het oplossen van problemen met een transactielogboek in SQL Server. Zie Problemen met transactielogboeken oplossen met Azure SQL Managed Instancevoor meer informatie over het oplossen van problemen met een transactielogboek in Azure SQL Managed Instance.

Notitie

Wanneer u deelneemt aan een koppeling, worden geautomatiseerde back-ups van volledige en transactielogboeken gemaakt vanuit SQL Managed Instance, ongeacht of dit de primaire replica is. Er worden geen differentiële back-ups gemaakt, wat kan leiden tot langere hersteltijden.

Prestaties van replica's vergelijken

Wanneer u de koppelingsfunctie gebruikt, is het belangrijk om de prestatiecapaciteit tussen SQL Server en SQL Managed Instance te vergelijken om prestatieproblemen te voorkomen als de secundaire replica geen replicatie van de primaire replica of na een failover kan bijhouden. De prestatiecapaciteit omvat CPU-kernen (of vCores in Azure), geheugen en I/O-doorvoer.

U kunt de prestaties van replicatie controleren met de grootte van de redo-wachtrij op de secundaire replica. De grootte van de redo-wachtrij geeft het aantal logboeken aan dat wacht om opnieuw uitgevoerd te worden op de secundaire replica. Een consistent hoge wachtrijgrootte voor opnieuw uitvoeren geeft aan dat de secundaire replica niet kan bijhouden met de primaire replica. U kunt de grootte van de nieuwe wachtrij op de volgende manieren controleren:

Als de grootte van de redo-wachtrij consistent hoog is, overweeg dan extra middelen toe te kennen aan de secundaire replica.

Certificaat draaien

Het is mogelijk dat het certificaat dat u gebruikt om het eindpunt voor databasespiegeling te beveiligen, verloopt, wat kan leiden tot de verslechtering van de koppeling. Om dit probleem te voorkomen, het certificaat roteren voordat het verloopt.

Gebruik de volgende Transact-SQL opdracht (T-SQL) om de vervaldatum van het huidige certificaat te controleren:

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

Als uw certificaat bijna verloopt of al is verlopen, kunt u een nieuw certificaatmaken en vervolgens het bestaande eindpunt wijzigen om het huidige certificaatte vervangen.

Zodra het eindpunt is geconfigureerd voor het gebruik van het nieuwe certificaat, kunt u verwijderen het verlopen certificaat.

Opstarttraceringsvlagmen toevoegen

In SQL Server zijn er twee traceringsvlagken (-T1800 en -T9567) die, wanneer ze als opstartparameters worden toegevoegd, de prestaties van gegevensreplicatie via de koppeling kunnen optimaliseren. Zie opstart-traceringsvlaggen inschakelen voor meer informatie.

Verwante inhoud

De koppeling gebruiken:

Voor meer informatie over de koppeling:

Voor andere replicatie- en migratiescenario's kunt u het volgende overwegen: