Dela via

SqlClient-stöd för hög tillgänglighet, katastrofåterställning

Ladda ned ADO.NET

I det här avsnittet beskrivs Microsoft SqlClient Data Provider med stöd för SQL Server för hög tillgänglighet och katastrofåterställning – Always On-tillgänglighetsgrupper. Funktionen AlwaysOn-tillgänglighetsgrupper lades till i SQL Server 2012. Mer information om AlwaysOn-tillgänglighetsgrupper finns i SQL Server Books Online.

Nu kan du ange tillgänglighetsgruppens lyssnare för en tillgänglighetsgrupp (tillgänglighetsgrupp med hög tillgänglighet, haveriberedskap) eller SQL Server 2012-klusterinstans för redundanskluster i anslutningsegenskapen. Om ett SqlClient-program är anslutet till en AlwaysOn-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änglighetsgruppslyssnare eller SQL Server 2012 Redundansklusterinstans, 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 till en tillgänglighetsgruppslyssnare eller SQL Server 2012 Redundansklusterinstans försöker SqlClient upprätta anslutningar till alla IP-adresser parallellt och om ett anslutningsförsök lyckas tar drivrutinen bort alla väntande anslutningsförsök.

Anmärkning

Om du ökar tidsgränsen för anslutningen och implementerar logik för omförsök av anslutningar ökar sannolikheten för att ett program ansluter till en tillgänglighetsgrupp. Dessutom, eftersom en anslutning kan misslyckas på grund av en redundansväxling, bör du implementera logik för att återförsöka anslutningen, och försöka ansluta på nytt tills anslutningen är återställd.

Följande anslutningsegenskaper stöds i Microsoft SqlClient Data Provider för SQL Server:

  • ApplicationIntent

  • MultiSubnetFailover

Du kan programmatiskt ändra dessa nyckelord för anslutningssträngar med:

Ansluta med MultiSubnetFailover

Ange MultiSubnetFailover=True alltid när du ansluter till en SQL Server 2012-tillgänglighetsgrupplyssnare eller SQL Server 2012 Redundansklusterinstans. MultiSubnetFailover möjliggör snabbare redundans för alla tillgänglighetsgrupper och eller redundansklusterinstanser i SQL Server 2012 och minskar redundanstiden avsevärt 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 felöverlämning av undernätet kommer systemet att aggressivt försöka återansluta TCP-anslutningen.

Anslutningsegenskapen MultiSubnetFailover anger att programmet distribueras i en tillgänglighetsgrupp eller SQL Server 2012 Redundansklusterinstans 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 antingen en AlwaysOn-tillgänglighetsgrupp eller en AlwaysOn-redundansklusterinstans, och gäller för både tillgänglighetsgrupper för enskilda och flera undernät och redundansklusterinstanser.

Mer information om nyckelord för anslutningssträngar i SqlClient finns i ConnectionString.

Att ange MultiSubnetFailover=True när du ansluter till något annat än en tillgänglighetsgruppslyssnare eller en SQL Server 2012-failover-klusterinstans kan leda till en negativ påverkan på prestandan och stöds inte.

Använd följande riktlinjer för att ansluta till en server i en tillgänglighetsgrupp eller SQL Server 2012 Redundansklusterinstans:

  • 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 gruppens lyssnare som servern i anslutningssträngen.

  • 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 att rymma övergångstid vid fel och reducera anslutningsförsök av program.

  • Distribuerade transaktioner stöds inte.

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

  • Om den sekundära replikplatsen inte har konfigurerats för att acceptera anslutningar.

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

SqlDependency är inte kompatibel med skrivskyddade sekundära repliker.

En anslutning kommer att misslyckas om en primär replik har konfigurerats för att avvisa arbetsbelastningar som är read-only och anslutningssträngen innehåller ApplicationIntent=ReadOnly.

Uppgradera från databasspegling för att använda kluster med flera undernät

Ett anslutningsfel (ArgumentException) inträffar om nyckelorden MultiSubnetFailover och Failover Partner anslutningen finns i anslutningssträngen, eller om MultiSubnetFailover=True och ett annat protokoll än TCP används. Ett fel (SqlException) kommer också att inträffa om MultiSubnetFailover används och SQL Server returnerar ett svar från en failover-partner som indikerar 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ängen 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å en primär databas inom tillgänglighetsgruppen och om MultiSubnetFailover=True används i anslutningssträngen som ansluter till denna primära databas i stället för till tillgänglighetsgrupplyssnaren.

Ange program avsikt

När ApplicationIntent=ReadOnlybegär klienten en läsarbetsbelastning när den ansluter till en AlwaysOn-aktiverad databas. Servern kommer att upprätthålla avsikten vid anslutning och under ett USE-databaskommando, men endast till en Always On-aktiverad databas.

Nyckelordet ApplicationIntent fungerar inte med äldre, skrivskyddade databaser.

En databas kan tillåta eller inte tillåta läsarbetsbelastningar för den målinriktade AlwaysOn-databasen. (Detta görs med ALLOW_CONNECTIONS -satsen i PRIMARY_ROLE - och SECONDARY_ROLE -Transact-SQL-uttrycken.)

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

Skrivskyddad routning

Skrivskyddad routning är en funktion som kan säkerställa 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 för anslutningssträngen ApplicationIntent måste vara inställt på ReadOnly.

  • Tillgänglighetsgruppen måste konfigureras av databasadministratören för att aktivera skrivskyddad routning.

Det kan hända att flera anslutningar via skrivskyddad routning inte ansluter alla till samma skrivskyddade replika. Ä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 för anslutningssträngen Data Source . Ange istället namnet på 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. Därför bör du öka tidsgränsen för inloggning.

Nästa steg

  • Last updated on