Bakit hinihintay ng iyong synchronous SQL commit ang paglalakbay pabalik-balik sa VPN

Tumalon ang latency ng pagsulat matapos ilipat ang isang replica sa ikalawang site, at ang tunnel ang pinakabagong bahagi, kaya ito ang sinisisi. Maaaring inosente ang tunnel: sa loob ng isang grupo ng pagkakaroon na may synchronous commit, hindi makumpirma ng pangunahin ang isang commit hanggang matapos ang isang malayong pagsulat ng log, kaya bawat transaksyon ay nagbabayad ng paglalakbay pabalik-balik gaano man karaming megabit ang kayang dalhin ng link. Sinusukat ng throughput ang bytes kada segundo, sinusukat ng latency kung gaano katagal ang isang palitan, at ang commit ay nangangailangan lamang ng isang maliit na palitan upang matapos. Isang numero lang ang magtatapos ng debate: ang tagal ng commit ng isang maliit na transaksyon, sinusukat sa loob ng database ng pagkakaroon at muli laban sa isang lokal na talahanayan sa parehong instance.

Ano ba talaga ang hinihintay ng pangunahin

Sa synchronous commit, pinipigilan ng pangunahin ang pagkilala sa commit hanggang kumpirmahin ng partner na ang mga tala ng log nito ay pinatigas. Ang pinatigas ay nangangahulugang tuluyang naisulat sa log ng transaksyon ng pangalawa, hindi muling pinatakbo sa mga pahina ng datos nito. Maaaring mahuli ang redo nang ilang minuto nang hindi nagdaragdag ng kahit isang millisecond sa commit ng pangunahin.

Ang dokumentasyon ng Microsoft tungkol sa mga mode ng pagkakaroon ay nagpapaliwanag ng pakikipagkamay na iyon at naglalarawan kung ano ang ginagawa ng plataporma kapag nawala ang partner. Ang isang replica na minarkahan bilang synchronous ay isang tuntunin tungkol sa paghihintay, hindi isang permanenteng pangako na may malusog na malayong kopya para sa bawat commit. Ang nadiskonektang landas ay tinukoy nang hiwalay, at hindi lamang ito ang pagpalya ng commit.

Kaya ang paghihintay na nakikita mo ay isang kabuuan: transportasyon ng log, pag-iiskedyul sa parehong host at ang pagsulat sa malayong imbakan. Ang pangalawang replica na may puspos na volume ng log ay nagdaragdag ng oras na hindi ipapakita ng anumang pagsubok ng bilis. Bihirang sukatin ang disk na iyon kapag binanggit ng reklamo ang VPN.

Ang bandwidth ay hindi pagkaantala ng paglalakbay pabalik-balik

Binabaha ng pagsubok ng bilis ang landas nang sandali at nag-uulat ng rate. Ang commit ay humihingi ng mas makitid: gaano katagal ang isang maliit na mensahe upang maabot ang kabilang panig, mapanatili at makabalik. Ang haba ng landas, mga pila at pagkawala ng packet ang nagtatakda ng numerong iyon, at wala sa mga ito ang bumubuti kapag itinaas ng provider ang kisame.

Kaya ang isang «mabilis» na tunnel ay maaaring magdagdag ng nakikitang parusa sa isang workload na mabigat sa pagsulat na binubuo ng maraming maliliit na sunud-sunod na transaksyon. Ang parehong kabuuang bytes na hinati sa isang libong commit ay nagbabayad ng paglalakbay pabalik-balik ng isang libong beses; isang malaking paglilipat ang nagbabayad nito nang isang beses.

Hilingin sa may-ari ng network ang pagkaantala at pagkawala na sinusukat sa mismong ruta ng replica sa ilalim ng kinatawan na karga. Ang ping mula sa laptop sa opisina patungo sa gateway ng VPN, o pagsubok ng bilis patungo sa kalapit na node, ay halos walang iniuukol sa rutang dinadaanan ng log. Tiyakin na ang window ng pagsukat ay nagsasapaw sa mga oras na mabagal ang pagsulat.

Basahin ang estado ng replica bago baguhin ang anuman

Magsimula sa kung ano ang iniuulat ng mga instance tungkol sa kanilang sarili, dahil maaaring hindi magkasundo ang dalawang panig kung gaano kalusog ang pakikipagtulungan at itinatago ng average sa dashboard kung aling pila ang gumagalaw. Ang mga query sa ibaba ay sumasagot sa magkaibang tanong: ang isa ay nagbabasa ng estado ng replikasyon kada database, ang isa ay nagbabasa kung paano naka-configure ang bawat replica. Patakbuhin ang dalawa bago hawakan ang isang mode.

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;

