Bakit Pinapabagal Pa Rin ng Mabilis na VPN ang Isang Sabayang Komit sa SQL

Magbukas ng sesyon ng query sa primary at tingnan kung ano ang hinihintay ng simpleng pagsulat. Kung ang database ay kabilang sa isang grupo ng availability na may sabayang komit at konektado ang sekondarya, ang bahagi ng paghihintay ay lumalabas sa gusali: naglalakbay ang mga tala ng log patungo sa replika, pinatitibay doon, at bumabalik ang balita ng pagpapatibay na iyon bago matapos ang komit. Hindi pinaiikli ng bandwidth ang paglalakbay pabalik-balik. Sinusundan ng paglalakad sa ibaba ang pag-amin mula sa screen hanggang sa malayong disk at pabalik.

Magsimula sa uri ng paghihintay sa primary

Ang pagsulat na naghihintay sa malayong replika ay lumalabas bilang paghihintay na may kaugnayan sa log at hindi bilang paghihintay ng CPU o lock, at ang tagal ng transaksyon ay sumusunod sa paglalakbay pabalik-balik sa halip na bilang ng mga hilera. Maraming maliliit na komit ang nagpapalinaw nito, dahil bawat isa ay nagbabayad ng paglalakbay nang hiwalay. Ang isang malaking operasyon ay nagtatago ng parehong gastos sa loob ng isang mas mahabang pag-amin.

Pag-uri-uriin ang iyong karga ng trabaho ayon sa dalas ng komit bago magpasya ng anuman tungkol sa link.

Basahin ang kalagayan ng replika bago basahin ang network. Ang mahalagang mga counter ay ang pila ng pagpapadala, pila ng redo at kalagayan ng pag-sync, at magkasama nilang ipinapakita kung nakakasabay o nahuhuli ang sekondarya. Ang lumalaking pila ng pagpapadala ay tumuturo sa transport, samantalang ang lumalaking pila ng redo ay tumuturo sa sariling trabaho o imbakan ng sekondarya. Magkaibang pag-aayos iyon, at wala sa kanila ang bumubuti sa pamamagitan ng pagdagdag ng bandwidth.

Sundan ang pag-amin hanggang sa sekondarya

Sa sabayang komit, hinihintay ng primary ang kumpirmasyon na pinatibay sa sekondarya ang kaugnay na log bago iulat ang komit bilang tapos. Ang pinatibay ay nangangahulugang matibay sa log, hindi muling naipakita sa mga pahina ng data. Iyon mismong pagkakaiba ang dahilan kung bakit ang sabayang sekondarya ay maaaring mahuli sa redo habang kumpirmado pa rin ang pagpapatibay.

Lakarin ang landas nang sunod-sunod at sukatin ang bawat yugto sa halip na ang kabuuan. Dumadaan ang mga tala ng log sa transport, isinusulat at isinasawsaw ito ng sekondarya, at bumabalik ang pag-amin sa parehong landas. Ang pagkaantala ng transport, pag-iskedyul ng sekondarya at latency ng log disk ng sekondarya ay lahat pumapasok sa kabuuan, at ang una lamang ang pag-aari ng may-ari ng network. Ang sekondaryang puno ang dami ng log ng ibang bagay ay maaaring magpahaba ng bawat komit habang walang ginagawa ang link.

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;

Kunin ang snapshot na iyon bago at pagkatapos ng isang kinatawang pagsulat sa halip na minsan sa isang tahimik na hapon. Ang pagkakaiba ang nagsasabi sa iyo kung aling pila ang gumalaw habang naghihintay ang komit.

Sukatin ang landas, hindi ang link

Sinusukat ng pagsubok sa throughput ang kakayahan sa pagitan ng dalawang punto na hindi ang iyong mga replika, sa ilalim ng kargang hindi ang iyong trabaho. Hilingin sa may-ari ng network ang pagkaantala at pagkawala sa kahabaan ng tunay na landas ng replika habang dumadaan ang tunay na trapiko, sa dalawang direksyon. Mas mahalaga ang pagkawala kaysa kakayahan dito, dahil ang nawalang segment ay nagkakahalaga ng muling pagpapadala at ang bawat komit ay naghihintay ng isang pag-amin. Ang link na mukhang mahusay sa pagsubok ng pag-download ay maaaring hindi pa rin angkop sa isang madaldal na pattern ng komit.

Panatilihing buo ang seguridad ng transport ng database at mga kontrol sa pag-access habang nagsusukat. Ang pagsukat ng landas ay hindi kailanman dahilan upang laktawan ang mga iyon.

Iugnay ang mga oras sa mga counter sa halip na sa kutob. Kung nananatiling walang laman ang pila ng pagpapadala at naghihintay pa rin ang komit, ang pagkaantala ay nasa pag-amin o sa pagsasawsaw ng sekondarya. Kung patuloy na lumalaki ang pila ng pagpapadala, ang hadlang ay ang transport o kakayahan. Itala kung aling obserbasyon ang sumuporta sa konklusyon upang maulit ng susunod na tao ang pagsukat at hindi ang pagtatalo.

Ano ang tunay na binabago ng asinkronikong mode

Inaalis ng asinkronikong komit ang paghihintay sa pagpapatibay ng sekondarya, kaya mas mabilis ang pagsulat at kaya nagbabago ang iyong posisyon sa tibay. Kinukumpirma ng primary ang transaksyon nang wala ang malayong kumpirmasyong iyon. Pagkatapos ay pinapayagang mahuli ang sekondarya, at ang pagkahuling iyon ang pagkakalantad.

Kung mawala ang primary bago maabot ng log ang isang magagamit na target ng failover, itinatapon ng pagpilit sa serbisyo patungo sa replikang iyon ang mga transaksyong naipabatid na sa application na komit na.

Ito ay desisyon sa punto ng pagbawi at pag-aari ito ng may-ari ng database, hindi ng pagsusuri ng pagganap. Itakda muna ang tinatanggap na window ng pagkawala ng data, piliin ang mode na tumutugon dito, pagkatapos ay i-optimize sa loob ng hangganang iyon. Kabilang sa mga opsyon na nagpapanatili ng sabayang proteksyon ang pagtanggal ng maiiwasang paglalakbay ng komit kung saan pinapayagan ng application, pag-aayos ng nasukat na bottleneck sa transport o imbakan, at paglipat ng replika upang mas maikling distansya ang lakarin ng pag-amin. Timbangin ang mga ito laban sa pangangailangan sa tibay na sinimulan mo, na hindi nagbago.