Pse një VPN i shpejtë ende ngadalëson një konfirmim sinkron SQL

Hapni një sesion pyetjeje në primar dhe shikoni çfarë pret një shkrim i thjeshtë. Nëse baza e të dhënave i përket një grupi disponueshmërie me konfirmim sinkron dhe sekondari është i lidhur, një pjesë e asaj pritjeje del nga ndërtesa: regjistrimet e logut udhëtojnë drejt replikës, forcohen atje, dhe lajmi i atij forcimi kthehet para se konfirmimi të përfundojë. Gjerësia e brezit nuk e shkurton atë udhëtim vajtje-ardhje. Udhëzimi më poshtë ndjek konfirmimin nga ekrani në diskun e largët dhe kthimin.

Filloni nga lloji i pritjes në primar

Një shkrim që pret në replikën e largët shfaqet si pritje e lidhur me logun, jo si pritje procesori ose bllokimi, dhe kohëzgjatja e transaksionit ndjek udhëtimin vajtje-ardhje në vend të numrit të rreshtave. Shumë konfirmime të vogla e bëjnë të qartë, sepse secili e paguan udhëtimin veçmas. Një operacion i vetëm masiv e fsheh të njëjtin kosto brenda një konfirmimi më të gjatë.

Renditni ngarkesën e punës sipas shpeshtësisë së konfirmimeve përpara se të nxirrni ndonjë përfundim për lidhjen.

Lexoni gjendjen e replikës përpara se të lexoni rrjetin. Numëruesit që kanë rëndësi janë radha e dërgimit, radha redo dhe gjendja e sinkronizimit, dhe së bashku tregojnë nëse sekondari po mbahet ose po mbetet prapa. Një radhë dërgimi në rritje tregon transportin, ndërsa një radhë redo në rritje tregon punën ose ruajtjen e vetë sekondarit. Këto janë riparime të ndryshme dhe asnjëra nuk përmirësohet duke shtuar gjerësi brezi.

Ndigni konfirmimin deri te sekondari

Me konfirmim sinkron, primari pret konfirmimin që logu përkatës është forcuar në sekondar përpara se ta raportojë konfirmimin si të përfunduar. Forcuar do të thotë i qëndrueshëm në log, jo i riprodhuar në faqet e të dhënave. Pikërisht ky dallim shpjegon pse një sekondar sinkron mund të mbetet prapa në redo ndërsa vazhdon të konfirmojë forcimin.

Kaloni shtegun me radhë dhe matni çdo fazë në vend të tërësisë. Regjistrimet e logut kalojnë përmes transportit, sekondari i shkruan dhe i shkarkon, dhe konfirmimi kthehet në të njëjtin shteg. Vonesa e transportit, planifikimi i sekondarit dhe latenca e diskut të logut të sekondarit hyjnë të gjitha në total, dhe vetëm e para i përket pronarit të rrjetit. Një sekondar, volumi i logut të të cilit është ngopur nga diçka tjetër, mund të zgjasë çdo konfirmim ndërsa lidhja rri boshe.

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

Merrni atë pamje para dhe pas një shkrimi përfaqësues, jo një herë në një pasdite të qetë. Diferenca është ajo që ju tregon cila radhë lëvizi ndërsa konfirmimi priste.

Matni shtegun, jo lidhjen

Një test xhiroje mat kapacitetin midis dy pikave që nuk janë replikat tuaja, nën një ngarkesë që nuk është puna juaj. Kërkojini pronarit të rrjetit vonesën dhe humbjen përgjatë shtegut real të replikës ndërsa qarkullon trafik real, në të dy drejtimet. Humbja këtu ka më shumë rëndësi se kapaciteti, sepse një segment i humbur kushton një ritransmetim dhe çdo konfirmim pret një konfirmim. Një lidhje që duket e shkëlqyer në një test shkarkimi mund të jetë ende e papërshtatshme për një model konfirmimesh llafazan.

Mbani të paprekura sigurinë e transportit të bazës së të dhënave dhe kontrollet e aksesit gjatë matjes. Matja e një shtegu nuk është kurrë arsye për t'i anashkaluar ato.

Ndërlidhni kohët me numëruesit në vend të intuitës. Nëse radha e dërgimit mbetet bosh dhe konfirmimi ende pret, vonesa është në konfirmim ose në shkarkimin e sekondarit. Nëse radha e dërgimit rritet vazhdimisht, kufizimi është transporti ose kapaciteti. Shënoni cili vëzhgim e mbështeti përfundimin, që personi tjetër të mund të përsërisë matjen dhe jo debatin.

Çfarë ndryshon vërtet mënyra asinkrone

Konfirmimi asinkron heq pritjen për konfirmimin e forcimit nga sekondari, prandaj shkrimet bëhen më të shpejta dhe prandaj ndryshon pozicioni juaj i qëndrueshmërisë. Primari e konfirmon transaksionin pa atë konfirmim të largët. Sekondarit pastaj i lejohet të mbetet prapa, dhe ajo mbetje është ekspozimi.

Nëse primari humbet përpara se logu të arrijë një objektiv të përdorshëm të kalimit të defektit, detyrimi i shërbimit në atë replikë hedh poshtë transaksione për të cilat aplikacionit i ishte thënë tashmë se ishin konfirmuar.

Ky është një vendim për pikën e rikuperimit dhe i përket pronarit të bazës së të dhënave, jo një rishikimi performance. Së pari caktoni dritaren e toleruar të humbjes së të dhënave, zgjidhni mënyrën që e plotëson, më pas optimizoni brenda asaj kufiri. Opsionet që ruajnë mbrojtjen sinkrone përfshijnë heqjen e udhëtimeve të konfirmimit të shmangshme aty ku aplikacioni e lejon, rregullimin e një pengese të matur transporti ose ruajtjeje, dhe zhvendosjen e replikës që konfirmimi të përshkojë më pak distancë. Peshojini ato kundrejt kërkesës për qëndrueshmëri me të cilën filluat dhe që nuk ka ndryshuar.