Зашто ваша синхрона SQL потврда чека путовање кроз VPN тамо и назад

Кашњење уписа је скочило након што је реплика премештена на другу локацију, а тунел је најновија компонента, па он прима кривицу. Тунел може бити невин: унутар групе доступности са синхроном потврдом примарна не може да потврди потврду док се не заврши удаљени упис у дневник, тако да свака трансакција плаћа путовање тамо и назад, колико год мегабита веза може да пренесе. Пропусност мери бајтове у секунди, кашњење мери колико траје једна размена, а потврди је потребна само једна мала размена да се заврши. Један број решава расправу: трајање потврде мале трансакције, измерено унутар базе доступности и затим поново према локалној табели на истој инстанци.

Шта примарна заправо чека

Под синхроном потврдом примарна задржава потврду док партнер не потврди да су његови записи у дневнику очврснути. Очврснуто значи трајно записано у дневник трансакција секундарне, а не поново извршено у њеним страницама података. Redo може да заостане минутима без додавања ни милисекунде потврди примарне.

Microsoft документација о режимима доступности објашњава то руковање и описује шта платформа ради када партнер испадне. Реплика означена као синхрона је правило о чекању, а не трајно обећање да за сваку потврду постоји здрава удаљена копија. Прекинута путања је дефинисана одвојено и није само то да потврда не успева.

Дакле, чекање које видите је збир: пренос дневника, распоређивање на оба хоста и упис у удаљено складиште. Секундарна са засићеним волуменом дневника додаје време које ниједан тест брзине неће показати. Тај диск се ретко мери када жалба помене VPN.

Пропусност није кашњење путовања тамо и назад

Тест брзине кратко преплави путању и пријави брзину. Потврда тражи нешто уже: колико времена малој поруци треба да стигне на другу страну, буде сачувана и врати се. Дужина путање, редови и губитак пакета одређују тај број, и ниједно од тога се не побољшава када провајдер подигне плафон.

Зато „брз“ тунел може да дода видљиву казну радном оптерећењу тешком на уписивању, састављеном од много малих узастопних трансакција. Исти укупан број бајтова подељен на хиљаду потврда плаћа путовање хиљаду пута; један групни пренос плаћа га једном.

Замолите власника мреже да измери кашњење и губитке на самој рути реплике под репрезентативним оптерећењем. Ping са канцеларијског лаптопа до VPN пролаза, или тест брзине до оближњег чвора, скоро ништа не приписује путањи којом дневник заиста путује. Нека се мерни прозор преклапа са сатима када је уписивање споро.

Прочитајте стање реплике пре него што било шта промените

Почните од онога што инстанце извештавају о себи, јер се две стране могу не сложити о томе колико је партнерство здраво и просек на контролној табли крије који се ред помера. Упити испод одговарају на различита питања: један чита стање репликације по бази, други чита како је свака реплика конфигурисана. Покрените оба пре него што додирнете режим.

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;

Први резултат одваја пренос дневника од redo-а. log_send_queue_size расте док redo_queue_size стоји равно значи да дневник није стигао; обрнуто значи да је стигао и да репродукција заостаје. Само први случај седи на путу потврде.

Други резултат потврђује које су реплике заиста конфигурисане како претпостављате, јер режим промењен током ранијег инцидента обично остаје промењен и недокументован. Читајте ред који вас занима уместо групне подразумеване вредности: availability_mode_desc и failover_mode_desc су по реплици. secondary_lag_seconds постоји само на SQL Server 2016 и новијем, па вам старија верзија оставља само колоне реда за слање и redo-а.

Затим измерите репрезентативан упис уместо да верујете просеку са контролне табле. Покрените блок испод у бази доступности, а затим га поново покрените према истом облику табеле у бази изван групе на истој инстанци. Разлика између два трајања је груба цена удаљеног дневника, и у расправи са мрежним тимом држи се много боље од графикона. Након тога мењајте по једну променљиву, иначе разлика престаје да значи било шта.

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;

Шта асинхрона потврда купује и колико кошта

Са асинхроном потврдом примарна престаје да чека потврду удаљеног очвршћавања, па путовање тамо и назад напушта пут потврде. Кашњење потврде пада и секундарна је слободна да заостане у мери коју нико не контролише. То је стварна поправка чекања и стварна промена обећања.

Цена је одлука о тачки опоравка. Ако примарна умре пре него што њен дневник стигне до циља пребацивања при отказу који заиста можете да користите, премештање услуге на асинхрону копију одбацује трансакције које је апликација већ пријавила као потврђене. Ниједан дијалог за конфигурацију то тако не представља, јер је то пословно питање о прихватљивом губитку, а не подешавање перформанси. Запишите толерисани прозор губитка пре инцидента, не током њега.

Договорите режим са власником података, писмено, заједно са процедуром пребацивања при отказу за случај када жељени циљ није доступан. Синхроно у пројектном документу није оперативно упутство, а асинхроно није лиценца да престанете да пратите редове.

Изаберите поправку коју ћете касније моћи да браните

Постоје четири честите опције. Одсеците избежљива путовања потврде тамо и назад тамо где семантика апликације дозвољава груписање; поправите измерено уско грло преноса или складиштења, што може да значи бржи волумен дневника на секундарној уместо веће цеви; приближите реплику да се путовање смањи; или олабавите заштитну политику и прихватите шири прозор губитка. Свака купује кашњење трошећи нешто друго, а четврта троши трајност. Назовите трошак пре него што изаберете.

Одлучујте са циљем кашњења радног оптерећења и његовим захтевом за трајност истовремено пред собом, јер оптимизација једног тихо троши друго. Затим поново покрените исту трансакцију коју сте измерили пре промене. Поправка која не може да помери тај број је претпоставка са билетом за промену.

Чувајте очитавања пре и после у запису промене. Иначе следећа особа која види споро уписивање понавља истрагу од почетка и поново почиње да криви тунел.