Kwa nini commit yako ya SQL ya wakati mmoja inasubiri safari ya VPN kwenda na kurudi

Ucheleweshaji wa uandishi uliruka baada ya nakala kuhamishwa hadi tovuti ya pili, na handaki ndiyo kipengele kipya zaidi, kwa hiyo inachukua lawama. Handaki inaweza kuwa haina hatia: ndani ya kikundi cha upatikanaji chenye commit ya wakati mmoja, msingi hauwezi kuthibitisha commit hadi uandishi wa kumbukumbu wa mbali ukamilike, kwa hiyo kila muamala hulipa safari ya kwenda na kurudi, bila kujali ni megabiti ngapi kiungo kinaweza kubeba. Kiwango cha upitishaji hupima baiti kwa sekunde, ucheleweshaji hupima muda ambao ubadilishanaji mmoja huchukua, na commit inahitaji ubadilishanaji mmoja mdogo tu ili kukamilika. Nambari moja huamua mzozo: muda wa commit ya muamala mdogo, uliopimwa ndani ya hifadhidata ya upatikanaji na kisha tena dhidi ya jedwali la ndani kwenye mfano huo huo.

Msingi unasubiri nini kwa kweli

Chini ya commit ya wakati mmoja, msingi hushikilia uthibitisho wa commit hadi mshirika athibitishe kuwa rekodi zake za kumbukumbu zimegandishwa. Kugandishwa kunamaanisha kuandikwa kwa kudumu kwenye kumbukumbu ya miamala ya ya pili, si kuendeshwa tena kwenye kurasa zake za data. Redo inaweza kubaki nyuma kwa dakika bila kuongeza millisekunde moja kwenye commit ya msingi.

Nyaraka za Microsoft kuhusu hali za upatikanaji zinaeleza mshikamano huo wa mikono na kueleza kile jukwaa hufanya mshirika anapoanguka. Nakala iliyowekwa alama ya wakati mmoja ni kanuni kuhusu kusubiri, si ahadi ya kudumu kwamba kuna nakala ya mbali yenye afya kwa kila commit. Njia iliyokatwa inafafanuliwa kwa tofauti, na si tu kwamba commit inashindwa.

Kwa hiyo kusubiri unakoona ni jumla: usafirishaji wa kumbukumbu, upangaji kwenye wenyeji wote wawili na uandishi kwenye hifadhi ya mbali. Ya pili yenye kiasi cha kumbukumbu kilichojaa huongeza muda ambao hakuna jaribio la kasi litakaoonyesha. Diski hiyo hupimwa mara chache malalamiko yanapotaja VPN.

Upana wa bendi si ucheleweshaji wa safari ya kwenda na kurudi

Jaribio la kasi hufurika njia kwa muda mfupi na kuripoti kasi. Commit inaomba kitu chembamba zaidi: muda ambao ujumbe mdogo huchukua kufikia upande wa pili, kuhifadhiwa na kurudi. Urefu wa njia, foleni na upotevu wa pakiti huamua nambari hiyo, na hakuna moja yao inaboreshwa mtoa huduma anapoinua dari.

Kwa hiyo handaki «ya haraka» inaweza kuongeza adhabu inayoonekana kwa mzigo wa kazi wenye uandishi mzito uliojengwa kwa miamala mingi midogo mfululizo. Jumla hiyo hiyo ya baiti ikigawanywa kwa commit elfu moja hulipa safari ya kwenda na kurudi mara elfu; uhamishaji mmoja mkubwa huilipa mara moja.

Mwombe mmiliki wa mtandao apime ucheleweshaji na upotevu kwenye njia ya nakala yenyewe chini ya mzigo wa uwakilishi. Ping kutoka kwa kompyuta ya mkononi ya ofisi hadi lango la VPN, au jaribio la kasi hadi nodi iliyo karibu, haliangazii karibu chochote njia ambayo kumbukumbu husafiri kweli. Hakikisha dirisha la upimaji linaingiliana na saa ambazo uandishi ni wa polepole.

Soma hali ya nakala kabla ya kubadilisha chochote

Anza na kile mifano inaripoti kuhusu yenyewe, kwa sababu pande mbili zinaweza kutokubaliana kuhusu jinsi ushirikiano ulivyo na afya na wastani wa dashibodi huficha foleni ipi inasonga. Maswali hapa chini hujibu maswali tofauti: moja husoma hali ya urudufishaji kwa kila hifadhidata, lingine husoma jinsi kila nakala imesanidiwa. Endesha yote mawili kabla ya kugusa hali yoyote.

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;