Ang unang resulta ay naghihiwalay ng transportasyon ng log mula sa redo. Ang log_send_queue_size na tumataas habang ang redo_queue_size ay patag ay nangangahulugang hindi pa dumarating ang log; ang kabaligtaran ay nangangahulugang dumating ito at nahuhuli ang pag-playback. Tanging ang unang kaso ang nakaupo sa landas ng commit.

Kinukumpirma ng ikalawang resulta kung aling mga replica ang talagang naka-configure ayon sa inaasahan mo, dahil ang isang mode na binago noong nakaraang insidente ay may tendensiyang manatiling binago at walang dokumento. Basahin ang hilera na mahalaga sa iyo sa halip na ang default ng grupo: ang availability_mode_desc at failover_mode_desc ay kada replica. Ang secondary_lag_seconds ay umiiral lamang sa SQL Server 2016 at mas bago, kaya ang lumang build ay nag-iiwan sa iyo ng mga column ng send queue at redo lamang.

Pagkatapos ay sukatin ang isang kinatawan na pagsulat sa halip na umasa sa average ng dashboard. Patakbuhin ang bloke sa ibaba sa database ng pagkakaroon, pagkatapos ay patakbuhin muli laban sa parehong hugis ng talahanayan sa isang database sa labas ng grupo sa parehong instance. Ang agwat sa pagitan ng dalawang tagal ay isang magaspang na presyo para sa malayong log, at sa isang pagtatalo sa koponan ng network ito ay naninindigan nang mas mahusay kaysa sa isang graph. Pagkatapos ay baguhin ang isang variable nang paisa-isa, kung hindi ay wala nang kahulugan ang agwat.

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;

Ano ang binibili ng asynchronous commit, at ano ang gastos

Sa asynchronous commit, tumitigil ang pangunahin sa paghihintay sa kumpirmasyon ng malayong pagpapatigas, kaya umaalis ang paglalakbay pabalik-balik sa landas ng commit. Bumababa ang latency ng commit at malaya ang pangalawa na mahuli nang halagang walang sinumang kumokontrol. Iyon ay tunay na pagwawasto sa paghihintay at tunay na pagbabago sa pangako.

Ang presyo ay isang desisyon tungkol sa punto ng pagbawi. Kung mamatay ang pangunahin bago maabot ng log nito ang isang target ng failover na talagang magagamit mo, ang paglipat ng serbisyo sa asynchronous na kopya ay nagtatapon ng mga transaksyong iniulat na ng aplikasyon bilang commit. Walang dialog ng configuration ang nagpapakita nito nang ganoon, dahil ito ay isang tanong sa negosyo tungkol sa katanggap-tanggap na pagkawala, hindi isang setting ng performance. Isulat ang tinatanggap na window ng pagkawala bago ang insidente, hindi habang nangyayari.

Sumang-ayon sa mode kasama ang may-ari ng datos, sa sulat, kasama ang pamamaraan ng failover para sa kaso na hindi available ang ginustong target. Ang synchronous sa isang dokumento ng disenyo ay hindi isang operational na manwal, at ang asynchronous ay hindi isang lisensya upang itigil ang pagmamasid sa mga pila.

Pumili ng pagwawasto na maipagtatanggol mo mamaya

May apat na tapat na pagpipilian. Putulin ang maiiwasang paglalakbay pabalik-balik ng commit kung saan pinapayagan ng semantika ng aplikasyon ang pagbubuo; ayusin ang sinusukat na hadlang sa transportasyon o imbakan, na maaaring mangahulugan ng mas mabilis na volume ng log sa pangalawa sa halip na mas malaking tubo; ilapit ang replica upang lumiit ang paglalakbay; o luwagan ang patakaran ng proteksyon at tanggapin ang mas malawak na window ng pagkawala. Bawat isa ay bumibili ng latency sa pamamagitan ng paggastos ng ibang bagay, at ang ikaapat ay gumagastos ng tibay. Pangalanan ang gastos bago pumili.

Magpasya habang nasa harap mo nang sabay ang target ng latency ng workload at ang pangangailangan nito sa tibay, dahil ang pag-optimize ng isa ay tahimik na gumagastos ng isa pa. Pagkatapos ay patakbuhin muli ang parehong transaksyong sinukat mo bago ang pagbabago. Ang pagwawastong hindi kayang ilipat ang numerong iyon ay isang haka-haka na may suot na tiket ng pagbabago.

Itago ang mga pagbasa bago at pagkatapos sa talaan ng pagbabago. Kung hindi, uulitin ng susunod na taong makakita ng mabagal na pagsulat ang imbestigasyon mula sa simula at magsisimulang sisihin muli ang tunnel.