Dela via

SqlClient-stöd för hög tillgänglighet och haveriberedskap

  • Artikel

I den här artikeln beskrivs SqlClient-stöd (tillagt i .NET Framework 4.5) för hög tillgänglighet och haveriberedskap med AlwaysOn-funktionerna: AlwaysOn-tillgänglighetsgrupper (AG:er) och Always On-redundansklusterinstanser (FCIs) med SQL Server 2012 eller senare.

Nu kan du ange en tillgänglighetsgruppslyssnare eller namnet på en FCI i anslutningsegenskapen. Om ett SqlClient-program är anslutet till en databas som redundansväxlar bryts den ursprungliga anslutningen och programmet måste öppna en ny anslutning för att fortsätta arbeta efter redundansväxlingen.

Om du inte ansluter till en tillgänglighetsgrupp eller FCI, och om flera IP-adresser är associerade med ett värdnamn, itererar SqlClient sekventiellt genom alla IP-adresser som är associerade med DNS-post. Detta kan vara tidskrävande om den första IP-adressen som returneras av DNS-servern inte är bunden till något nätverkskort (NIC). När du ansluter en FCI eller till lyssnaren för en tillgänglighetsgrupp försöker SqlClient upprätta anslutningar till alla IP-adresser parallellt. Om ett anslutningsförsök lyckas tar drivrutinen bort alla väntande anslutningsförsök.

Kommentar

Sannolikheten att ett program kan ansluta till en tillgänglighetsgrupp ökar om du ökar tidsgränsen för anslutningar och implementerar logik för anslutningsförsök. Eftersom en anslutning kan misslyckas på grund av en redundansväxling bör du implementera logik för återförsök av anslutningen och försöka ansluta igen tills den återansluts.

Följande anslutningsegenskaper har lagts till i SqlClient i .NET Framework 4.5:

  • ApplicationIntent
  • MultiSubnetFailover

Du kan programmatiskt ändra dessa anslutningssträng nyckelord med:

Kommentar

Inställningen MultiSubnetFailover till true krävs inte med .NET Framework-versionerna 4.6.1 och senare. Det krävs i .NET Core och .NET 5+.

Ansluta med MultiSubnetFailover

Ange MultiSubnetFailover=True alltid när du ansluter till FCI eller lyssnaren för en tillgänglighetsgrupp. MultiSubnetFailover möjliggör snabbare redundans för alla AG:er och eller FCI:er i SQL Server 2012 eller senare och avsevärt minskar redundanstiden för always on-topologier med ett och flera undernät. Under en redundansväxling med flera undernät försöker klienten ansluta parallellt. Under en redundansväxling i undernätet försöker klienten aggressivt återförsöka TCP-anslutningen.

Anslutningsegenskapen MultiSubnetFailover anger att programmet använder antingen en tillgänglighetsgrupp eller FCI och att SqlClient försöker ansluta till databasen på den primära SQL Server-instansen genom att försöka ansluta till alla IP-adresser. När MultiSubnetFailover=True har angetts för en anslutning försöker klienten återförsök med TCP-anslutningen snabbare än operativsystemets standardintervall för TCP-återöverföring. Detta möjliggör snabbare återanslutning efter redundansväxling av en tillgänglighetsgrupp eller FCI, och gäller både AG:er och FCI:er för både ett och flera undernät.

Mer information om anslutningssträng nyckelord i SqlClient ConnectionStringfinns i .

Om du MultiSubnetFailover=True anger när du ansluter till något annat än en tillgänglighetsgrupp eller FCI kan det leda till en negativ prestandapåverkan och stöds inte.

Använd följande riktlinjer för att ansluta till en server med någon av AlwaysOn-funktionerna:

  • Använd anslutningsegenskapen MultiSubnetFailover när du ansluter till ett enda undernät eller flera undernät. Det förbättrar prestandan för båda.

  • Om du vill ansluta till en tillgänglighetsgrupp anger du lyssnaren för tillgänglighetsgruppen som server i anslutningssträng.

  • Anslutning till en SQL Server-instans som konfigurerats med fler än 64 IP-adresser orsakar ett anslutningsfel.

  • Beteendet för ett program som använder anslutningsegenskapen MultiSubnetFailover påverkas inte baserat på typen av autentisering: SQL Server-autentisering, Kerberos-autentisering eller Windows-autentisering.

  • Öka värdet Connect Timeout för för att hantera för redundans och minska återförsök av programanslutning.

  • Distribuerade transaktioner stöds inte.

