Wêrom in flugge VPN noch altyd in syngroane SQL-fêstiging fertraget

Iepenje in query-sesje op de primêre en sjoch wêr't in ienfâldige skriuwerij op wachtet. At de database by in beskikberensgroep mei syngroane fêstiging heart en de sekundêre is ferbûn, ferlit in part fan dy wachttiid it gebou: logrecords reizgje nei de replika, wurde dêr hurde, en it berjocht oer dy hurding komt werom foardat de fêstiging klear is. Bânbreedte ferkoartet dy reis hinne en wer net. De rûnlieding hjirûnder folget de befêstiging fan it skerm nei de fiere skiif en werom.

Begjin by it wachttype op 'e primêre

In skriuwerij dy't op 'e fiere replika wachtet, ferskynt as in log-relatearre wachttiid ynstee fan in CPU- of slotwachttiid, en de doer fan 'e transaksje folget de reis hinne en wer ynstee fan it oantal rigen. In protte lytse fêstigings meitsje dat dúdlik, om't elk de reis apart betellet. Ien bulksbewurking ferberget deselde kosten yn ien langere befêstiging.

Sortearje jo wurklêst op fêstigingsfrekwinsje foardat jo eat oer de ferbining konkludearje.

Lês de tastân fan 'e replika foardat jo it netwurk lêze. De tellers dy't ta saak dogge, binne de stjoerwachtrige, de redo-wachtrige en de syngronisaasjetastân, en tegearre litte se sjen oft de sekundêre byhâldt of efterrekket. In groeiende stjoerwachtrige wiist op ferfier, wylst in groeiende redo-wachtrige op it eigen wurk of de opslach fan 'e sekundêre wiist. Dat binne ferskate reparaasjes, en net ien ferbetteret troch bânbreedte ta te foegjen.

Folgje de befêstiging nei de sekundêre

By syngroane fêstiging wachtet de primêre op befêstiging dat it oangeande log op 'e sekundêre hurde is foardat er de fêstiging as dien rapportearret. Hurde betsjut duorjend yn it log, net weromspele yn gegevenssiden. Krekt dat ferskil is de reden wêrom't in syngroane sekundêre efterrinne kin op redo wylst er de hurding noch befêstiget.

Rin it paad yn folchoarder en mjit elke stap ynstee fan it gehiel. Logrecords geane oer it ferfier, de sekundêre skriuwt en spielt se, en de befêstiging komt werom oer itselde paad. Fertraging fan ferfier, planning fan 'e sekundêre en latency fan 'e logskiif fan 'e sekundêre komme allegear yn it totaal, en allinnich it earste heart by de netwurk-eigner. In sekundêre waans logfolume troch eat oars fersêde is, kin elke fêstiging útlûke wylst de ferbining stil stiet.

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;

Nim dy momintopname foar en nei in represintative skriuwerij ynstee fan ien kear op in stille middei. It ferskil is wat jo fertelt hokker rige beweegde wylst de fêstiging wachte.

Mjit it paad, net de ferbining

In trochfiertest mjit kapasiteit tusken twa punten dy't jo replika's net binne, ûnder in lêst dy't jo wurk net is. Freegje de netwurk-eigner om fertraging en ferlies lâns it echte replikapaad wylst echte ferkear rint, yn beide rjochtingen. Ferlies weaget hjir swierder as kapasiteit, om't in ferlern segmint in werstjoering kostet en elke fêstiging op ien befêstiging wachtet. In ferbining dy't der poerbêst út sjocht yn in downloadtest kin noch altyd min passe by in praatsk fêstigingspatroan.

Hâld de transportbefeiliging en tagongsregels fan 'e database yntakt wylst jo mjit. It mjitten fan in paad is nea in reden om se te omgean.

Korrelearje de tiden mei de tellers ynstee fan mei yntuysje. At de stjoerwachtrige leech bliuwt en de fêstiging wachtet noch, sit de fertraging yn 'e befêstiging of yn it spielen fan 'e sekundêre. At de stjoerwachtrige stadich groeit, is ferfier of kapasiteit de beheining. Skriuw op hokker observaasje de konklúzje stipe, sadat de folgjende persoan de mjitting werhelje kin ynstee fan 'e diskusje.

Wat asyngroane modus echt feroaret

Asyngroane fêstiging hellet it wachtsjen op 'e hurdingsbefêstiging fan 'e sekundêre wei, dêrom wurde skriuwerijen flugger en dêrom feroaret jo duorsumensposysje. De primêre befêstiget de transaksje sûnder dy fiere befêstiging. Dan mei de sekundêre efterrinne, en dat efterrinne is de bleatstelling.

At de primêre ferlern giet foardat it log in brûkber oerskeakeldoel berikt, smyt it twingend ferpleatsen fan 'e tsjinst nei dy replika transaksjes fuort dy't de applikaasje al as fêstige meidield wie.

Dat is in beslút oer it werstelpunts en it heart by de database-eigner, net by in prestaasje-oersjoch. Set earst it tastiene finster foar gegevensferlies, kies de modus dy't dêrby past, en optimalisearje dan binnen dy grins. Opsjes dy't syngroane beskerming hâlde, binne ûnder oare it fuortheljen fan te foarkommen fêstigingsreizen dêr't de applikaasje it tastiet, it reparearjen fan in metten kearpunt yn ferfier of opslach, en it ferpleatsen fan 'e replika sadat de befêstiging minder ôfstân reizget. Weagje se tsjin 'e duorsumenseask dy't jo begûn binne, dy't net feroare is.