SQL Server Native klientstöd för hög tillgänglighet och katastrofåterställning

gäller för:SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceAzure Synapse AnalyticsAnalytics Platform System (PDW)

Detta ämne diskuterar stöd för SQL Server Native Client (lagt till i SQL Server 2012 (11.x)) för Always On-tillgänglighetsgrupper. För mer information om Always On-tillgänglighetsgrupper, se Tillgänglighetsgrupplyssnare, Klientanslutning och applikationsfailover (SQL Server),Skapande och konfiguration av tillgänglighetsgrupper (SQL Server),Failover-klustring och Always On-tillgänglighetsgrupper (SQL Server) samt Aktiva sekundäraries: läsbara sekundära repliker (Always On tillgänglighetsgrupper).

Du kan ange tillgänglighetsgruppens lyssnare för en given tillgänglighetsgrupp i anslutningssträngen. Om en SQL Server Native Client-applikation är ansluten till en databas i en tillgänglighetsgrupp som failover, bryts den ursprungliga anslutningen och applikationen måste öppna en ny anslutning för att fortsätta arbetet efter failovern.

Om du inte ansluter till en tillgänglighetsgrupplyssnare, och om flera IP-adresser är kopplade till ett värdnamn, kommer SQL Server Native Client att iterera sekventiellt genom alla IP-adresser kopplade till DNS-inmatning. 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 man ansluter till en tillgänglighetsgruppslyssnare försöker SQL Server Native Client etablera anslutningar till alla IP-adresser parallellt, och om ett anslutningsförsök lyckas kommer drivrutinen att kassera alla väntande anslutningsförsök.

Ansluta med MultiSubnetFailover

Ange alltid MultiSubnetFailover=Ja när du ansluter till en SQL Server 2012 tillgänglighetsgrupplyssnare eller SQL Server 2012 Failover Cluster Instance. MultiSubnetFailover möjliggör snabbare failover för alla tillgänglighetsgrupper och failover-klusterinstanser i SQL Server 2012 och minskar avsevärt failovertiden för enkel- och multisubnäts Always On-topologier. Under en multi-subnet failover kommer klienten att försöka ansluta parallellt. Under en subnätsfailover kommer SQL Server Native Client aggressivt att försöka om TCP-anslutningen.

MultiSubnetFailover-anslutningsegenskapen indikerar att applikationen distribueras i en tillgänglighetsgrupp eller Failover Cluster Instance, och att SQL Server Native Client kommer att försöka ansluta till databasen på den primära SQL Server-instansen genom att försöka ansluta till alla IP-adresser. När MultiSubnetFailover=Yes anges för en anslutning, försöker klienten om TCP-anslutningsförsök snabbare än operativsystemets standardintervaller för TCP-återutsändning. 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.

För mer information om reťazec pripojenia-nyckelord, se Using Connection String Keywords with SQL Server Native Client.

Att specificera MultiSubnetFailover=Yes vid anslutning till något annat än en tillgänglighetsgrupplyssnare eller Failover Cluster Instance kan ge negativ prestandapåverkning och stöds inte.

Använd följande riktlinjer för att ansluta till en server i en tillgänglighetsgrupp eller Failover Cluster Instance:

• Använd MultiSubnetFailover-anslutningsegenskapen när du ansluter till ett enskilt subnät eller multi-subnät; Det kommer att förbättra 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 konfigurerad med fler än 64 IP-adresser orsakar anslutningsfel.

• Beteendet hos en applikation som använder MultiSubnetFailover-anslutningsegenskapen påverkas inte baserat på typen av autentisering: SQL Server-autentisering, Kerberos-autentisering eller Windows-autentisering.

• Du kan öka värdet på loginTimeout för att hantera failover-tid och minska försök att återansluta applikationer.

• Distribuerade transaktioner stöds inte.

Om skrivskyddad routing inte är i kraft kommer anslutning till en sekundär replikplats i en tillgänglighetsgrupp att misslyckas i följande situationer:

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

