Pse commit-i juaj SQL sinkron pret udhëtimin vajtje-ardhje të VPN-së

Vonesa e shkrimit u hodh pasi një replikë u zhvendos në sitin e dytë, dhe tuneli është komponenti më i ri, prandaj ai merr fajin. Tuneli mund të jetë i pafajshëm: brenda një grupi disponueshmërie me commit sinkron, primarja nuk mund të konfirmojë një commit derisa të përfundojë një shkrim logu në distancë, kështu që çdo transaksion paguan një udhëtim vajtje-ardhje, sado megabitë që lidhja mund të mbajë. Xhiro mat bajt për sekondë, vonesa mat sa zgjat një shkëmbim, dhe një commit ka nevojë vetëm për një shkëmbim të vogël për të përfunduar. Një numër i vetëm e zgjidh debatin: kohëzgjatja e commit-it të një transaksioni të vogël, e matur brenda bazës së të dhënave të disponueshmërisë dhe më pas përsëri ndaj një tabele lokale në të njëjtën instancë.

Çfarë pret në të vërtetë primarja

Nën commit sinkron, primarja mban konfirmimin e commit-it derisa partneri të konfirmojë se regjistrimet e tij të logut janë të forcuara. I forcuar do të thotë i shkruar në mënyrë të qëndrueshme në login e transaksioneve të sekondares, jo i riekzekutuar në faqet e saj të të dhënave. Redo mund të mbetet pas me minuta pa i shtuar një milisekondë të vetme commit-it të primares.

Dokumentacioni i Microsoft për mënyrat e disponueshmërisë shpjegon atë shtrëngim duarsh dhe përshkruan çfarë bën platforma kur një partner del. Një replikë e shënuar si sinkrone është një rregull për pritjen, jo një premtim i përhershëm se ekziston një kopje e shëndetshme në distancë për çdo commit. Rruga e shkëputur përcaktohet veçmas, dhe nuk është thjesht fakti që commit-i dështon.

Prandaj pritja që shihni është një shumë: transporti i logut, planifikimi në të dy hostet dhe shkrimi në ruajtjen në distancë. Një sekondare me volum logu të ngopur shton kohë që asnjë test shpejtësie nuk do ta tregojë. Ai disk matet rrallë kur ankesa përmend VPN-në.

Gjerësia e brezit nuk është vonesë vajtje-ardhje

Një test shpejtësie e përmbyt rrugën për pak kohë dhe raporton një ritëm. Një commit kërkon diçka më të ngushtë: sa kohë i duhet një mesazhi të vogël për të arritur anën tjetër, për t'u ruajtur dhe për t'u kthyer. Gjatësia e rrugës, radhët dhe humbja e paketave e përcaktojnë atë numër, dhe asnjëra prej tyre nuk përmirësohet kur ofruesi ngre tavanin.

Prandaj një tunel «i shpejtë» mund të shtojë një dënim të dukshëm për një ngarkesë pune me shkrim të rëndë, e ndërtuar nga shumë transaksione të vogla radhazi. E njëjta sasi totale bajtësh e ndarë në një mijë commit-e paguan udhëtimin vajtje-ardhje një mijë herë; një transferim masiv e paguan atë një herë.

Kërkojini pronarit të rrjetit vonesën dhe humbjen të matura në vetë rrugën e replikës nën një ngarkesë përfaqësuese. Një ping nga një laptop zyre drejt portës VPN, ose një test shpejtësie drejt një nyje të afërt, pothuajse asgjë nuk i atribuon rrugës që logu ndjek në të vërtetë. Bëni që dritarja e matjes të përputhet me orët kur shkrimi është i ngadaltë.

Lexoni gjendjen e replikës përpara se të ndryshoni diçka

Filloni nga ajo që instancat raportojnë për veten e tyre, sepse të dy palët mund të mos bien dakord për sa e shëndetshme është partneriteti dhe një mesatare e panelit fsheh cila radhë po lëviz. Pyetësorët më poshtë përgjigjen pyetjeve të ndryshme: njëri lexon gjendjen e replikimit për çdo bazë të dhënash, tjetri lexon si është konfiguruar çdo replikë. Ekzekutoni të dy përpara se të prekni një mënyrë.

SELECT ag.name AS ag_name, drs.database_id, drs.synchronization_state_desc,
       drs.log_send_queue_size, drs.redo_queue_size, drs.secondary_lag_seconds
FROM sys.dm_hadr_database_replica_states AS drs
JOIN sys.availability_groups AS ag ON ag.group_id = drs.group_id;

SELECT ar.replica_server_name, ar.availability_mode_desc, ar.failover_mode_desc
FROM sys.availability_replicas AS ar;

