Dela via

Funktionskompatibilitet med AG- och DNN-lyssnare

Gäller för:SQL Server på en virtuell Azure-dator

Tips/Råd

Det finns många metoder för att distribuera en tillgänglighetsgrupp. Förenkla distributionen och eliminera behovet av en Azure Load Balancer eller ett distribuerat nätverksnamn (DNN) för din AlwaysOn-tillgänglighetsgrupp genom att skapa dina virtuella SQL Server-datorer i flera undernät i samma virtuella Azure-nätverk. Om du redan har skapat tillgänglighetsgruppen i ett enda undernät kan du migrera den till en miljö med flera undernät.

Vissa SQL Server-funktioner förlitar sig på ett hårdkodat virtuellt nätverksnamn (VNN). När du använder DNN-lyssnaren (distribuerat nätverksnamn) med din AlwaysOn-tillgänglighetsgrupp och SQL Server på virtuella Azure-datorer i ett enda undernät kan det uppstå vissa begränsningar.

Den här artikeln beskriver SQL Server-funktioner och samverkan med tillgänglighetsgruppens DNN-lyssnare.

Beteendeskillnader

Observera följande skillnader mellan funktionerna i VNN-lyssnaren och DNN-lyssnaren:

  • Tid för redundansväxling: Redundansväxlingen går snabbare när du använder en DNN-lyssnare eftersom det inte finns någon anledning att vänta tills nätverkslastbalanseraren identifierar felhändelsen och ändrar dess ruttning.
  • Befintliga anslutningar: Anslutningar till en specifik databas i en tillgänglighetsgrupp under växling vid redundans stängs, men andra anslutningar till den primära repliken förblir öppna eftersom DNN är online under redundansväxlingen. Det här beteendet skiljer sig från en traditionell VNN-miljö där alla anslutningar till den primära repliken stängs vanligtvis när tillgänglighetsgruppen genomgår en failover, lyssnaren går offline och den primära repliken övergår till den sekundära rollen. När du använder en DNN listener kan du behöva justera applikationsanslutningssträngar för att säkerställa att anslutningar omdirigeras till den nya primära replikan vid övergång till failover.
  • Öppna transaktioner: Öppna transaktioner mot en databas i en felförbisedd tillgänglighetsgrupp stängs och återställs, och du måste återansluta manuellt. I SQL Server Management Studio stänger du till exempel frågefönstret och öppnar ett nytt.

Klientdrivrutiner

För ODBC-, OLEDB-, ADO.NET-, JDBC-, PHP- och Node.js-drivrutiner anger du DNN-lyssnarnamnet och porten som servernamn i anslutningssträngen. För att säkerställa snabb anslutning vid redundans lägger du till MultiSubnetFailover=True i anslutningssträngen om SQL-klienten stöder den.

Tools

Användare av SQL Server Management Studio, sqlcmd och SQL Server Data Tools måste ange DNN-lyssnarnamnet och porten som servernamn i anslutningssträngen för att ansluta till lyssnaren.

Det finns för närvarande inte stöd för att skapa DNN-lyssnaren med hjälp av SQL Server Management Studio (SSMS).

Tillgänglighetsgrupper och FCI

Du kan konfigurera en AlwaysOn-tillgänglighetsgrupp med hjälp av en redundansklusterinstans (FCI) som en av replikerna. För att den här konfigurationen ska fungera med DNN-lyssnaren måste failover-klusterinstansen också använda DNN, eftersom det inte finns något sätt att placera den virtuella FCI-IP-adressen i AG DNN-IP-listan.

I den här konfigurationen måste speglingsslutpunktens URL för FCI-repliken använda FCI DNN. På samma sätt måste den skrivskyddade routningen till FCI-repliken använda FCI DNN om FCI används som skrivskyddad replik.

Formatet för speglingsslutpunkten är: ENDPOINT_URL = 'TCP://<FCI DNN DNS name>:<mirroring endpoint port>'.

Om ditt FCI DNN DNS-namn till exempel är dnnlsnr, och 5022 är porten för FCI:ns speglingsslutpunkt, ser kodfragmentet Transact-SQL (T-SQL) för att skapa slutpunkts-URL:en ut så här:

ENDPOINT_URL = 'TCP://dnnlsnr:5022'