2. Om en applikation använder ApplicationIntent=ReadWrite (diskuterat nedan) och den sekundära replikplatsen är konfigurerad för skrivskyddad åtkomst.

En anslutning misslyckas om en primär replik är konfigurerad att avvisa arbetsbelastningar med skrivskyddad åtkomst och anslutningssträngen innehåller ApplicationIntent=ReadOnly.

Uppgradera till att använda kluster med flera undernät istället för databasspegling

Ett anslutningsfel uppstår om nyckelorden MultiSubnetFailover och Failover_Partner anslutning finns i anslutningssträngen. Ett fel uppstår också om MultiSubnetFailover används och SQL Server returnerar ett failover-partnersvar som indikerar att den är en del av ett databas-speglingspar.

Om du uppgraderar en SQL Server Native Client-applikation som för närvarande använder databasmirroring till ett multi-subnet-scenario, bör du ta bort egenskapen Failover_Partner connection och ersätta den med MultiSubnetFailover satt till Yes och ersätta servernamnet i reťazec pripojenia med en tillgänglighetsgruppslyssnare. Om en anslutningssträng använder Failover_Partner och MultiSubnetFailover=Yes, kommer drivrutinen att generera ett fel. Om en anslutningssträng använder Failover_Partner och MultiSubnetFailover=No (eller ApplicationIntent=ReadWrite), kommer applikationen att använda databasspegling.

Drivrutinen kommer att ge ett fel om databasspegling används på primärdatabasen i tillgänglighetsgruppen, och om MultiSubnetFailover=Yes används i anslutningssträngen som ansluter till en primär databas istället för till en tillgänglighetsgrupplyssnare.

Specificera applikationens avsikt

Du kan ange nyckelordet ApplicationIntent i din anslutningssträng. De tilldelbara värdena är ReadWrite (standardvärdena) eller ReadOnly.

När du sätter ApplicationIntent=ReadOnly, begär klienten en läsarbetsbelastning vid anslutning. Servern tillämpar avsikten vid anslutning och under ett USE databasuttryck.

Nyckelordet ApplicationIntent fungerar inte med äldre skrivskyddade databaser.

Mål för ReadOnly

När en anslutning väljer ReadOnly, tilldelas anslutningen någon av följande speciella konfigurationer som kan finnas för databasen:

• Alltid på. En databas kan tillåta eller avvisa läsarbetsbelastningar på den avsedda tillgänglighetsgruppens databas. Detta val styrs genom att använda ALLOW_CONNECTIONS klausulen i PRIMARY_ROLE och SECONDARY_ROLE Transact-SQL-satserna.

• Geo-replication

• Lässkalbarhet

Om inga av dessa specialmål är tillgängliga läser man i stället från den vanliga databasen.

Nyckelordet ApplicationIntent möjliggör skrivskyddad routing.

Skrivskyddad routing

Skrivskyddad routning är en funktion som kan säkerställa tillgången till en skrivskyddad kopia av en databas. För att aktivera skrivskyddad routning gäller samtliga följande villkor:

• Du måste koppla upp dig till en lyssnare i Always On-tillgänglighetsgruppen.

• Nyckelordet för anslutningssträngen ApplicationIntent måste vara inställt på ReadOnly.

• Databasadministratören måste konfigurera tillgänglighetsgruppen för att möjliggöra skrivskyddad routing.

Flera anslutningar som var och en använder skrivskyddad routing ansluter kanske inte alla till samma skrivskyddade replik. Ändringar i databassynkronisering eller ändringar i serverns routningskonfiguration kan resultera i klientanslutningar till olika skrivskyddade repliker.

Du kan säkerställa att alla skrivskyddade förfrågningar ansluter till samma skrivskyddade replika genom att inte skicka en tillgänglighetsgrupplyssnare till anslutningssträngens Server nyckelord. Ange istället namnet på den skrivskyddade instansen.

