Delen via


Koppeling oplossen - Azure SQL Managed Instance

van toepassing op:Azure SQL Managed Instance

In dit artikel leert u hoe u problemen kunt bewaken en oplossen met een koppeling tussen SQL Server en Azure SQL Managed Instance.

U kunt de status van de koppeling controleren met Transact-SQL (T-SQL), Azure PowerShell of de Azure CLI. Als u problemen ondervindt, kunt u de foutcodes gebruiken om het probleem op te lossen.

Veel problemen met het maken van de koppeling kunnen worden opgelost door het netwerk tussen de twee exemplaren te controleren en te valideren dat de -omgeving goed is voorbereid voor de koppeling.

Eerste zaaien

Bij het tot stand brengen van een koppeling tussen SQL Server en Azure SQL Managed Instance, is er een initiële seedingfase voordat de gegevensreplicatie wordt gestart. De eerste seedingfase is het langste en duurste deel van de bewerking. Zodra de initiële seeding is voltooid, worden gegevens gesynchroniseerd en worden alleen volgende gegevenswijzigingen gerepliceerd. De tijd die nodig is om de initiële seeding te voltooien, is afhankelijk van de grootte van gegevens, de werkbelastingsintensiteit van de primaire databases en de snelheid van de koppeling tussen netwerken van de primaire en secundaire replica's.

Als de snelheid van de koppeling tussen de twee instanties langzamer is dan nodig is, is de tijd om te zaaien waarschijnlijk merkbaar beïnvloed. U kunt de opgegeven seedingsnelheid, de totale grootte van gegevens en de koppelingssnelheid gebruiken om te schatten hoe lang de initiële seedingfase duurt voordat de gegevensreplicatie begint. Voor een individuele database van 100 GB duurt de eerste seed-fase bijvoorbeeld ongeveer 1,2 uur als de koppeling 84 GB per uur kan pushen en als er geen andere databases worden gezaaid naar een andere koppeling. Als de koppeling slechts 10 GB per uur kan overdragen, kan het seeden van een database van 100 GB ongeveer 10 uur duren. Als er meerdere databases moeten worden gerepliceerd via meerdere koppelingen, wordt seeding parallel uitgevoerd en kan de eerste seedingfase aanzienlijk langer duren, vooral als de parallelle seeding van gegevens uit alle databases de beschikbare koppelingsbandbreedte overschrijdt.

Belangrijk

De initiële seedingfase kan dagen duren bij zeer lage of drukke verbindingen. In dit geval kan er een time-out opgetreden bij het maken van de koppeling. Het maken van de koppeling wordt na 6 dagen automatisch geannuleerd.

Als u problemen ondervindt met een koppeling, kunt u SQL Server Management Studio (SSMS), Transact-SQL (T-SQL), Azure PowerShell of de Azure CLI gebruiken om informatie over de huidige status van de koppeling op te halen.

Gebruik T-SQL voor een snelle status van de koppelingsstatus en gebruik vervolgens Azure PowerShell of de Azure CLI voor uitgebreide informatie over de huidige status van de koppeling.

Koppelingsbewaking is beschikbaar vanaf SQL Server Management Studio (SSMS) 21.0 (preview).

Volg deze stappen om de koppelingsstatus in SSMS te controleren:

  1. Maak verbinding met een replica die als host fungeert voor de koppeling.

  2. Vouw in ObjectverkennerAlwaysOn Hoge beschikbaarheid uit en vouw vervolgens Beschikbaarheidsgroepen uit.

  3. Klik met de rechtermuisknop op de naam van de koppeling en selecteer Eigenschappen om het venster Koppelingseigenschappen te openen:

    Schermopname van het snelmenu op een koppeling in SSMS, met eigenschappen gemarkeerd.

  4. In het venster Eigenschappen van koppeling wordt nuttige informatie weergegeven over de koppeling, zoals replicagegevens, koppelingsstatus en de vervaldatum van het eindpuntcertificaat:

    Schermopname van het venster Koppelingseigenschappen in SSMS.

In de replicaState waarde wordt de huidige koppeling beschreven. Als de status ook Fout bevat, is er een fout opgetreden tijdens de bewerking die wordt vermeld in de status. Bijvoorbeeld, LinkCreationError geeft aan dat er een fout is opgetreden tijdens het maken van de koppeling.

Enkele mogelijke replicaState waarden zijn:

  • CreatingLink: Eerste zaadjes planten
  • LinkSynchroniseren: gegevensreplicatie wordt uitgevoerd
  • LinkFailoverInProgress-: Failover wordt uitgevoerd

Raadpleeg de opdracht Gedistribueerde beschikbaarheidsgroepen GET REST API voor een volledige lijst met eigenschappen van de koppelingsstatus.

