Som DBA:er stöter vi i allmänhet på att våra kunder klagar på att den nuvarande produktionsservern inte kan hålla belastningen på servern och om belastningen kan vara balanserad med den sekundära servern. Detta är möjligt med en databas i DR Server med skrivskyddad databas i Log Shipping och sekundära SQL Server-repliker i Always On Availability Group. Den största fördelen med Always On Groups är att det tillåter oss att ställa in gruppnivå HA för valfritt antal databaser och vi kan skapa upp till fyra sekundära repliker och detta är en kombination av Clustering, Log Shipping och Database Mirroring där dataöverföringen sker mer flexibel och funktionell.
Always On Readable Secondary Replica har en funktion för att hantera särskilda skrivskyddade anslutningsförfrågningar som kallas Read-only routing. I allmänhet är både läs- och läsavsikten som standard riktade till den primära repliken och ingenting är avsett för de sekundära replikerna. Nu kan de sekundära replikerna inte bara användas för säkerhetskopiering, DBCC och rapporteringsändamål, utan kan också efterfrågas i framtiden genom att använda "ReadOnly" som applikationsavsikt i applikationens anslutningssträng.
Vi har tre repliker SQL1, SQL2 och SQL3 i Windows failover-klustret. Varje nod har en fristående SQL Server 2012-instans installerad och konfigurerad med Always On AG. Vi är alltid på AG Group som heter "CODEAG" med lyssnarnamnet "CODELIS"
I följande skärmdump är SQL1 en primär replik, SQL2 är en sekundär replik, SQL3 är en sekundär replik.
Så här konfigurerar du en skrivskyddad ruttlista i alltid tillgängliga grupper
Steg 1:
Anslutningar görs till tillgänglighetsgruppen med hjälp av lyssnarens namn eller IP. För att skapa flera lyssnare för en tillgänglighetsgrupp, följ proceduren nedan.
För att manuellt skapa eller konfigurera en lyssnare för en tillgänglighetsgrupp
- Under Objektutforskaren ansluter du till instansen som innehåller den primära repliken av tillgänglighetsgruppen.
- Utöka AON-gruppen och klicka på tillgänglighetsgruppen för vilken vi försöker konfigurera lyssnaren manuellt och fortsätt.
- Högerklicka på Availability Group Listeners Node och välj New Listener Command. Detta öppnar en ny dialogruta för att konfigurera en lyssnare.
- Portnummer för en befintlig avlyssnare kan ändras genom att utöka noden för tillgänglighetsgrupplyssnare följt av högerklicka på lyssnarna och välja egenskaperna.
- Skriv nu in det nya portnumret och klicka på OK.
Identifiera lyssnarnamnet som konfigurerats för Always On-replikering genom att fråga DMV enligt nedan.
SELECT AV.name AS AVGName , AVGLis.dns_name AS ListenerName , AVGLis.ip_configuration_string_from_cluster AS ListenerIP FROM sys.availability_group_listeners AVGLis INNER JOIN sys.availability_groups AV on AV.group_id = AV.group_id
I följande skärmdump är AG-gruppens namn CODEAG och AG-lyssnarens IP är CODELIS.
Steg 2:
För att konfigurera skrivskyddad routing måste vi konfigurera replikerna till enbart läsavsikter för att tillåta skrivskyddade anslutningar till sekundära repliker.
- Anslut till instansen som innehåller den primära repliken.
- Utöka AON High Availability Node, sedan AG Group Node.
- Klicka på AG-gruppen vars replik ska ändras.
- Högerklicka på repliken och välj egenskaper för att ändra anslutningsåtkomsten för de primära och sekundära rollerna enligt följande.
Den sekundära rollen har ett nytt värde från den läsbara sekundära släpplistan.
Endast läsavsikt
Det här alternativet tillåter läsåtkomst för de sekundära databaserna för denna replik. Endast skrivskyddade anslutningar är tillåtna.
Ja
Det här alternativet tillåter endast läsåtkomst men alla anslutningar är tillåtna för den sekundära repliken.
Nej
Detta stoppar alla användaranslutningar till den sekundära repliken och tillåter dig inte ens att läsa.
Ställ in de läsbara sekundära egenskaperna till Endast läsavsikt.
I följande skärmdump är de läsbara sekundära egenskaperna för varje sekundär replik inställd på Read-intent only.
Steg 3:
Varje läsbar sekundär replik kan tilldelas en skrivskyddad routing-URL som kommer att användas för att dirigera anslutningsförfrågningar med läsavsikt till en specifik läsbar sekundär replik.
Använd T-SQL för att ange en skrivskyddad routing-URL för alla replikerna i vår tillgänglighetsgrupp.
ALTER AVAILABILITY GROUP [CODEAG] MODIFY REPLICA ON N'SQL1' WITH (SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY)); ALTER AVAILABILITY GROUP [CODEAG] MODIFY REPLICA ON N'SQL1' WITH (SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://SQL1.abc.com:17999')); ALTER AVAILABILITY GROUP [CODEAG] MODIFY REPLICA ON N'SQL2' WITH (SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY)); ALTER AVAILABILITY GROUP [CODEAG] MODIFY REPLICA ON N'SQL2' WITH (SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://SQL2.abc.com:17999')); ALTER AVAILABILITY GROUP [CODEAG] MODIFY REPLICA ON N'SQL3' WITH (SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY)); ALTER AVAILABILITY GROUP [CODEAG] MODIFY REPLICA ON N'SQL3' WITH (SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://SQL3.abc.com:17999'));
Steg 4:
För repliken som vi markerar som skrivskyddad routing när den är den primära repliken, finns det ett behov av att specificera en skrivskyddad routinglista och detta sker endast när den lokala repliken körs under den primära rollen.
ALTER AVAILABILITY GROUP [CODEAG]
MODIFY REPLICA ON
N'SQL1' WITH
(PRIMARY_ROLE (READ_ONLY_ROUTING_LIST=('SQL2','SQL3')));
ALTER AVAILABILITY GROUP [CODEAG]
MODIFY REPLICA ON
N'SQL3' WITH
(PRIMARY_ROLE (READ_ONLY_ROUTING_LIST=('SQL2','SQL1')));
ALTER AVAILABILITY GROUP [CODEAG]
MODIFY REPLICA ON
N'SQL2' WITH
(PRIMARY_ROLE (READ_ONLY_ROUTING_LIST=('SQL3','SQL1')));
I skriptet ovan, exemplet när SQL1 är den primära repliken, kommer arbetsbelastningen med endast läsavsikt att omdirigeras till de läsbara sekundära replikerna; SQL2 respektive SQL3:på liknande sätt, om SQL3 är den primära repliken, kommer arbetsbelastningen med endast läsavsikt att omdirigeras till de läsbara sekundära replikerna; SQL2 respektive SQL1.
Skrivskyddad trafik kommer att dirigeras till den första tillgängliga repliken tills och om den inte är tillgänglig skulle den dirigera trafiken till nästa tillgängliga replik i routinglistan. När du har mer än en replik är det inte möjligt att dela belastningen mellan repliker fram till SQL Server 2012 och 2014. Men SQL Server 2016 låter dig balansera belastningen mellan skrivskyddade repliker.
Exempel:
ALTER AVAILABILITY GROUP [CODEAG]
MODIFY REPLICA ON
N'SQL2' WITH
(PRIMARY_ROLE (READ_ONLY_ROUTING_LIST=(('SQL3','SQL1'), ‘SQL2’)));
Det här routinglistans beteende "belastningsbalanserar" skrivskyddade anslutningar mellan SQL3 och SQL1. Ovan har vi två inbäddade listor i routinglistan:
Lista 1:'SQL3', 'SQL1'
Lista 2:'SQL2'
Rutt till replikerna i den första listan. SQL3 och SQL1 är tillgängliga för skrivskyddade anslutningar. Den första inkommande skrivskyddade anslutningen kommer att dirigeras till SQL3, den andra skrivskyddade anslutningen dirigeras till SQL1, den tredje skrivskyddade anslutningen dirigeras till SQL3, den fjärde skrivskyddade anslutningen kommer att dirigeras till SQL1, och så vidare, med en "round-robin"-fördelning av skrivskyddade anslutningar mellan de två replikerna i den första listan.
Om några repliker blir otillgängliga fortsätter routing med återstående repliker i den första listan. Om SQL3 eller SQL1 blir otillgängliga för skrivskyddade anslutningar, kommer de skrivskyddade anslutningarna endast att dirigeras till de tillgängliga skrivskyddade replikerna i den första listan. Till exempel, om SQL3 inte är synkroniserat eller ALLOW_CONNECTIONS är inställt på NO, så kommer alla skrivskyddade anslutningar att dirigeras till SQL1. Så länge en av servrarna är tillgänglig för skrivskyddade anslutningar kommer INGA skrivskyddade anslutningar att dirigeras till SQL2.
Om alla repliker i den första listan är otillgängliga, väg till repliker i nästa lista. Om SQL3 och SQL1 blir otillgängliga för skrivskyddade anslutningar, kommer alla skrivskyddade anslutningar endast att dirigeras till nästa lista med repliker, som i det här fallet är SQL2.
Återuppta dirigeringen till den första listan om några repliker blir tillgängliga. När sekundära repliker som har högre prioritet i listan blir tillgängliga för skrivskyddade anslutningar, kommer framtida skrivskyddade anslutningar att ansluta till dem vid behov.
I SQL Server 2016 kan du konfigurera lastbalansering över en uppsättning skrivskyddade repliker.
Steg 5:
sys.availability_read_only_routing_lists DMV, som returnerar den skrivskyddade routningslistan för varje tillgänglighetsgruppreplik i gruppen Always On Availability.
SELECT AVGSrc.replica_server_name AS SourceReplica , AVGRepl.replica_server_name AS ReadOnlyReplica , AVGRepl.read_only_routing_url AS RoutingURL , AVGRL.routing_priority AS RoutingPriority FROM sys.availability_read_only_routing_lists AVGRL INNER JOIN sys.availability_replicas AVGSrc ON AVGRL.replica_id = AVGSrc.replica_id INNER JOIN sys.availability_replicas AVGRepl ON AVGRL.read_only_replica_id = AVGRepl.replica_id INNER JOIN sys.availability_groups AV ON AV.group_id = AVGSrc.group_id ORDER BY SourceReplica
I följande skärmdump visar resultatet routing-URL och routing-prioritet.
Steg 6:
För att testa skrivskyddad routing med SQLCMD, använd –K ReadOnly-parameter som visar sekundära replikmottagande läsanslutningar enligt routinglistan.
I följande skärmdump accepterar den sekundära repliken läsanslutningarna, dvs... SQL2.
Steg 7:
Failover tillgänglighetsgruppen och testa skrivskyddad routing.
- I Objektutforskaren ansluter du till en serverinstans som är värd för en sekundär replik av tillgänglighetsgruppen som måste misslyckas. Expandera serverträdet.
- Utöka noden AlwaysOn High Availability och Availability Groups-noden.
- Högerklicka på tillgänglighetsgruppen som du vill misslyckas med och välj Failover.
Nu blir SQL2 primär replik och anslutningar hanteras av SQL1.
Anslutningssträngsyntaxen som programmet ska använda beror på SQL Server Provider.
Om det är .Net Framework Data Provider 4.0.2 för SQL Server blir syntaxen följande:
Server=tcp:MyAgListener,portnumber;Database=SQL1;IntegratedSecurity=SSPI;ApplicationIntent=ReadOnly;MultiSubnetFailover=True
Slutsats:
För att minska arbetsbelastningen är denna skrivskyddade routing fortfarande det bästa alternativet. En applikation som involverar SQL Server Reporting Services som är värd i SharePoint eller Native Mode-installationen av Report Server kan använda skrivskyddad avsikt som undviker typisk blockering, minne och CPU-användning på primära noder.