Ինչու է ձեր սինխրոն SQL հաստատումը սպասում VPN-ի գնալ-վերադառնալուն

Գրելու ուշացումը թռավ այն բանից հետո, երբ կրկնօրինակը տեղափոխվեց երկրորդ վայր, և թունելը ամենանոր բաղադրիչն է, ուստի մեղքը նրա վրա է ընկնում։ Թունելը կարող է անմեղ լինել՝ սինխրոն հաստատումով հասանելիության խմբի ներսում առաջնայինը չի կարող հաստատում ճանաչել, քանի դեռ հեռավոր լոգի գրառումը չի ավարտվել, ուստի յուրաքանչյուր գործարք վճարում է գնալ-վերադառնալ, ինչքան էլ մեգաբիթ կապը կարողանա կրել։ Թողունակությունը չափում է բայթերը վայրկյանում, ուշացումը չափում է, թե որքան է տևում մեկ փոխանակումը, և հաստատմանը պետք է ընդամենը մեկ փոքր փոխանակում՝ ավարտվելու համար։ Մեկ թիվ է լուծում վեճը՝ փոքր գործարքի հաստատման տևողությունը, չափված հասանելիության տվյալների բազայում, ապա նորից՝ նույն օրինակի տեղական աղյուսակի դեմ։

Ինչին է իրականում սպասում առաջնայինը

Սինխրոն հաստատման դեպքում առաջնայինը պահում է հաստատման ճանաչումը, քանի դեռ գործընկերը չի հաստատել, որ իր լոգի գրառումները կարծրացված են։ Կարծրացված նշանակում է հաստատուն կերպով գրված երկրորդայինի գործարքների լոգում, ոչ թե վերագործարկված նրա տվյալների էջերում։ Redo-ն կարող է րոպեներով հետ մնալ՝ առաջնայինի հաստատմանը ոչ մի միլիվայրկյան չավելացնելով։

Microsoft-ի փաստաթղթերը հասանելիության ռեժիմների մասին նկարագրում է այդ ձեռքսեղմումը և թե ինչ է անում հարթակը, երբ գործընկերը դուրս է ընկնում։ Սինխրոն նշված կրկնօրինակը սպասելու կանոն է, ոչ թե մշտական խոստում, որ յուրաքանչյուր հաստատման համար գոյություն ունի առողջ հեռավոր պատճեն։ Անջատված ուղին սահմանվում է առանձին, և դա պարզապես այն չէ, որ հաստատումը ձախողվում է։

Այսպիսով, ձեր տեսած սպասումը գումար է՝ լոգի տեղափոխում, պլանավորում երկու հոսթերում և գրառում հեռավոր պահոցում։ Հագեցած լոգի ծավալով երկրորդայինը ավելացնում է ժամանակ, որը ոչ մի արագության թեստ ցույց չի տա։ Այդ սկավառակը հազվադեպ է չափվում, երբ բողոքը նշում է VPN-ը։

Թողունակությունը գնալ-վերադառնալու ուշացում չէ

Արագության թեստը կարճ ժամանակով ողողում է ուղին և հաղորդում արագություն։ Հաստատումը հարցնում է ավելի նեղ բան՝ որքան ժամանակ է պետք փոքր հաղորդագրությանը մյուս կողմը հասնելու, պահպանվելու և վերադառնալու համար։ Ուղու երկարությունը, հերթերը և փաթեթների կորուստը որոշում են այդ թիվը, և դրանցից ոչ մեկը չի բարելավվում, երբ մատակարարը բարձրացնում է առաստաղը։

Ուստի «արագ» թունելը կարող է տեսանելի տուգանք ավելացնել գրառումով ծանր աշխատանքային բեռին, որը կառուցված է բազմաթիվ փոքր հաջորդական գործարքներից։ Նույն ընդհանուր բայթերը հազար հաստատման բաժանված վճարում են գնալ-վերադառնալը հազար անգամ, մեկ զանգվածային փոխանցումը վճարում է այն մեկ անգամ։

Խնդրեք ցանցի տիրոջը չափել ուշացումն ու կորուստը հենց կրկնօրինակի երթուղու վրա՝ ներկայացուցչական բեռի տակ։ Գրասենյակային նոութբուքից VPN դարպասին ping-ը կամ մոտակա հանգույցին արագության թեստը գրեթե ոչինչ չի վերագրում այն ուղուն, որով լոգը իրականում անցնում է։ Թույլ տվեք, որ չափման պատուհանը համընկնի դանդաղ գրառման ժամերի հետ։

Կարդացեք կրկնօրինակի վիճակը՝ նախքան որևէ բան փոխելը