Er zijn twee verschillende foutencategorieën die u kunt tegenkomen bij het gebruik van de koppeling: fouten bij het initialiseren van de koppeling en fouten bij het maken van de koppeling.

De volgende fout kan optreden bij het initialiseren van een koppeling (koppelingsstatus: LinkInitError):

  • Fout 41962: Bewerking is afgebroken omdat de koppeling niet binnen 5 minuten is gestart. Controleer netwerkverbinding en probeer het opnieuw.
  • Fout 41973: Koppeling kan niet tot stand worden gebracht omdat eindpuntcertificaat van SQL Server niet correct is geïmporteerd in Azure SQL Managed Instance.
  • fout 41974: koppeling kan niet tot stand worden gebracht omdat eindpuntcertificaat van sql Managed Instance niet correct is geïmporteerd in SQL Server.
  • Fout 41976: De beschikbaarheidsgroep reageert niet. Controleer de namen en configuratieparameters en probeer het opnieuw.
  • Fout 41986: Koppeling kan niet tot stand worden gebracht omdat de verbinding is mislukt of omdat de secundaire replica niet reageert. Controleer de namen, configuratieparameters en netwerkverbinding en probeer het opnieuw.
  • Fout 47521: Koppeling kan niet tot stand worden gebracht omdat de secundaire server de aanvraag niet heeft ontvangen. Zorg ervoor dat de beschikbaarheidsgroep en databases in orde zijn op de primaire server en probeer het opnieuw.

De volgende fouten kunnen optreden bij het maken van een koppeling (koppelingsstatus: LinkCreationError):

  • fout 41977: de doeldatabase reageert niet. Controleer de koppelingsparameters en probeer het opnieuw.

  • Voortijdige afkapping van logboeken: als het transactielogboek wordt afgekapt voordat de eerste seeding is voltooid, ziet u waarschijnlijk een van de volgende fouten:

    • Fout 1408: De externe kopie van de database '%.*ls' is niet ver genoeg hersteld om databasespiegeling in te schakelen of om deze aan de beschikbaarheidsgroep toe te voegen.
    • Fout 1412: De externe kopie van de database "%.*ls" is niet doorgestuurd naar een tijdstip dat is opgenomen in de lokale kopie van het databaselogboek.

    U kunt dit probleem oplossen door de koppeling te verwijderen en opnieuw te maken.
    U kunt dit probleem voorkomen door back-ups van transactielogboeken op SQL Server te onderbreken voor het repliceren van de database tijdens de eerste seedingfase.

Inconsistente toestand na geforceerde failover

Na een geforceerde failover, kan er een split-brain-scenario optreden waarbij beide replica's de primaire rol hebben, waardoor de koppeling in een inconsistente toestand blijft. Dit kan gebeuren als u tijdens een noodgeval een failover naar de secundaire replica uitvoert en de primaire replica weer online komt.

Controleer eerst of u zich in een split-brain scenario bevindt. U kunt dit doen met behulp van SQL Server Management Studio (SSMS) of Transact-SQL (T-SQL).

Maak verbinding met zowel de SQL Server als de SQL Managed Instance in SSMS, en vouw vervolgens in Objectverkenner, de Beschikbaarheidsreplica's uit onder het knooppunt Beschikbaarheidsgroep in Always On High Availability. Als twee verschillende replica's als (Primair) enworden vermeld, bevindt u zich in een split-brain scenario.

U kunt ook het volgende T-SQL-script uitvoeren op zowel SQL Server als SQL Managed Instance om de rol van de replica's te controleren:

-- Execute on SQL Server and SQL Managed Instance 
USE master
DECLARE @link_name varchar(max) = '<DAGName>'
SELECT
   ag.name [Link name], 
   rs.role_desc [Link role] 
FROM
   sys.availability_groups ag 
   JOIN sys.dm_hadr_availability_replica_states rs 
   ON ag.group_id = rs.group_id 
WHERE 
   rs.is_local = 1 AND ag.is_distributed = 1 AND ag.name = @link_name 
GO

Als beide instellingen PRIMAIRE in de Koppelingsrol kolom vermelden, bevindt u zich in een split-brain scenario.

Als je de split-brain-toestand wilt oplossen, maak je eerst een back-up op de replica die oorspronkelijk de primaire was. Als de oorspronkelijke primaire sql Server was, neemt u een back-up van het tail-logboek. Als het oorspronkelijke primaire exemplaar een SQL Managed Instance was, maakt u een alleen-kopiëren volledige back-up van . Nadat de back-up is voltooid, stelt u de gedistribueerde beschikbaarheidsgroep in op de secundaire rol voor de replica die eerst de primaire replica was, maar nu secundair wordt.

