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

Латентноста на запишување скокна откако репликата се премести на втората локација, а тунелот е најновата компонента, па тој ја добива вината. Тунелот може да е невин: во група за достапност со синхрон commit примарната не може да потврди commit додека не заврши далечинското запишување на дневникот, па секоја трансакција плаќа повратно патување, колку и мегабити да може да пренесе врската. Пропусноста мери бајти во секунда, латентноста мери колку трае една размена, а commit бара само една мала размена за да заврши. Еден број ја решава расправата: времетраењето на commit на мала трансакција, измерено во базата за достапност и потоа повторно наспроти локална табела на истиот пример.

Што всушност чека примарната

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

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

Значи чекањето што го гледате е збир: пренос на дневник, распоредување на двата домаќини и запишување во далечинското складиште. Секундарна со заситен волумен на дневник додава време што ниту еден тест за брзина нема да го покаже. Тој диск ретко се мери кога жалбата го именува VPN.

Пропусноста не е доцнење на повратно патување

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

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

Побарајте од сопственикот на мрежата да измери доцнење и загуби на самата рута на репликата под репрезентативно оптоварување. 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 стои рамно значи дека дневникот не пристигнал; обратното значи дека пристигнал и дека репродукцијата заостанува. Само првиот случај седи на патот на commit.

Вториот резултат потврдува кои реплики се навистина конфигурирани како што претпоставувате, бидејќи режим сменет за време на претходен инцидент обично останува сменет и недокументиран. Читајте го редот што ве интересира наместо стандардната вредност на групата: 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;

Што купува асинхрон commit и колку чини

Со асинхрон commit примарната престанува да чека потврда за далечинското зацврстување, па повратното патување излегува од патот на commit. Латентноста на commit паѓа и секундарната е слободна да заостане колку што никој не контролира. Тоа е вистинска поправка за чекањето и вистинска промена на ветувањето.

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

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

Изберете поправка што подоцна ќе можете да ја одбраните

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

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

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