Om skrivskyddad routning inte tillämpas misslyckas anslutningen till en sekundär replikplats i följande situationer:

  • Om platsen för sekundära repliker inte har konfigurerats att acceptera anslutningar.

  • Om ett program använder ApplicationIntent=ReadWrite (beskrivs nedan) och den sekundära replikplatsen har konfigurerats för skrivskyddad åtkomst.

SqlDependency stöds inte på skrivskyddade sekundära repliker.

En anslutning misslyckas om en primär replik har konfigurerats för att avvisa skrivskyddade arbetsbelastningar och anslutningssträng innehåller ApplicationIntent=ReadOnly.

Uppgradera till kluster med flera undernät från databasspegling

Ett anslutningsfel (ArgumentException) inträffar om nyckelorden MultiSubnetFailover och Failover Partner anslutningen finns i anslutningssträng, eller om MultiSubnetFailover=True och ett annat protokoll än TCP används. Ett fel (SqlException) inträffar också om MultiSubnetFailover används och SQL Server returnerar ett partnersvar för redundans som anger att det är en del av ett databasspeglingspar.

Om du uppgraderar ett SqlClient-program som för närvarande använder databasspegling till ett scenario med flera undernät bör du ta bort anslutningsegenskapen Failover Partner och ersätta den med MultiSubnetFailover inställt True på och ersätta servernamnet i anslutningssträng med en tillgänglighetsgrupplyssnare. Om en anslutningssträng använder Failover Partner och MultiSubnetFailover=Truegenererar drivrutinen ett fel. Men om en anslutningssträng använder Failover Partner och MultiSubnetFailover=False (eller ApplicationIntent=ReadWrite) använder programmet databasspegling.

Drivrutinen returnerar ett fel om databasspegling används på den primära databasen i tillgänglighetsgruppen och om MultiSubnetFailover=True används i anslutningssträng som ansluter till en primär databas i stället för till en tillgänglighetsgrupplyssnare.

Ange programavsikt

När ApplicationIntent=ReadOnlybegär klienten en läsarbetsbelastning när den ansluter till en AlwaysOn-aktiverad databas. Servern framtvingar avsikten vid anslutningstid och under en USE-databas-instruktion men endast till en AlwaysOn-aktiverad databas.

Nyckelordet ApplicationIntent fungerar inte med äldre, skrivskyddade databaser.

En databas kan tillåta eller neka icke skrivskyddade arbetsbelastningar för AlwaysOn-måldatabasen. (Detta görs med ALLOW_CONNECTIONS -satsen i transact-SQL-uttrycken PRIMARY_ROLE SECONDARY_ROLE.)

Nyckelordet ApplicationIntent används för att aktivera skrivskyddad routning.

Skrivskyddad routning

Skrivskyddad routning är en funktion som kan användas för att garantera tillgängligheten för en skrivskyddad replik av en databas. Så här aktiverar du skrivskyddad routning:

  • Du måste ansluta till en tillgänglighetsgruppslyssnare för AlwaysOn-tillgänglighetsgruppen.
  • Nyckelordet ApplicationIntent anslutningssträng måste anges till ReadOnly.
  • Databasadministratören måste konfigurera skrivskyddad routning för tillgänglighetsgruppen.

Alla anslutningar som använder skrivskyddad routning kanske inte ansluter till samma skrivskyddade replik. Ändringar i databassynkronisering eller ändringar i serverns routningskonfiguration kan resultera i klientanslutningar till olika skrivskyddade repliker. För att säkerställa att alla skrivskyddade begäranden ansluter till samma skrivskyddade replik skickar du inte en tillgänglighetsgrupplyssnare till nyckelordet Data Source anslutningssträng. Ange i stället namnet för den skrivskyddade instansen.

Skrivskyddad routning kan ta längre tid än att ansluta till den primära eftersom skrivskyddad routning först ansluter till den primära och sedan letar efter den bästa tillgängliga läsbara sekundära. Av den anledningen bör du öka tidsgränsen för inloggning.

Se även