Miksi synkroninen SQL-vahvistuksesi odottaa VPN:n edestakaista matkaa

Kirjoituslatenssi hyppäsi, kun replika siirrettiin toiselle sivustolle, ja tunneli on uusin komponentti, joten se saa syyn niskoilleen. Tunneli voi olla syytön: synkronisen vahvistuksen käytettävyysryhmässä ensisijainen ei voi kuitata vahvistusta ennen kuin etälokin kirjoitus on valmis, joten jokainen transaktio maksaa edestakaisen matkan riippumatta siitä, kuinka monta megabittiä linkki kuljettaa. Läpäisykyky mittaa tavuja sekunnissa, latenssi mittaa, kuinka kauan yksi vaihto kestää, ja vahvistus tarvitsee vain yhden pienen vaihdon valmistuakseen. Yksi luku ratkaisee väittelyn: pienen transaktion vahvistuksen kesto mitattuna käytettävyystietokannan sisällä ja uudelleen saman instanssin paikallista taulua vastaan.

Mitä ensisijainen todella odottaa

Synkronisessa vahvistuksessa ensisijainen pitää vahvistuksen kuittauksen, kunnes kumppani vahvistaa, että sen lokitietueet on kovetettu. Kovetettu tarkoittaa pysyvästi toissijaisen transaktiolokiin kirjoitettua, ei sen datasivuille uudelleen ajettua. Redo voi jäädä minuutteja jälkeen lisäämättä millisekuntiakan ensisijaisen vahvistukseen.

Microsoftin dokumentaatio käytettävyystiloista käy läpi tuon kättelyn ja kuvaa, mitä alusta tekee, kun kumppani putoaa pois. Synkroniseksi merkitty replika on sääntö odottamisesta, ei pysyvä lupaus siitä, että jokaiselle vahvistukselle on terve etäkopio. Katkennut polku määritellään erikseen, eikä se ole yksinkertaisesti sitä, että vahvistus epäonnistuu.

Havaitsemasi odotus on siis summa: lokinsiirto, ajastus molemmilla isännillä ja etävaraston kirjoitus. Kyllästyneen lokimäärän toissijainen lisää aikaa, jota mikään nopeustesti ei näytä. Sitä levyä mitataan harvoin, kun valitus mainitsee VPN:n.

Kaistanleveys ei ole edestakaisen matkan viive

Nopeustesti tulvii polun hetkeksi ja ilmoittaa nopeuden. Vahvistus kysyy kapeampaa asiaa: kuinka kauan pienen viestin kestää saavuttaa toinen puoli, tallentua ja palata. Polun pituus, jonotus ja pakettihäviö määräävät tämän luvun, eikä mikään niistä parane, kun palveluntarjoaja nostaa katon.

Siksi «nopea» tunneli voi lisätä näkyvän rangaistuksen kirjoitusraskaille työkuormalle, joka on rakennettu monista pienistä peräkkäisistä transaktioista. Sama tavumäärä tuhanteen vahvistukseen jaettuna maksaa edestakaisen matkan tuhat kertaa; yksi massasiirto maksaa sen kerran.

Pyydä verkon omistajaa mittaamaan viive ja häviö replikan reitillä itsellään edustavalla kuormalla. Ping toimistokannettavasta VPN-portille tai nopeustesti läheiseen solmuun ei kohdista juuri mitään reitille, jota loki tosiasiassa kulkee. Varmista, että mittausikkuna osuu yhteen niiden tuntien kanssa, jolloin kirjoitus on hidasta.

Lue replikan tila ennen kuin muutat mitään

Aloita siitä, mitä instanssit kertovat itsestään, koska kaksi puolta voivat olla eri mieltä siitä, kuinka terve kumppanuus on, ja koontinäytön keskiarvo piilottaa, mikä jono liikkuu. Alla olevat kyselyt vastaavat eri kysymyksiin: toinen lukee replikaation tilan tietokannoittain, toinen lukee, miten kukin replika on määritetty. Suorita molemmat ennen kuin kosket tilaan.

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;