Read-only-routing kan ta längre tid än att ansluta till primären. Detta beror på att read-only-routing först kopplas till primären och sedan letar efter den bästa tillgängliga läsbara sekundären. På grund av dessa flera steg bör du öka din login timeout till minst 30 sekunder.

ODBC

Två ODBC-reťazec pripojenia-nyckelord lades till för att stödja Always On-tillgänglighetsgrupper i SQL Server Native Client:

• ApplicationIntent

• MultiSubnetFailover

För mer information om ODBC:s reťazec pripojenia-nyckelord i SQL Server Native Client, se Using Connection String Keywords with SQL Server Native Client.

De ekvivalenta anslutningsegenskaperna är:

• SQL_COPT_SS_APPLICATION_INTENT

• SQL_COPT_SS_MULTISUBNET_FAILOVER

För mer information om ODBC-anslutningsegenskaper i SQL Server Native Client, se SQLSetConnectAttr.

Funktionen hos nyckelorden ApplicationIntent och MultiSubnetFailover kommer att exponeras i ODBC Data Source Administrator för DSN som använder SQL Server Native Client-drivrutinen, med start i SQL Server 2012 (11.x).

En SQL Server Native Client ODBC-applikation kan använda en av tre funktioner för att skapa anslutningen:

OLE DB

OLE DB i SQL Server Native Client stöder inte nyckelordet MultiSubnetFailover.

OLE DB i SQL Server Native Client kommer att stödja applikationens avsikt. Applikationsavsikten kommer att fungera likadant för OLE DB-applikationer som för ODBC-applikationer (se ovan).

Ett OLE DB-reťazec pripojenia-nyckelord lagt till för att stödja Always On-tillgänglighetsgrupper i SQL Server Native Client:

• Program avsikt

För mer information om reťazec pripojenia-nyckelord i SQL Server Native Client, se Using Connection String Keywords with SQL Server Native Client.

De ekvivalenta anslutningsegenskaperna är:

• SSPROP_INIT_APPLICATIONINTENT

• DBPROP_INIT_PROVIDERSTRING

En SQL Server Native Client OLE DB-applikation kan använda en av metoderna för att specificera applikationens avsikt:

IDBInitialize::Initialize
IDBInitialize::Initialize använder den tidigare konfigurerade uppsättningen egenskaper för att initiera datakällan och skapa datakällobjektet. Ange applikationsavsikt som en leverantörsegenskap eller som en del av den utökade egenskapssträngen.

IDataInitialize::GetDataSource
IDataInitialize::GetDataSource tar en inmatningsanslutningssträng som kan innehålla nyckelordet Application Intent .

IDBProperties::GetProperties
IDBProperties::GetProperties hämtar värdet på egenskapen som för närvarande är inställd på datakällan. Du kan hämta applikationsintentionsvärdet genom DBPROP_INIT_PROVIDERSTRING-egenskapen och SSPROP_INIT_APPLICATIONINTENT-egenskapen.

IDBProperties::SetProperties
För att sätta egenskapsvärdet ApplicationIntent , anropa IDBProperties::SetProperties och skickar in egenskapen SSPROP_INIT_APPLICATIONINTENT med värdet "ReadWrite" eller "ReadOnly" eller DBPROP_INIT_PROVIDERSTRING egenskap med värde som innehåller "ApplicationIntent=ReadOnly" eller "ApplicationIntent=ReadWrite".

Du kan ange applikationsavsikt i fältet Application Intent Properties på fliken Alla i dialogrutan Data Link Properties .

När implicita anslutningar upprättas kommer den implicita anslutningen att använda applikationsintentionsinställningen för moderanslutningen. På samma sätt kommer flera sessioner skapade från samma datakälla att ärva datakällans applikationsintentionsinställning.

Relaterat innehåll

• inbyggda klientfunktioner i SQL Server
• Använda nyckelord för anslutningssträngar med den interna SQL Server-klienten