Wêrom jo synchrone SQL-fêstlizzing op de VPN-rûnreis wachtet

De skriuwlatinsje sprong omheech nei't in replika nei it twadde plak ferhuze, en de tunnel is it nijste ûnderdiel, dus hy krijt de skuld. De tunnel kin ûnskuldich wêze: binnen in beskikberensgroep mei synchrone fêstlizzing kin it primêre net in fêstlizzing befêstigje foardat in ôfstâns logskriuwing klear is, dus elke transaksje betellet in rûnreis, hoefolle megabit de ferbining ek drage kin. Trochsat mjit bytes per sekonde, latinsje mjit hoe lang ien útwikseling duorret, en in fêstlizzing hat mar ien lyts útwikseling nedich om klear te wêzen. Ien getal beslist it skeel: de doer fan 'e fêstlizzing fan in lytse transaksje, metten yn 'e beskikberensdatabank en dêrnei wer tsjin in pleatslike tabel op deselde ynstânsje.

Wêr't it primêre echt op wachtet

Under synchrone fêstlizzing hâldt it primêre de fêstlizzingsbefêstiging tsjin oant de partner befêstiget dat syn logrecords ferhurde binne. Ferhurde betsjut duorsum skreaun yn it transaksjelog fan 'e sekundêre, net opnij útfierd yn syn gegevenssiden. Redo kin minuten efterbliuwe sûnder ien millisekunde oan 'e fêstlizzing fan it primêre ta te foegjen.

Microsoft har dokumintaasje oer de beskikberensmodi leit dy hânskud út en beskriuwt wat it platfoarm docht as in partner fuortfalt. In replika dy't as synchroan markearre is, is in regel oer wachtsjen, gjin steande belofte dat der foar elke fêstlizzing in sûne ôfstâns kopy bestiet. It ôfbrutsen paad wurdt apart definiearre, en it is net gewoan dat de fêstlizzing mislearret.

Dat it wachtsjen dat jo sjogge is in som: logferfier, planning op beide hosts en de skriuwing nei de ôfstâns opslach. In sekundêre mei in fersêde logfolume foeget tiid ta dy't gjin snelheidstest sjen litte sil. Dy skiif wurdt selden metten as de klacht de VPN neamt.

Bânbreedte is gjin fertraging fan in rûnreis

In snelheidstest oerstreamt it paad koart en rapportearret in taryf. In fêstlizzing freget wat smeller: hoe lang in lyts berjocht der oer docht om de oare kant te berikken, bewarre te wurden en werom te kommen. Paadlingte, wachtrigen en pakketferlies bepale dat getal, en gjin fan dy ferbetteret as de leveransier it plafond ferheget.

In «flugge» tunnel kin dus in sichtbere boete tafoegje oan in skriuwswiere wurklast dy't boud is út in protte lytse opienfolgjende transaksjes. Itselde byte-totaal oer tûzen fêstlizzings ferdield betellet de rûnreis tûzen kear; ien bulkoerdracht betellet dy ien kear.

Freegje de netwurkeigner om fertraging en ferlies metten oer de replikarûte sels ûnder represintative lading. In ping fan in kantoarlaptop nei de VPN-poarte, of in snelheidstest nei in tichtby lizzend knooppunt, skriuwt hast neat ta oan it paad dat it log echt reizget. Soargje dat it mjitfinster oerlaapet mei de oeren wêryn't skriuwen stadich is.

Lês de tastân fan 'e replika foardat jo wat feroarje

Begjin mei wat de ynstânsjes oer harsels rapportearje, want de beide kanten kinne it net iens wêze oer hoe sûn it partnerskip is en in dashboardgemiddelde ferberget hokker wachtrige beweecht. De queries hjirûnder beantwurdzje ferskillende fragen: ien lêst de replikaasjetastân per databank, de oare lêst hoe't elke replika konfigurearre is. Rin beide foardat jo in modus oanreitsje.

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;