Als er bijvoorbeeld sprake is van een noodgeval, ervan uitgaande dat u een failover van uw SQL Server-workload naar Azure SQL Managed Instance hebt geforceerd en u uw workload wilt blijven uitvoeren op SQL Managed Instance, neemt u een back-up van het taillogboek op SQL Server en stelt u vervolgens de gedistribueerde beschikbaarheidsgroep in op de secundaire rol op SQL Server, zoals in het volgende voorbeeld:

--Execute on SQL Server 
USE master
ALTER AVAILABILITY GROUP [<DAGName>] 
SET (ROLE = SECONDARY) 
GO 

Voer vervolgens een geplande handmatige failover uit van SQL Managed Instance naar SQL Server met behulp van de koppeling, zoals het volgende voorbeeld:

--Execute on SQL Managed Instance 
USE master
ALTER AVAILABILITY GROUP [<DAGName>] FAILOVER 
GO 

Verlopen certificaat

Het is mogelijk dat het certificaat dat wordt gebruikt voor de koppeling verloopt. Als het certificaat verloopt, mislukt de koppeling. U kunt dit probleem oplossen door het certificaat te roteren.

Netwerkconnectiviteit testen

Bidirectionele netwerkconnectiviteit tussen SQL Server en SQL Managed Instance is nodig om de koppeling te laten werken. Nadat u poorten aan de zijde van SQL Server hebt geopend en een NSG-regel aan de zijde van SQL Managed Instance hebt geconfigureerd, test u de connectiviteit met behulp van SQL Server Management Studio (SSMS) of Transact-SQL.

Test het netwerk door een tijdelijke SQL Agent-taak te maken op zowel SQL Server als SQL Managed Instance om de verbinding tussen de twee exemplaren te controleren. Wanneer u Network Checker in SSMS gebruikt, wordt de taak automatisch voor u gemaakt en verwijderd nadat de test is voltooid. U moet de SQL Agent-taak handmatig verwijderen als u uw netwerk test met behulp van T-SQL.

Notitie

Het uitvoeren van PowerShell-scripts door de SQL Server Agent op SQL Server op Linux wordt momenteel niet ondersteund, dus het is momenteel niet mogelijk om Test-NetConnection uit te voeren vanuit de SQL Server Agent-taak op SQL Server op Linux.

Als u de SQL Agent wilt gebruiken om de netwerkverbinding te testen, hebt u de volgende vereisten nodig:

  • De gebruiker die de test uitvoert, moet machtigingen hebben om een job te maken (ofwel als een sysadmin of als hij tot de rol SQLAgentOperator voor msdbbehoort) voor zowel SQL Server als SQL Managed Instance.
  • De SQL Server Agent service moet draaien op SQL Server. Omdat de agent standaard is ingeschakeld voor SQL Managed Instance, is er geen extra actie nodig.

Voer de volgende stappen uit om de netwerkverbinding tussen SQL Server en SQL Managed Instance in SSMS te testen:

  1. Maak verbinding met het exemplaar dat als primaire replica in SSMS fungeert.

  2. Vouw in Objectverkennerdatabases uit en klik met de rechtermuisknop op de database die u met de secundaire database wilt koppelen. Selecteer Taken >Azure SQL Managed Instance link> Verbinding testen om de Netwerkcontrole-wizard te openen.

    Schermopname van objectverkenner in S S M S, waarbij de testverbinding is geselecteerd in het snelmenu van de databasekoppeling.

  3. Selecteer Volgende op de Inleidingspagina van de wizard Netwerkcontrole.

  4. Als aan alle vereisten wordt voldaan op de pagina Voorwaarden, selecteert u Volgende. Los anders eventuele onvervulde vereisten op en selecteer vervolgens Validatie opnieuw uitvoeren.

  5. Op de Aanmelden pagina, selecteer Aanmelden om verbinding te maken met het andere exemplaar, dat als de secundaire replica zal dienen. Selecteer Volgende.

  6. Controleer de details op de pagina Netwerkopties opgeven en geef indien nodig een IP-adres op. Selecteer Volgende.

  7. Controleer op de pagina Samenvatting de acties die de wizard uitvoert en selecteer vervolgens Voltooien om de verbinding tussen de twee replica's te testen.

  8. Controleer de pagina resultaten om te controleren of er connectiviteit bestaat tussen de twee replica's en selecteer vervolgens sluiten om te voltooien.

Voorzichtigheid

Ga alleen verder met de volgende stappen als u de netwerkverbinding tussen uw bron- en doelomgevingen hebt gevalideerd. Los anders problemen met de netwerkverbinding op voordat u doorgaat.

Raadpleeg de volgende bronnen voor meer informatie over de koppelingsfunctie: