Skrivebeskyttet routing for en Always On

Som DBA'er støder vi generelt på vores kunder, der klager over, at den nuværende produktionsserver ikke er i stand til at holde belastningen på serveren, og om belastningen kan være afbalanceret med den sekundære server. Dette er muligt med en database i DR Server med Read-only database i Log Shipping og Secondary SQL Server replikaer i Always On Availability Group. Den største fordel ved Always On Groups er, at det giver os mulighed for at opsætte gruppeniveau HA for et vilkårligt antal databaser, og vi kan oprette op til fire sekundære replikaer, og dette er en kombination af Clustering, Log Shipping og Database Mirroring, hvor datatransmissionen er mere fleksibel og funktionel.

Always On Readable Secondary Replica har en funktion til at håndtere bestemte skrivebeskyttede forbindelsesanmodninger kaldet Read-only routing. Generelt er både læse- og læsehensigten som standard rettet til den primære replika, og intet er beregnet til de sekundære replikaer. Nu kan de sekundære replikaer ikke kun bruges til sikkerhedskopiering, DBCC og rapporteringsformål, men kan også forespørges i fremtiden ved at bruge 'ReadOnly' som deres Application Intent i applikationsforbindelsesstrengen.

Vi har tre replikaer SQL1, SQL2 og SQL3 i Windows failover-klyngen. Hver node har en selvstændig SQL Server 2012-instans installeret og konfigureret med Always On AG. Vi er altid på AG Group med navnet "CODEAG" med lytterens navn "CODELIS"

I det følgende skærmbillede er SQL1 en primær replika, SQL2 er en sekundær replika, SQL3 er en sekundær replika.

Sådan konfigurerer du skrivebeskyttet routingliste i grupper, der altid er tilgængelige

Trin 1:

Forbindelser oprettes til tilgængelighedsgruppen ved hjælp af lytterens navn eller IP. For nu at oprette flere lyttere til én tilgængelighedsgruppe, følg venligst nedenstående procedure.

For manuelt at oprette eller konfigurere en lytter til en tilgængelighedsgruppe

Under Objekt Explorer skal du oprette forbindelse til den instans, der har den primære replika af tilgængelighedsgruppen.
Udvid AON-gruppen, og klik på den tilgængelighedsgruppe, som vi forsøger at manuelt konfigurere lytteren for, og fortsæt.
Højreklik på Availability Group Listeners Node, og vælg New Listener Command. Dette åbner en ny dialogboks til konfiguration af en lytter.
Portnummeret på en eksisterende lytter kan ændres ved at udvide noden for tilgængelighedsgruppelyttere efterfulgt af at højreklikke på lytterne og vælge egenskaberne.
Indtast nu det nye portnummer, og klik på OK.

Identificer lytternavnet, der er konfigureret til Always On-replikering, ved at forespørge DMV som nedenfor.

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 det følgende skærmbillede er AG-gruppens navn CODEAG, og AG-lytterens IP er CODELIS.

Trin 2:

For at konfigurere skrivebeskyttet routing skal vi konfigurere replikaerne til kun at læse-hensigten for at tillade skrivebeskyttede forbindelser til sekundære replikaer.

Opret forbindelse til den forekomst, der indeholder den primære replika.
Udvid AON High Availability Node og derefter AG Group Node.
Klik på den AG-gruppe, hvis replika skal ændres.
Højreklik på replikaen, og vælg egenskaber for at ændre forbindelsesadgangen for de primære og sekundære roller som følger.

Den sekundære rolle har en ny værdi fra den læsbare sekundære dropliste.

Kun læsehensigt

Denne mulighed giver læseadgang til de sekundære databaser i denne replika. Kun skrivebeskyttede forbindelser er tilladt.

Denne indstilling tillader kun læseadgang, men alle forbindelser er tilladt for den sekundære replika.

Nej

Dette stopper alle brugerforbindelser til den sekundære replika og giver dig ikke engang mulighed for at læse.

Indstil de læsbare sekundære egenskaber til Kun læsehensigt.

I det følgende skærmbillede er de læsbare sekundære egenskaber for hver sekundær replika indstillet til Kun læsehensigt.

Trin 3:

Hver læsbar sekundær replika kan tildeles en skrivebeskyttet routing-URL, der vil blive brugt til at dirigere læsehensigtsforbindelsesanmodninger til en specifik læsbar sekundær replika.

Brug T-SQL til at angive en skrivebeskyttet routing-URL for alle replikaerne i vores tilgængelighedsgruppe.

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'));

Trin 4:

For den replika, som vi markerer som skrivebeskyttet routing, når det er den primære replika, er der behov for at specificere en skrivebeskyttet routingliste, og dette bliver kun effektueret, når den lokale replika kører under den primære rolle.

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 ovenstående script, eksemplet når SQL1 er den primære replika, vil arbejdsbelastningen med kun læsehensigt blive omdirigeret til de læsbare sekundære replikaer; hhv. SQL2 og SQL3:på samme måde, hvis SQL3 er den primære replika, vil arbejdsbelastningen med kun læsehensigt blive omdirigeret til de læsbare sekundære replikaer; henholdsvis SQL2 og SQL1.

Skrivebeskyttet trafik vil blive dirigeret til den første tilgængelige replika, indtil og medmindre den ikke er tilgængelig, vil den dirigere trafikken til den næste tilgængelige replika på routinglisten. Når du har mere end én replika, er det ikke muligt at dele belastningen mellem replikaer indtil SQL Server 2012 og 2014. Men SQL Server 2016 giver dig mulighed for at afbalancere belastningen mellem skrivebeskyttede replikaer.

Eksempel:

ALTER AVAILABILITY GROUP [CODEAG]
MODIFY REPLICA ON
N'SQL2' WITH
(PRIMARY_ROLE (READ_ONLY_ROUTING_LIST=(('SQL3','SQL1'), ‘SQL2’)));

Denne routinglisteadfærd "belastningsbalancerer" skrivebeskyttede forbindelser mellem SQL3 og SQL1. Ovenfor har vi to indlejrede lister i routinglisten:

Liste 1:'SQL3', 'SQL1'

Liste 2:'SQL2'

Rut til replikaerne på den første liste. SQL3 og SQL1 er tilgængelige for skrivebeskyttede forbindelser. Den første indkommende skrivebeskyttede forbindelse vil blive dirigeret til SQL3, den anden skrivebeskyttede forbindelse vil blive dirigeret til SQL1, den tredje skrivebeskyttede forbindelse vil blive dirigeret til SQL3, den fjerde skrivebeskyttede forbindelse vil blive dirigeret til SQL1, og så videre, med en 'round-robin'-fordeling af skrivebeskyttede forbindelser mellem de to replikaer i den første liste.

Hvis nogen replikaer bliver utilgængelige, vil routing fortsætte med resterende replikaer på den første liste. Hvis SQL3 eller SQL1 bliver utilgængelige for skrivebeskyttede forbindelser, vil de skrivebeskyttede forbindelser kun blive dirigeret til de tilgængelige skrivebeskyttede replikaer på den første liste. For eksempel, hvis SQL3 er i en ikke-synkroniseret tilstand, eller ALLOW_CONNECTIONS er indstillet til NEJ, vil alle skrivebeskyttede forbindelser blive dirigeret til SQL1. Så længe en af serverne er tilgængelig for skrivebeskyttede forbindelser, vil INGEN skrivebeskyttede forbindelser blive dirigeret til SQL2.

Hvis alle replikaer på den første liste er utilgængelige, rute til replikaer på næste liste. Hvis SQL3 og SQL1 bliver utilgængelige for skrivebeskyttede forbindelser, vil alle skrivebeskyttede forbindelser kun blive dirigeret til den næste liste over replikaer, som i dette tilfælde er SQL2.

Genoptag omdirigering til den første liste, hvis nogen replikaer bliver tilgængelige. Efterhånden som sekundære replikaer, der har højere prioritet på listen, bliver tilgængelige for skrivebeskyttede forbindelser, vil fremtidige skrivebeskyttede forbindelser oprette forbindelse til dem efter behov.

I SQL Server 2016 kan du konfigurere belastningsbalancering på tværs af et sæt skrivebeskyttede replikaer.

Trin 5:

sys.availability_read_only_routing_lists DMV, der returnerer den skrivebeskyttede routingliste for hver tilgængelighedsgruppe-replik i Always On Availability-gruppen.

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 det følgende skærmbillede viser resultatet routing-URL og routing-prioritet.

Trin 6:

For at teste skrivebeskyttet routing ved hjælp af SQLCMD skal du bruge -K ReadOnly parameter, der viser sekundære replika-modtagende læseforbindelser i henhold til routinglisten.

I det følgende skærmbillede accepterer den sekundære replika læseforbindelserne, dvs.... SQL2.

Trin 7:

Failover tilgængelighedsgruppen og test skrivebeskyttet routing.

I Object Explorer skal du oprette forbindelse til en serverforekomst, der er vært for en sekundær replika af tilgængelighedsgruppen, der skal mislykkes. Udvid servertræet.
Udvid noden AlwaysOn High Availability og Availability Groups noden.
Højreklik på tilgængelighedsgruppen, der skal mislykkes, og vælg Failover.

Nu bliver SQL2 primær replika, og forbindelser håndteres af SQL1.

Den forbindelsesstrengsyntaks, som applikationen skal bruge, afhænger af SQL Server-udbyderen.

Hvis det er .Net Framework Data Provider 4.0.2 til SQL Server, vil syntaksen være som følger:

Server=tcp:MyAgListener,portnumber;Database=SQL1;IntegratedSecurity=SSPI;ApplicationIntent=ReadOnly;MultiSubnetFailover=True

Konklusion:

For at reducere arbejdsbyrden er denne skrivebeskyttede routing fortsat den bedste mulighed. En applikation, der involverer SQL Server Reporting Services, der hostes i SharePoint eller Native Mode-installationen af Report Server, kan bruge skrivebeskyttet hensigt, der undgår typisk blokering, hukommelse og CPU-brug på primære noder.