Ensimmäinen tulos erottaa lokinsiirron redosta. log_send_queue_size kasvaa, kun redo_queue_size pysyy tasaisena, tarkoittaa, ettei loki ole saapunut; päinvastainen tarkoittaa, että se saapui ja toisto laahaa perässä. Vain ensimmäinen tapaus istuu vahvistuksen polulla.

Toinen tulos vahvistaa, mitkä replikat on todella määritetty niin kuin oletat, koska aiemman tapauksen aikana muutettu tila jää usein muutetuksi ja dokumentoimattomaksi. Lue rivi, joka sinua kiinnostaa, ryhmän oletusarvon sijaan: availability_mode_desc ja failover_mode_desc ovat replikakohtaisia. secondary_lag_seconds on vain SQL Server 2016:ssa ja uudemmissa, joten vanhempi versio jättää sinulle vain lähetysjonon ja redon sarakkeet.

Mittaa sitten edustava kirjoitus sen sijaan, että luottaisit koontinäytön keskiarvoon. Suorita alla oleva lohko käytettävyystietokannassa ja suorita se sitten uudelleen samaa taulumuotoa vastaan tietokannassa ryhmän ulkopuolella samassa instanssissa. Kahden keston välinen ero on karkea hinta etälokista, ja se pitää väittelyssä verkkotiimin kanssa paljon paremmin kuin kuvaaja. Muuta sen jälkeen yhtä muuttujaa kerrallaan, muuten ero lakkaa tarkoittamasta mitään.

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;

Mitä asynkroninen vahvistus ostaa ja mitä se maksaa

Asynkronisella vahvistuksella ensisijainen lopettaa etäkovetuksen vahvistuksen odottamisen, joten edestakainen matka poistuu vahvistuksen polulta. Vahvistuksen latenssi laskee ja toissijainen saa vapaasti jäädä jälkeen määrän, jota kukaan ei hallitse. Se on todellinen korjaus odotukseen ja todellinen muutos lupaukseen.

Hinta on palautumispistettä koskeva päätös. Jos ensisijainen kuolee ennen kuin sen loki saavuttaa failover-kohteen, jota todella voit käyttää, palvelun siirtäminen asynkroniselle kopiolle hylkää transaktiot, jotka sovellus on jo ilmoittanut vahvistetuiksi. Mikään asetusten valintaikkuna ei esitä sitä niin, koska se on liiketoimintakysymys hyväksyttävästä menetyksestä, ei suorituskykyasetus. Kirjoita siedetty menetysikkuna ylös ennen tapausta, ei sen aikana.

Sovi tila datan omistajan kanssa kirjallisesti yhdessä failover-menettelyn kanssa siltä varalta, että ensisijainen kohde ei ole käytettävissä. Synkroninen suunnitteludokumentissa ei ole operatiivinen käsikirja, eikä asynkroninen ole lisenssi lopettaa jonojen seuraaminen.

Valitse korjaus, jonka voit puolustaa jälkeenpäin

Tarjolla on neljä rehellistä vaihtoehtoa. Leikkaa pois vältettävissä olevat vahvistuksen edestakaiset matkat siellä, missä sovelluksen semantiikka sallii eräajon; korjaa mitattu siirron tai tallennuksen pullonkaula, mikä voi tarkoittaa nopeampaa lokimäärää toissijaisella suuremman putken sijaan; siirrä replika lähemmäs, jotta edestakainen matka pienenee; tai löysää suojauskäytäntöä ja hyväksy leveämpi menetysikkuna. Jokainen ostaa latenssia kuluttamalla jotain muuta, ja neljäs kuluttaa kestävyyttä. Nimeä kulutus ennen kuin valitset.

Päätä, kun työkuorman latenssitavoite ja kestävyysvaatimus ovat samanaikaisesti edessäsi, koska toisen optimointi kuluttaa hiljaa toista. Suorita sitten uudelleen sama transaktio, jonka mittasit ennen muutosta. Korjaus, joka ei pysty liikuttamaan tuota lukua, on muutospyynnön kantama arvaus.

Säilytä ennen ja jälkeen -lukemat muutoskirjauksessa. Muuten seuraava henkilö, joka näkee hitaita kirjoituksia, toistaa tutkinnan alusta ja aloittaa taas tunnelin syyttämisestä.