Սկսեք նրանից, ինչ օրինակները հաղորդում են իրենց մասին, քանի որ երկու կողմերը կարող են տարաձայնվել, թե որքան առողջ է գործընկերությունը, և վահանակի միջինը թաքցնում է, թե որ հերթն է շարժվում։ Ներքևի հարցումները պատասխանում են տարբեր հարցերի՝ մեկը կարդում է ռեպլիկացիայի վիճակը յուրաքանչյուր տվյալների բազայի համար, մյուսը՝ թե ինչպես է կազմաձևված յուրաքանչյուր կրկնօրինակ։ Գործարկեք երկուսն էլ՝ նախքան որևէ ռեժիմի դիպչելը։

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-ը մնում է հարթ, նշանակում է, որ լոգը չի հասել, հակառակը նշանակում է, որ այն հասել է, և վերարտադրումը հետ է մնում։ Միայն առաջին դեպքն է նստում հաստատման ուղու վրա։

Երկրորդ արդյունքը հաստատում է, թե որ կրկնօրինակներն են իրոք կազմաձևված այնպես, ինչպես դուք ենթադրում եք, քանի որ նախորդ միջադեպի ընթացքում փոփոխված ռեժիմը հակված է մնալ փոփոխված և չփաստաթղթավորված։ Կարդացեք այն տողը, որը ձեզ հետաքրքրում է, խմբի լռելյայնի փոխարեն՝ 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;

Ինչ է գնում ասինխրոն հաստատումը և ինչ արժե

Ասինխրոն հաստատման դեպքում առաջնայինը դադարում է սպասել հեռավոր կարծրացման հաստատմանը, ուստի գնալ-վերադառնալը հեռանում է հաստատման ուղուց։ Հաստատման ուշացումը նվազում է, և երկրորդայինը ազատ է հետ մնալու այն չափով, որը ոչ ոք չի վերահսկում։ Դա իրական ուղղում է սպասման համար և իրական փոփոխություն խոստման մեջ։

Գինը վերականգնման կետի որոշում է։ Եթե առաջնայինը մահանում է, նախքան նրա լոգը կհասնի ձախողման անցման այն թիրախին, որը դուք իրոք կարող եք օգտագործել, ծառայությունը ասինխրոն պատճեն տեղափոխելը դեն է նետում գործարքները, որոնք հավելվածն արդեն հաղորդել էր որպես հաստատված։ Ոչ մի կազմաձևման երկխոսություն դա այդպես չի ներկայացնում, որովհետև դա ընդունելի կորստի մասին գործարար հարց է, ոչ թե արտադրողականության կարգավորում։ Գրեք հանդուրժվող կորստի պատուհանը միջադեպից առաջ, ոչ թե ընթացքում։

Պայմանավորվեք ռեժիմի շուրջ տվյալների տիրոջ հետ՝ գրավոր, նախընտրելի թիրախի անհասանելիության դեպքի ձախողման անցման ընթացակարգի հետ միասին։ Նախագծային փաստաթղթում սինխրոնը գործառնական ուղեցույց չէ, և ասինխրոնը լիցենզիա չէ հերթերին հետևելը դադարեցնելու համար։

Ընտրեք ուղղում, որը հետագայում կկարողանաք պաշտպանել

Գոյություն ունեն չորս ազնիվ տարբերակներ։ Կտրեք խուսափելի հաստատման գնալ-վերադառնալները այնտեղ, որտեղ հավելվածի իմաստաբանությունը թույլ է տալիս խմբավորում; ուղղեք ձեր չափած տեղափոխման կամ պահեստավորման խոչընդոտը, ինչը կարող է նշանակել ավելի արագ լոգի ծավալ երկրորդայինի վրա՝ ավելի մեծ խողովակի փոխարեն; մոտեցրեք կրկնօրինակը, որպեսզի գնալ-վերադառնալը փոքրանա; կամ թուլացրեք պաշտպանության քաղաքականությունը և ընդունեք ավելի լայն կորստի պատուհան։ Յուրաքանչյուրը գնում է ուշացում՝ ծախսելով այլ բան, և չորրորդը ծախսում է ամրությունը։ Անվանեք ծախսը՝ նախքան ընտրելը։

Որոշեք՝ միաժամանակ ձեր առջև ունենալով աշխատանքային բեռի ուշացման թիրախը և դրա ամրության պահանջը, որովհետև մեկի օպտիմալացումը լուռ ծախսում է մյուսը։ Ապա նորից գործարկեք այն նույն գործարքը, որը չափել էիք փոփոխությունից առաջ։ Ուղղումը, որը չի կարող շարժել այդ թիվը, փոփոխության տոմս կրող ենթադրություն է։

Պահեք փոփոխությունից առաջ և հետո ցուցումները փոփոխության գրառման մեջ։ Այլապես հաջորդ մարդը, ով կտեսնի դանդաղ գրառումներ, հետաքննությունը նորից կսկսի սկզբից և նորից կսկսի մեղադրել թունելին։