It earste resultaat skiedt logferfier fan redo. log_send_queue_size dat klimt wylst redo_queue_size flak bliuwt, betsjut dat it log net oankommen is; it tsjinoerstelde betsjut dat it oankommen is en dat it ôfspyljen efterbliuwt. Allinnich it earste gefal sit op it fêstlizzingspaad.

It twadde resultaat befêstiget hokker replika's echt konfigurearre binne sa't jo oannimme, want in modus dy't by in earder ynsidint feroare is, bliuwt meastentiids feroare en ûndokumintearre. Lês de rige dy't jo oanbelanget ynstee fan it standert fan 'e groep: availability_mode_desc en failover_mode_desc binne per replika. secondary_lag_seconds bestiet allinnich op SQL Server 2016 en letter, dus in âldere build lit jo allinnich de kolommen foar stjoerwachtrige en redo.

Mjit dan in represintative skriuwing ynstee fan in dashboardgemiddelde te fertrouwen. Rin it blok hjirûnder yn 'e beskikberensdatabank, en rin it dan wer tsjin deselde taffoarm yn in databank bûten de groep op deselde ynstânsje. It gat tusken de beide doeren is in rûge priis foar it ôfstâns log, en it hâldt yn in diskusje mei it netwurkteam folle better stân as in grafyk. Feroarje dêrnei ien fariabele tagelyk, oars betsjut it gat neat mear.

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;

Wat asynchrone fêstlizzing keapet, en wat it kostet

Mei asynchrone fêstlizzing hâldt it primêre op mei wachtsjen op 'e befêstiging fan 'e ôfstâns ferhurding, dus de rûnreis ferlit it fêstlizzingspaad. De fêstlizzingslatinsje sakket en de sekundêre is frij om efter te bliuwen yn in mjitte dy't nimmen kontrolearret. Dat is in echte oplossing foar it wachtsjen en in echte feroaring oan 'e belofte.

De priis is in beslút oer it werstelspunt. As it primêre stjert foardat syn log in failover-doel berikt dat jo echt brûke kinne, smyt it ferpleatsen fan 'e tsjinst nei de asynchrone kopy transaksjes fuort dy't de applikaasje al as fêstlein rapportearre hie. Gjin konfiguraasjedialooch stelt it sa foar, want it is in saaklike fraach oer akseptabel ferlies, gjin prestaasje-ynstelling. Skriuw it tolerearre ferliesfinster op foar it ynsidint, net ûnder it ynsidint.

Spreek de modus ôf mei wa't de gegevens besit, skriftlik, tegearre mei de failover-proseduere foar it gefal dat it foarkarre doel net beskikber is. Synchroan yn in ûntwerpdocument is gjin operasjonele hânlieding, en asynchroan is gjin lisinsje om op te hâlden mei it folgjen fan 'e wachtrigen.

Kies in oplossing dy't jo letter ferdigenje kinne

Der binne fjouwer earlike opsjes. Snij foarkombare fêstlizzingsrûnreizen fuort wêr't de semantyk fan 'e applikaasje bondeljen tastean; reparearje in metten ferfier- of opslachknelpunt, wat in flugger logfolume op 'e sekundêre betsjutte kin ynstee fan in gruttere piip; ferpleats de replika tichterby sadat de rûnreis krimpt; of fersoepelje it beskermingsbelied en akseptearje in breder ferliesfinster. Elk keapet latinsje troch wat oars út te jaan, en de fjirde jout duorsumheid út. Neam de útjefte foardat jo kieze.

Beslis mei it latinsjedoel fan 'e wurklast en syn duorsumheidsfoarsis byinoar foar jo, want it iene optimalisearje jout stilwei it oare út. Rin dêrnei deselde transaksje wer dy't jo foar de feroaring metten hawwe. In oplossing dy't dat getal net bewege kin, is in gissing mei in feroaringskaartsje oan.

Hâld de foar- en nei-lêzingen yn it feroaringsrecord. Oars werhellet de folgjende persoan dy't stadich skriuwen sjocht, it ûndersyk fan it begjin ôf en begjint wer de tunnel de skuld te jaan.