Зошто брз VPN се уште го забавува синхроното SQL потврдување

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

Започнете од типот на чекање на примарниот

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

Подредете го работното оптоварување по честота на потврдувања пред да заклучите нешто за врската.

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

Следете го потврдувањето до секундарниот

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

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

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;

Направете таков снимок пред и по репрезентативно запишување, а не еднаш во тивко попладне. Разликата е она што ви кажува кој ред се поместил додека потврдувањето чекало.

Мерете ја патеката, а не врската

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

Задржете ја безбедноста на транспортот на базата и контролата на пристап недопрени додека мерите. Мерењето на патека никогаш не е причина да ги заобиколите.

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

Што навистина менува асинхрониот режим

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

Ако примарниот се загуби пред дневникот да стигне до употреблива цел за префрлање, присилното преместување на услугата на таа реплика ги фрла трансакциите за кои на апликацијата веќе ѝ било кажано дека се потврдени.

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