Miksi nopea VPN hidastaa silti synkronista SQL-vahvistusta

Avaa kyselyistunto ensisijaisella ja katso, mitä yksinkertainen kirjoitus odottaa. Jos tietokanta kuuluu synkronisen vahvistuksen saatavuusryhmään ja toissijainen on yhteydessä, osa odotuksesta lähtee rakennuksesta: lokitietueet matkaavat replikalle, kovetetaan siellä, ja tieto kovetuksesta palaa ennen kuin vahvistus päättyy. Kaistanleveys ei lyhennä tätä edestakaista matkaa. Alla oleva katsaus seuraa kuittausta näytöltä etälevylle ja takaisin.

Aloita ensisijaisen odotustyypistä

Etäreplikalla odottava kirjoitus näkyy lokiin liittyvänä odotuksena eikä suorittimen tai lukon odotuksena, ja transaktion kesto seuraa edestakaista matkaa rivimäärän sijaan. Monet pienet vahvistukset tekevät sen ilmeiseksi, koska jokainen maksaa matkan erikseen. Yksi massatoiminto kätkee saman kustannuksen yhteen pidempään kuittaukseen.

Lajittele työkuorma vahvistustiheyden mukaan ennen kuin päättelet mitään yhteydestä.

Lue replikan tila ennen kuin luet verkkoa. Tärkeät laskurit ovat lähetysjono, redo-jono ja synkronointitila, ja yhdessä ne näyttävät, pysyykö toissijainen tahdissa vai jääkö jälkeen. Kasvava lähetysjono viittaa siirtoon, kun taas kasvava redo-jono viittaa toissijaisen omaan työhön tai tallennukseen. Ne ovat eri korjauksia, eikä kumpikaan parane kaistanleveyttä lisäämällä.

Seuraa kuittaus toissijaiselle

Synkronisessa vahvistuksessa ensisijainen odottaa vahvistusta siitä, että kyseinen loki on kovetettu toissijaisella, ennen kuin se ilmoittaa vahvistuksen valmiiksi. Kovetettu tarkoittaa pysyvää lokissa, ei tietosivuille toistettua. Juuri tämä ero selittää, miksi synkroninen toissijainen voi jäädä jälkeen redossa ja silti vahvistaa kovetuksen.

Käy polku järjestyksessä ja mittaa jokainen vaihe kokonaisuuden sijaan. Lokitietueet kulkevat siirron yli, toissijainen kirjoittaa ja huuhtelee ne, ja kuittaus palaa samaa polkua. Siirron viive, toissijaisen ajoitus ja toissijaisen lokilevyn latenssi päätyvät kaikki summaan, ja vain ensimmäinen kuuluu verkon omistajalle. Toissijainen, jonka lokimäärä on kyllästetty jollain muulla, voi venyttää jokaisen vahvistuksen, kun yhteys seisoo käyttämättömänä.

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;

Ota tuo tilannekuva ennen edustavaa kirjoitusta ja sen jälkeen, älä kerran rauhallisena iltapäivänä. Ero kertoo, mikä jono liikkui vahvistuksen odottaessa.

Mittaa polkua, älä yhteyttä

Läpäisytestissä mitataan kapasiteettia kahden pisteen välillä, jotka eivät ole replikojasi, kuormalla, joka ei ole työkuormasi. Pyydä verkon omistajalta viivettä ja häviötä todellisella replikan polulla, kun todellinen liikenne kulkee, molempiin suuntiin. Häviö painaa täällä enemmän kuin kapasiteetti, koska kadonnut segmentti maksaa uudelleenlähetyksen ja jokainen vahvistus odottaa yhtä kuittausta. Yhteys, joka näyttää lataustestissä erinomaiselta, voi silti sopia huonosti puheliaalle vahvistuskuviolle.

Pidä tietokannan siirtoturvallisuus ja käyttöoikeusvalvonta ehjinä mittaamisen aikana. Polun mittaaminen ei ole koskaan syy ohittaa niitä.

Korreloi ajat laskureihin intuition sijaan. Jos lähetysjono pysyy tyhjänä ja vahvistus odottaa yhä, viive on kuittauksessa tai toissijaisen huuhtelussa. Jos lähetysjono kasvaa jatkuvasti, rajoite on siirto tai kapasiteetti. Kirjaa, mikä havainto tuki johtopäätöstä, jotta seuraava henkilö voi toistaa mittauksen eikä väittelyä.

Mitä asynkroninen tila todella muuttaa

Asynkroninen vahvistus poistaa odotuksen toissijaisen kovetuskuittaukselle, minkä vuoksi kirjoitukset nopeutuvat ja minkä vuoksi kestävyysasemasi muuttuu. Ensisijainen vahvistaa transaktion ilman sitä etäkuittausta. Toissijaisen annetaan sitten jäädä jälkeen, ja se jälkeen jääminen on altistus.

Jos ensisijainen menetetään ennen kuin loki saavuttaa käyttökelpoisen vikasietotavoitteen, palvelun pakottaminen tuolle replikalle hylkää transaktiot, jotka sovellukselle oli jo ilmoitettu vahvistetuiksi.

Se on palautumispistepäätös ja kuuluu tietokannan omistajalle, ei suorituskykykatsaukselle. Aseta ensin siedetty tietohäviön ikkuna, valitse tila, joka täyttää sen, ja optimoi sitten sen rajan sisällä. Synkronisen suojauksen säilyttäviin vaihtoehtoihin kuuluvat vältettävissä olevien vahvistusmatkojen poistaminen siellä, missä sovellus sen sallii, mitatun siirto- tai tallennuspullonkaulan korjaaminen ja replikan siirtäminen niin, että kuittaus kulkee lyhyemmän matkan. Punnitse niitä kestävyysvaatimuksen kanssa, jolla aloitit ja joka ei ole muuttunut.