Rezultati i parë ndan transportin e logut nga redo. log_send_queue_size që rritet ndërsa redo_queue_size qëndron i sheshtë do të thotë që logu nuk ka mbërritur; e kundërta do të thotë se ka mbërritur dhe se riprodhimi mbetet pas. Vetëm rasti i parë qëndron në rrugën e commit-it.

Rezultati i dytë konfirmon cilat replika janë vërtet të konfiguruara siç supozoni, sepse një mënyrë e ndryshuar gjatë një incidenti të mëparshëm priret të mbetet e ndryshuar dhe e padokumentuar. Lexoni rreshtin që ju intereson në vend të parazgjedhjes së grupit: availability_mode_desc dhe failover_mode_desc janë për çdo replikë. secondary_lag_seconds ekziston vetëm në SQL Server 2016 e më vonë, kështu që një ndërtim më i vjetër ju lë vetëm kolonat e radhës së dërgimit dhe të redo-s.

Më pas matni një shkrim përfaqësues në vend që të mbështeteni në një mesatare paneli. Ekzekutoni bllokun më poshtë në bazën e të dhënave të disponueshmërisë dhe më pas ekzekutoni përsëri ndaj të njëjtës formë tabele në një bazë të dhënash jashtë grupit në të njëjtën instancë. Diferenca midis dy kohëzgjatjeve është një çmim i përafërt për login në distancë, dhe në një debat me ekipin e rrjetit qëndron shumë më mirë se një grafik. Më pas ndryshoni një variabël në një herë, përndryshe diferenca nuk do të thotë më asgjë.

IF OBJECT_ID('dbo.CommitProbe') IS NULL
    CREATE TABLE dbo.CommitProbe (probe_id int PRIMARY KEY, touched_at datetime2(3));
IF NOT EXISTS (SELECT 1 FROM dbo.CommitProbe WHERE probe_id = 1)
    INSERT INTO dbo.CommitProbe (probe_id) VALUES (1);
SET STATISTICS TIME ON;
BEGIN TRANSACTION;
UPDATE dbo.CommitProbe SET touched_at = SYSUTCDATETIME() WHERE probe_id = 1;
COMMIT TRANSACTION;
SET STATISTICS TIME OFF;

Çfarë blen commit-i asinkron dhe sa kushton

Me commit asinkron, primarja ndalon së prituri konfirmimin e forcimit në distancë, kështu që udhëtimi vajtje-ardhje largohet nga rruga e commit-it. Vonesa e commit-it bie dhe sekondarja është e lirë të mbetet pas në një masë që askush nuk e kontrollon. Ky është një rregullim i vërtetë për pritjen dhe një ndryshim i vërtetë i premtimit.

Çmimi është një vendim për pikën e rikuperimit. Nëse primarja vdes përpara se logu i saj të arrijë një objektiv failover-i që ju vërtet mund ta përdorni, kalimi i shërbimit në kopjen asinkrone hedh poshtë transaksione që aplikacioni i kishte raportuar tashmë si të kryera. Asnjë dialog konfigurimi nuk e paraqet kështu, sepse është një pyetje biznesi për humbjen e pranueshme, jo një rregullim performance. Shkruani dritaren e humbjes së toleruar përpara incidentit, jo gjatë tij.

Bini dakord për mënyrën me pronarin e të dhënave, me shkrim, së bashku me procedurën e failover-it për rastin kur objektivi i preferuar nuk është i disponueshëm. Sinkron në një dokument projektimi nuk është manual operativ, dhe asinkron nuk është licencë për të ndaluar së vëzhguari radhët.

Zgjidhni një rregullim që mund ta mbroni më vonë

Ka katër opsione të ndershme. Prisni udhëtimet e commit-it vajtje-ardhje që mund të shmangen aty ku semantika e aplikacionit lejon grumbullimin; rregulloni një pengesë transporti ose ruajtjeje që e keni matur, gjë që mund të nënkuptojë një volum logu më të shpejtë në sekondare në vend të një tubi më të madh; afroni replikën që udhëtimi vajtje-ardhje të tkurret; ose lehtësoni politikën e mbrojtjes dhe pranoni një dritare humbjeje më të gjerë. Secili blen vonesë duke shpenzuar diçka tjetër, dhe i katërti shpenzon qëndrueshmërinë. Emërtoni shpenzimin përpara se të zgjidhni.

Vendosni me objektivin e vonesës së ngarkesës së punës dhe kërkesën e saj për qëndrueshmëri përpara jush në të njëjtën kohë, sepse optimizimi i njërës shpenzon në heshtje tjetrën. Më pas ekzekutoni përsëri të njëjtin transaksion që matët përpara ndryshimit. Një rregullim që nuk mund ta lëvizë atë numër është një hamendësim me një biletë ndryshimi.

Ruani leximet përpara dhe pas në regjistrin e ndryshimit. Përndryshe personi tjetër që sheh shkrime të ngadalta e përsërit hetimin nga fillimi dhe fillon përsëri duke fajësuar tunelin.