På samma sätt är formatet för den skrivskyddade routnings-URL:en: TCP://<FCI DNN DNS name>:<SQL Server instance port>.

Om ditt DNN DNS-namn till exempel är dnnlsnr, och 1444 är porten som används av det skrivskyddade SQL Server FCI-målet, ser T-SQL-kodfragmentet för att skapa den skrivskyddade routnings-URL:en ut så här:

READ_ONLY_ROUTING_URL = 'TCP://dnnlsnr:1444'

Du kan utelämna porten i URL:en om det är standardporten 1433. För en namngiven instans konfigurerar du en statisk port för den namngivna instansen och anger den i url:en för skrivskyddad routning.

Distribuerad tillgänglighetsgrupp

Om du konfigurerar din tillgänglighetsgruppslyssnare med hjälp av ett distribuerat nätverksnamn (DNN) kan du inte konfigurera en distribuerad tillgänglighetsgrupp ovanpå tillgänglighetsgruppen.

Replication

Transaktions-, sammanslagnings- och ögonblicksbildsreplikering stödjer alla att byta ut VNN-lyssnaren mot DNN-lyssnaren och porten i de replikeringsobjekt som är anslutna till lyssnaren.

Mer information om hur du använder replikering med tillgänglighetsgrupper finns i Utgivare och tillgänglighetsgrupp, Prenumerant och tillgänglighetsgrupp samt distributör och tillgänglighetsgrupp.

MSDTC

Både lokal och klustrad MSDTC stöds, men MSDTC använder en dynamisk port. Den här dynamiska porten kräver en Standard Azure Load Balancer för att konfigurera HA-porten. Den virtuella datorn måste därför använda en standard-IP-reservation, eller så kan du inte exponera den för Internet.

Definiera två regler: en för RPC Endpoint Mapper-port 135 och en för den verkliga MSDTC-porten. Efter redundansväxlingen ändrar du lastbalanserarens regel till den nya MSDTC-porten när den har ändrats på den nya noden.

Om MSDTC är lokal måste du tillåta utgående kommunikation.

Distribuerad fråga

Distribuerad fråga förlitar sig på en länkad server, som du kan konfigurera med AG DNN-lyssnaren och porten. Om porten inte är 1433 väljer du alternativet Använd annan datakälla i SQL Server Management Studio (SSMS) när du konfigurerar den länkade servern.

FILESTREAM

FILESTREAM stöds men inte för scenarier där användare får åtkomst till den avgränsade filresursen med hjälp av Windows-fil-API:et.

FileTable

FileTable stöds men inte för scenarier där användare får åtkomst till den begränsade fildelningen via Windows File API.

Länkade servrar

Konfigurera länkad server med AG DNN-lyssnarnamn och port. Om porten inte är 1433 väljer du alternativet Använd annan datakälla i SQL Server Management Studio (SSMS) när du konfigurerar den länkade servern.

Vanliga frågor

Vilken SQL Server-version stöder AG DNN-lyssnare?

SQL Server 2019 CU 8 och senare versioner.

Vilken är den förväntade redundanstiden när jag använder DNN-lyssnaren?

För DNN-lyssnaren är failovertiden densamma som AG-failovertiden, utan extra tid (till exempel sondtid när du använder Azure Load Balancer).

Finns det något versionskrav för ATT SQL-klienter ska ha stöd för DNN med OLEDB och ODBC?

Använd anslutningssträngen MultiSubnetFailover=True för stöd för DNN-lyssnare. Den är tillgänglig från och med SQL Server 2012 (11.x).

Krävs det några konfigurationsändringar för SQL Server för att jag ska kunna använda DNN-lyssnaren?

SQL Server kräver ingen konfigurationsändring för att använda DNN, men vissa SQL Server-funktioner kan kräva mer övervägande.

Stöder DNN kluster med flera undernät?

Ja. Klustret binder DNN i DNS med de fysiska IP-adresserna för alla repliker i tillgänglighetsgruppen oavsett undernät. SQL-klienten försöker alla IP-adresser för DNS-namnet oavsett undernät.

Stöder tillgänglighetsgruppens DNN-lyssnare skrivskyddad routing?

Ja. Skrivskyddad routning stöds med DNN-lyssnaren.

Relaterat innehåll

  • Last updated on