Tokeo la kwanza hutenganisha usafirishaji wa kumbukumbu na redo. log_send_queue_size ikipanda wakati redo_queue_size imesimama tambarare inamaanisha kumbukumbu haijafika; kinyume chake inamaanisha imefika na uchezaji upya umebaki nyuma. Ni kesi ya kwanza pekee inayokaa kwenye njia ya commit.

Tokeo la pili huthibitisha ni nakala zipi zimesanidiwa kweli kama unavyodhani, kwa sababu hali iliyobadilishwa wakati wa tukio la awali huwa inabaki imebadilishwa na bila nyaraka. Soma safu inayokuhusu badala ya chaguo-msingi la kikundi: availability_mode_desc na failover_mode_desc ni kwa kila nakala. secondary_lag_seconds inapatikana tu kwenye SQL Server 2016 na baadaye, kwa hiyo ujenzi wa zamani unakuachia safu za foleni ya kutuma na redo pekee.

Kisha pima uandishi wa uwakilishi badala ya kuamini wastani wa dashibodi. Endesha kizuizi hapa chini kwenye hifadhidata ya upatikanaji, kisha kiendeshe tena dhidi ya umbo hilo hilo la jedwali kwenye hifadhidata nje ya kikundi kwenye mfano huo huo. Pengo kati ya muda hizo mbili ni bei mbaya ya kumbukumbu ya mbali, na katika mjadala na timu ya mtandao inashikilia vizuri zaidi kuliko grafu. Baada ya hapo badilisha kigezo kimoja kwa wakati mmoja, vinginevyo pengo hilo halina maana tena.

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 isiyo ya wakati mmoja inanunua nini, na inagharimu nini

Kwa commit isiyo ya wakati mmoja, msingi huacha kusubiri uthibitisho wa ugandishaji wa mbali, kwa hiyo safari ya kwenda na kurudi inaondoka kwenye njia ya commit. Ucheleweshaji wa commit hupungua na ya pili iko huru kubaki nyuma kwa kiasi ambacho hakuna anayedhibiti. Hiyo ni marekebisho ya kweli kwa kusubiri na mabadiliko ya kweli kwenye ahadi.

Bei ni uamuzi kuhusu hatua ya urejeshaji. Iwapo msingi unakufa kabla kumbukumbu yake kufikia lengo la uhamishaji wa hitilafu ambalo unaweza kutumia kweli, kuhamisha huduma hadi nakala isiyo ya wakati mmoja hutupa miamala ambayo programu ilikuwa imeripoti kama imethibitishwa. Hakuna mazungumzo ya usanidi yanayoiwasilisha hivyo, kwa sababu ni swali la biashara kuhusu upotevu unaokubalika, si mpangilio wa utendaji. Andika dirisha la upotevu linalovumilika kabla ya tukio, si wakati wake.

Kubaliana kuhusu hali na mmiliki wa data, kwa maandishi, pamoja na utaratibu wa uhamishaji wa hitilafu kwa kesi ambapo lengo linalopendelewa halipatikani. Ya wakati mmoja katika hati ya usanifu si mwongozo wa uendeshaji, na isiyo ya wakati mmoja si leseni ya kuacha kufuatilia foleni.

Chagua marekebisho ambayo unaweza kuyatetea baadaye

Kuna chaguo nne za uaminifu. Kata safari za commit za kwenda na kurudi zinazoweza kuepukwa pale ambapo maana ya programu inaruhusu uunganishaji; rekebisha kizuizi cha usafirishaji au hifadhi ulichopima, ambacho kinaweza kumaanisha kiasi cha kumbukumbu cha haraka zaidi kwenye ya pili badala ya bomba kubwa; sogeza nakala karibu ili safari ipungue; au legeza sera ya ulinzi na ukubali dirisha pana la upotevu. Kila moja hununua ucheleweshaji kwa kutumia kitu kingine, na ya nne hutumia uimara. Taja matumizi kabla ya kuchagua.

Amua ukiwa na lengo la ucheleweshaji wa mzigo wa kazi na hitaji lake la uimara mbele yako kwa wakati mmoja, kwa sababu kuboresha moja hutumia lingine kimya kimya. Kisha endesha tena muamala huo huo uliopima kabla ya mabadiliko. Marekebisho yasiyoweza kusogeza nambari hiyo ni dhana iliyovaa tikiti ya mabadiliko.

Hifadhi usomaji wa kabla na baada katika rekodi ya mabadiliko. Vinginevyo mtu anayefuata kuona uandishi wa polepole hurudia uchunguzi tangu mwanzo na huanza tena kulaumu handaki.