SQL Server Միշտ միացված. DBA-ի ամբողջական ուղեցույց [2026]

SQL Server Always On-ը Microsoft-ի համապարփակ բարձր մատչելիության և աղետներից վերականգնման լուծումն է, որը ներկայացված է SQL Server 2012թ.: Այն ներկայացնում է զգալի առաջընթաց նախորդ տեխնոլոգիաների համեմատ, ինչպիսիք են տվյալների բազայի հայելային արտացոլումը և գրանցամատյանների առաքումը, ապահովելով տվյալներին անընդհատ հասանելիություն՝ միաժամանակ նվազագույնի հասցնելով աշխատանքի ընդհատումը և տվյալների կորուստը:

1.2 Ինչու են բիզնեսները միշտ կարիք ունենում լուծումների

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

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

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

1.3 Հիմնական հասկացություններ՝ RTO, RPO, HA և DR

Վերականգնման ժամանակի նպատակ (RTO) սահմանում է խափանումից հետո դադարի առավելագույն ընդունելի տևողությունը՝ որքան արագ պետք է տվյալների բազան վերականգնվի առցանց ռեժիմում։

Վերականգնման կետի նպատակ (RPO) սահմանում է ժամանակի մեջ չափված առավելագույն ընդունելի տվյալների կորուստը՝ այսինքն՝ թե որքան վերջերս գրանցված տվյալներ կարող է բիզնեսը թույլ տալ կորցնել։

Բարձր մատչելիություն (ԲՄ) կենտրոնանում է նույն տվյալների կենտրոնում պարբերաբար առաջացող խափանումների, ինչպիսիք են սարքային անսարքությունները կամ ծրագրային ապահովման խափանումները, պատճառով առաջացած դադարների նվազագույնի հասցնելու վրա։

Աղետների վերականգնում (DR) Անդրադառնում է ամբողջ կայքերին ազդող աղետալի իրադարձություններին՝ պահպանելով տվյալների պատճենները աշխարհագրորեն տարբեր վայրերում: Մինչդեռ HA-ն կենտրոնանում է խափանումների նվազագույնի հասցնելու վրա, DR-ն կենտրոնանում է խոշոր միջադեպերի ժամանակ տվյալների պաշտպանության և բիզնեսի շարունակականության ապահովման վրա:

SQL Server Միշտ միացված ռեժիմը աջակցում է և՛ HA-ին, և՛ DR-ին մեկ միասնական ճարտարապետության շրջանակներում: Սինխրոն հաստատման ռեժիմը ապահովում է RPO = 0՝ գրեթե զրոյական RTO-ի համար ավտոմատ անցումային ռեժիմով. ասինխրոն հաստատման ռեժիմը ընդունում է տվյալների հնարավոր կորուստը՝ հեռավոր կայքերում ավելի ցածր լատենտության ազդեցության դիմաց:

1.4 Միշտ լուծումների վրա

SQL Server Always On-ը տրամադրում է տեղակայման երեք տարբերակ, որոնցից յուրաքանչյուրը համապատասխանում է տարբեր մատչելիության և ենթակառուցվածքային պահանջներին: Այս ուղեցույցը ներառում է բոլոր երեքը՝

Մշտապես հասանելի խմբեր (AG): Տվյալների բազայի մակարդակի բարձր մատչելիություն և աղետներից վերականգնում՝ առանց համատեղ պահեստավորման։
Միշտ միացված Failover կլաստերի դեպքեր (FCI): Օրինակի մակարդակի բարձր մատչելիություն՝ օգտագործելով համատեղ պահեստավորում։
AG + FCI համակցված՝ Երկշերտ պաշտպանություն, որը համատեղում է օրինակի և տվյալների բազայի մակարդակի failover-ը՝ առավելագույն կայունության համար։

2. Մշտապես հասանելի խմբեր

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

2.1 Հիմնական առանձնահատկությունները

Տվյալների բազայի մակարդակի ձախողում. առանձին տվյալների բազաները կամ խմբերը կարող են ձախողվել անկախ SQL Server օրինակ;
մինչև ինը կրկնօրինակ (մեկ հիմնական, ութ երկրորդական) Enterprise Edition-ում։
սինխրոն-կոմիտ ռեժիմ՝ տվյալների զրոյական կորստի համար, ասինխրոն-կոմիտ ռեժիմ՝ հեռավոր DR կրկնօրինակների համար։
ավտոմատ անցում համաժամանակյա կրկնօրինակների համար, երբ առաջնայինը անհասանելի է դառնում։
ընթեռնելի երկրորդային կրկնօրինակներ՝ հաշվետվությունների և պահուստային աշխատանքային բեռները բեռնաթափելու համար։
Հասանելիության խմբի լսողը տրամադրում է մեկ միացման վերջնակետ, որը ավտոմատ կերպով ուղղորդվում է դեպի ընթացիկ հիմնականը։

2.2 Իրականացման քայլեր

Պատրաստել Active Directory ծառայության հաշիվները և կարգավորել թույլտվությունները բոլոր հանգույցների վրա։
տեղադրել և ստուգել Windows Server Failover Clustering-ը բոլոր մասնակից սերվերների վրա։
տեղադրել SQL Server որպես առանձին օրինակ յուրաքանչյուր հանգույցի վրա՝ օգտագործելով հետևողական ուղիներ և կարգավորումներ։
Միացրեք «Միշտ միացված հասանելիության խմբեր» գործառույթը՝ SQL Server Կազմաձևման կառավարիչ կամ PowerShell;
տվյալների բազաները կարգավորել լրիվ վերականգնման մոդելի վրա և կատարել լրիվ և գրանցամատյանների պահուստային պատճեններ։
ստեղծել մատչելիության խումբ, ավելացնել կրկնօրինակներ և կարգավորել մատչելիության և ձախողման ռեժիմները։
երկրորդային կրկնօրինակների սերմնավորում՝ օգտագործելով ավտոմատ սերմնավորում կամ ձեռքով պահուստավորում և վերականգնում։
Ստեղծեք մատչելիության խմբի լսող և ստուգեք հաճախորդի կապը։

Ամբողջական քայլ առ քայլ ուղեցույցի համար տե՛ս մեր «Միշտ հասանելի խմբեր» ամբողջական ուղեցույց.

2.3 Լավագույնը

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

2.4 Կողմ

Համատեղ պահեստավորման կարիք չկա. յուրաքանչյուր կրկնօրինակ օգտագործում է անկախ տեղական պահեստավորում։
աջակցում է և՛ HA-ին, և՛ DR-ին մեկ կոնֆիգուրացիայում։
ընթեռնելի երկրորդական սկավառակները նվազեցնում են առաջնային աշխատանքային ծանրաբեռնվածությունը։
Տվյալների բազայի մակարդակի մանրամասնությունը թույլ է տալիս տարբեր ձախողման քաղաքականություններ յուրաքանչյուր տվյալների բազայի խմբի համար։

2.5 Դեմ

Լրիվ հնարավորությունների համար անհրաժեշտ է Enterprise Edition (Ստանդարտ տարբերակը աջակցում է Basic AG-ին՝ էական սահմանափակումներով)։
սինխրոն հաստատման ռեժիմը ավելացնում է գրման լատենտություն, որը համամասնական է ցանցի երկկողմանի փոխանցման ժամանակին։
Մուտքերը, SQL Agent-ի աշխատանքները և կապված սերվերները պահանջում են ձեռքով համաժամեցում SQL Server 2019 և ավելի վաղ;
Բոլոր կրկնօրինակները պետք է գտնվեն նույն Windows Server Failover կլաստերի հանգույցներում։

2.6 հղումներ

Microsoft-ի պաշտոնական փաստաթուղթը. Ի՞նչ է «Միշտ միացված» հասանելիության խումբը։
Microsoft-ի պաշտոնական փաստաթուղթը. Ստանալով StarՄիշտ հասանելի խմբերի հետ

3. Միշտ միացված Failover կլաստերի օրինակներ

Միշտ միացված Failover կլաստերի դեպքեր (FCI) ապահովում է օրինակի մակարդակի բարձր մատչելիություն՝ գործարկելով մեկ SQL Server օրինակ՝ մի քանի ֆիզիկական հանգույցների վրա, որոնք կիսում են նույն պահեստը։ Երբ ակտիվ հանգույցը խափանվում է, SQL Server սպասման հանգույցի վրա գտնվող օրինակը ավտոմատ կերպով վերագործարկվում էtarted, դարձնելով անցումը թափանցիկ հաճախորդի ծրագրերի համար։

3.1 Հիմնական առանձնահատկությունները

Օրինակի մակարդակի ձախողում. օրինակի բոլոր տվյալների բազաները միասին ձախողվում են որպես մեկ միավոր։
համօգտագործվող պահեստ (Storage Area Network (SAN), iSCSI, Storage Spaces Direct կամ SMB), որը հասանելի է բոլոր հանգույցների կողմից։
Վիրտուալ ցանցի անունը և վիրտուալ IP հասցեն ապահովում են կայուն միացման վերջնակետ՝ անկախ նրանից, թե որ հանգույցն է ակտիվ։
Windows Server Failover Clustering-ը կառավարում է հանգույցների վիճակի մոնիթորինգը, քվորումը և failover-ի կազմակերպումը։
Աջակցում է Ակտիվ/Պահպանի, Ակտիվ/Ակտիվ, N+1 և N+M հանգույցի կոնֆիգուրացիայի տեսակները։

3.2 Իրականացման քայլեր

Բոլոր կլաստերային հանգույցներին համատեղ պահեստի տրամադրում և կցում։
տեղադրել Failover Clustering գործառույթը և ստուգել կլաստերի կարգավորումը։
ստեղծել Windows Server Failover Cluster և կարգավորել քվորումը։
վազել SQL Server տեղադրում՝ ընտրելով failover կլաստերի տարբերակը և նշելով վիրտուալ ցանցի անունը և համատեղ օգտագործվող պահեստավորման ուղիները։
ավելացնել լրացուցիչ հանգույցներ SQL Server ձախողման կլաստերի օրինակ;
Ստուգեք ձախողման վարքագիծը՝ փորձարկելով հանգույցների միջև ձեռքով ձախողումը։

Ամբողջական քայլ առ քայլ ուղեցույցի համար տե՛ս մեր SQL Server Failover Cluster-ի ամբողջական ուղեցույց.

3.3 Լավագույնը

Գործող համատեղ պահեստավորման ենթակառուցվածքներով միջավայրեր (SAN կամ iSCSI);
ծրագրեր, որոնք պահանջում են օրինակի մակարդակի ձախողում, որտեղ բոլոր տվյալների բազաները պետք է միասին ձախողվեն։
իրավիճակներ, երբ հաճախորդի թափանցիկությունը կարևոր է, և կիրառական կողմում որևէ փոփոխություն ընդունելի չէ։
կազմակերպություններ, որոնք առաջնահերթություն են տալիս միակողմանի ձախողման մոդելի պարզությանը։

3.4 Կողմ

Ավտոմատ failover ինստանսի մակարդակում՝ առանց հաճախորդի վերակազմաձևման անհրաժեշտության։
տվյալների վերարտադրման վրա ծախս չկա՝ բոլոր հանգույցները մուտք ունեն նույն պահեստին։
կանխատեսելի ձախողման վարքագիծ բոլոր տվյալների բազաների համար միաժամանակ;
Աջակցում է հանգույցների ճկուն կոնֆիգուրացիաներ (Ակտիվ/Ակտիվ, N+1, N+M)՝ սարքավորումների օգտագործումը օպտիմալացնելու համար։

3.5 Դեմ

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

3.6 հղումներ

Microsoft-ի պաշտոնական փաստաթուղթը. Միշտ միացված Failover կլաստերի օրինակներ (SQL Server)

4. Միավորել հասանելիության խմբերը Failover կլաստերային օրինակների հետ

Կազմակերպությունների համար, որոնք պահանջում են ինչպես օրինակային, այնպես էլ տվյալների բազայի մակարդակի պաշտպանություն, SQL Server աջակցում է h-ինostFailover Cluster Instances (FCI)-ի վրա հասանելիության խմբի կրկնօրինակների ստեղծում: Այս կոնֆիգուրացիայում յուրաքանչյուր FCI հանգույց գործում է որպես առանձին հասանելիության կրկնօրինակ, ուստի FCI failover-ը թափանցիկ է հասանելիության խմբի համար, մինչդեռ AG failover-ը ապահովում է տվյալների բազայի մակարդակի պաշտպանություն բոլոր կայքերում: Այս համադրությունը ապահովում է most հասանելի է բարձր մատչելիության և աղետներից վերականգնման համապարփակ ծածկույթ SQL Server.

4.1 Հիմնական առանձնահատկությունները

Երկշերտ failover. FCI-ն կարգավորում է օրինակի մակարդակի հանգույցների խափանումները, AG-ն կարգավորում է կայքի մակարդակի կամ կրկնօրինակի մակարդակի խափանումները։
Յուրաքանչյուր FCI հաշվվում է որպես մեկ կրկնօրինակ հասանելիության խմբում՝ անկախ նրանից, թե քանի հանգույց է պարունակում FCI-ն։
FCI-hostխմբագրված կրկնօրինակները դեռևս պահանջում են համատեղ պահեստավորում՝ համաձայն FCI ստանդարտ պահանջների։
AG կրկնօրինակներ hostFCI-ներում աջակցվում է միայն ձեռքով անցումը. ավտոմատ անցումը հասանելի չէ FCI-h-ի համար։ostխմբագրված կրկնօրինակներ;
Առանձին օրինակները կարող են մասնակցել նույն մատչելիության խմբին՝ FCI-h-ի հետ միասին։ostխմբագրված կրկնօրինակներ։

4.2 Իրականացման քայլեր

Տեղակայել և վավերացնել յուրաքանչյուր FCI անկախ՝ հետևելով FCI-ի ստանդարտ կարգավորման ընթացակարգերին։
համոզվեք, որ բոլոր FCI հանգույցները և առանձին կրկնօրինակ հանգույցները պատկանում են նույն Windows Server Failover կլաստերին։
միացրեք «Միշտ միացված հասանելիության խմբեր» գործառույթը FCI-ի յուրաքանչյուր օրինակի վրա։
ստուգեք, որ ոչ մի WSFC հանգույց չի host նույն հասանելիության խմբի երկու կրկնօրինակներ FCI-ի ցանկացած հնարավոր ձախողումից հետո։
ստեղծել մատչելիության խումբ՝ FCI օրինակները նշանակելով որպես կրկնօրինակներ և կարգավորելով ձեռքով ձախողման ռեժիմը բոլոր FCI-h-ների համար։ostխմբագրված կրկնօրինակներ;
սերմնավորել երկրորդական կրկնօրինակները և կարգավորել հասանելիության խմբի լսիչը։

FCI կարգավորման մանրամասների համար տե՛ս մեր SQL Server Failover Cluster-ի ամբողջական ուղեցույց: AG կարգավորման մանրամասների համար տե՛ս մեր «Միշտ հասանելի խմբերի» ամբողջական ուղեցույցը:

4.3 Լավագույնը

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

4.4 Կողմ

Առավելագույն պաշտպանություն. հանգույցի խափանումները կարգավորվում են FCI-ի կողմից, տեղամասի խափանումները կարգավորվում են AG-ի կողմից։
FCI-ի ձախողումը թափանցիկ է հասանելիության խմբի համար — AG-ն չի տեսնում որևէ կրկնօրինակի փոփոխություն FCI-ի ձախողման ժամանակ։
ճկուն տոպոլոգիա՝ FCI-h խառնուրդostխմբագրված և առանձին կրկնօրինակներ նույն հասանելիության խմբում։

4.5 Դեմ

FCI-hostխմբագրված կրկնօրինակները աջակցում են միայն ձեռքով AG failover-ը — ավտոմատ AG failover-ը հասանելի չէ այս կրկնօրինակների համար։
պահանջում է WSFC հանգույցի ուշադիր պլանավորում՝ մեկ հանգույցի h-ից խուսափելու համար։ostFCI-ի ձախողումից հետո նույն AG-ի երկու կրկնօրինակների ստեղծումը։
բարձր ենթակառուցվածքային գost և գործառնական բարդություն, քան միայն AG-ն կամ FCI-ը։
FCI-ի յուրաքանչյուր բաղադրիչի համար դեռևս անհրաժեշտ է համատեղ պահեստ։

4.6 հղումներ

Microsoft-ի պաշտոնական փաստաթուղթը. Failover կլաստերացում և միշտ միացված հասանելիության խմբեր (SQL Server)
Microsoft-ի պաշտոնական փաստաթուղթը. Ի՞նչ է «Միշտ միացված» հասանելիության խումբը։
Microsoft-ի պաշտոնական փաստաթուղթը. Ստանալով StarՄիշտ հասանելի խմբերի հետ
Microsoft-ի պաշտոնական փաստաթուղթը. Միշտ միացված Failover կլաստերի օրինակներ (SQL Server)

5. Միշտ միացված լուծումների համեմատություն

5.1 Հատկանիշների համեմատական աղյուսակ

առանձնահատկություն	Հասանելիության խմբեր	Failover կլաստերի օրինակներ	AG + FCI համակցված
Failover շրջանակ	Տվյալների բազայի մակարդակ	Օրինակի մակարդակ	Երկուսն էլ
Անհրաժեշտ է համատեղ պահեստ	Ոչ	Այո	Այո (FCI բաղադրիչի համար)
Տվյալների կրկնօրինակում	Յուրաքանչյուր կրկնօրինակի համար՝ հիմնված լոգարիթմի վրա	Ոչ մեկը (համօգտագործվող պահեստ)	ՖԿԻ-ների միջև լոգարիթմական տվյալների հիման վրա
Ավտոմատ ձախողում	Այո (սինխրոն կրկնօրինակներ)	Այո	FCI: Այո; AG: Ոչ
Ընթերցելի երկրորդական տեքստեր	Այո	Ոչ	Այո (AG բաղադրիչ)
Աղետների վերականգնումը	Ներկառուցվող	Ներկառուցված չէ	Ներկառուցվող
Առավելագույն կրկնօրինակներ	9 (Ձեռնարկություն)	N / A	9 (Ձեռնարկություն)
Ենթակառուցվածքի բարդությունը	Միջին	Միջին	Բարձր
Cost	Ավելի ցածր (SAN անհրաժեշտ չէ)	Ավելի բարձր (պահանջվում է SAN)	Ամենաբարձրը

5.2 Ընտրեք ձեր միշտ միացված լուծումը

Starձեր պահեստային ենթակառուցվածքի հետ. եթե դուք չունեք առկա համատեղ պահեստային տարածք, մատչելիության խմբերը բնական ընտրություն են, և մost cost-արդյունավետ ուղի դեպի և՛ HA, և՛ DR: Եթե դուք արդեն իսկ շահագործում եք SAN միջավայր և անհրաժեշտ է օրինակի մակարդակի failover, FCI-ն ավելի պարզ տարբերակ է, բայց պլանավորեք AG ավելացնել ավելի ուշ, եթե ապագայում միջկայքային DR-ը պահանջ լինի:

Ընտրեք AG + FCI համադրությունը միայն այն դեպքում, երբ ունեք իրական կարիք պաշտպանության երկու շերտերի և գործառնական հասունության՝ աճող բարդությունը կառավարելու համար: Հիշելու հիմնական սահմանափակումն այն է, որ FCI-h-ըosted AG կրկնօրինակները չեն աջակցում AG ավտոմատ failover-ը, ուստի այս տոպոլոգիան պահանջում է ձեռքով միջամտություն մատչելիության խմբի մակարդակի failover-ների համար։

Մ – ի համարost Այսօրվա նոր տեղակայումների համար խորհուրդ է տրվում օգտագործել «Միշտ հասանելի խմբերը» տարբերակը։tarկարևորագույն կետը. այն ընդգրկում է և՛ HA, և՛ DR, չի պահանջում համատեղ պահեստավորում և աջակցում է ընթեռնելի երկրորդական հիշողություններ՝ հնարավորություններ, որոնց միայն FCI-ն չի կարող համեմատվել։

6. Լավագույն փորձը SQL Server Միշտ լուծումների վրա

6.1 Պլանավորում և նախագծում

Միշտ միացված լուծում ընտրելուց առաջ սահմանեք RTO և RPO պահանջները՝ սրանք tarստանում է ուղղակիորեն որոշելու, թե արդյոք համաժամանակյա, թե ասինխրոն հաստատման ռեժիմը նպատակահարմար է, և արդյոք ավտոմատ ձախողման ռեժիմը հնարավոր է։
Սահմանեք երկրորդական կրկնօրինակների չափը՝ ձախողման դեպքում ամբողջ հիմնական աշխատանքային ծանրաբեռնվածությունը կարգավորելու համար, ներառյալ գագաթնակետային ծանրաբեռնվածության սցենարները։
AG տեղակայումների համար, գրման ուշացման ազդեցությունը նվազագույնի հասցնելու համար, սինխրոն կրկնօրինակները տեղադրեք նույն տվյալների կենտրոնում կամ ցածր լատենտությամբ ցանցում: Ասինխրոն ռեժիմը պահեք աշխարհագրորեն հեռավոր DR կրկնօրինակների համար:
Քվորումը նախագծեք կենտ թվով ձայներով։ Երկու հանգույցից բաղկացած կլաստերների համար ավելացրեք ֆայլի համօգտագործում կամ ամպային վկա որպես երրորդ քվեարկություն՝ ուղեղի պառակտման սցենարներից խուսափելու համար։
Զգուշորեն պլանավորեք ձեր ցանցի տոպոլոգիան բազմաենթացանցային տեղակայումների համար: Յուրաքանչյուր ենթացանց պահանջում է իր սեփական լսողի IP հասցեն, և հաճախորդների միացման տողերում անհրաժեշտ է MultiSubnetFailover=True արժեքը:

6.2 Կիրառման ուղեցույցներ

Օգտագործեք հետևողական SQL Server տարբերակի, հրատարակության և կուտակային թարմացման մակարդակները բոլոր կրկնօրինակների համար: Խառը թարմացման մակարդակները կարող են անսպասելի վարքագիծ առաջացնել ձախողման ժամանակ:
Կարգավորեք կլաստերի արագության երթևեկության համար նվիրված ցանցային ինտերֆեյսներ՝ առանձին հավելվածի երթևեկությունից։
Միացնել ավտոմատ սերմնավորումը նախնական տվյալների բազայի համաժամեցման համար SQL Server 2016 և ավելի ուշ՝ այն վերացնում է պահուստային պատճենները երկրորդական կրկնօրինակների վրա ձեռքով պատճենելու անհրաժեշտությունը m-ի համար։ost սցենարները:
AG + FCI տոպոլոգիաների համար, FCI հանգույցի յուրաքանչյուր կոնֆիգուրացիայի փոփոխությունից հետո ստուգեք, որ ոչ մի WSFC հանգույց չի կարող հայտնվել h-ում։ostնույն հասանելիության խմբի երկու կրկնօրինակների ստեղծումը։
Միշտ օգտագործեք SQL Server Management Studio-ն կամ Transact-SQL-ը՝ մատչելիության խմբի ձախողումները կառավարելու համար. երբեք անմիջապես չօգտագործեք Failover Cluster Manager-ը, քանի որ այն տեղյակ չէ AG համաժամացման վիճակի մասին և կարող է հանգեցնել երկարատև դադարների կամ տվյալների կորստի:

6.3 Մոնիտորինգ և սպասարկում

Հետևեք համաժամեցման վիճակին, ուղարկեք հերթը և կրկնեք հերթը պարբերաբար՝ օգտագործելով հասանելիության խմբի վահանակը SQL Server Management Studio կամ Dynamic Management Views (DMV): Երկրորդային միացման վրա կրկնության հերթի աճը ցույց է տալիս I/O խցանում, որը կհետաձգի ձախողման վերականգնումը:
Գործարկեք DBCC CHECKDB-ը երկրորդական կրկնօրինակների վրա՝ ամբողջականության ստուգումները հիմնականից բեռնաթափելու համար: Տես մեր DBCC CHECKDB ուղեցույց Մանրամասների համար դիմեք
Դիմել SQL Server Թարմացումներ՝ օգտագործելով շարունակական թարմացումներ. նախ թարմացրեք երկրորդային կրկնօրինակները, կատարեք պլանավորված ձեռքով անցում թարմացված երկրորդայինին, ապա թարմացրեք նախկին առաջնայինը: Սա սահմանափակում է անսարքության ժամանակը մեկ անցումային տարբերակի տևողությամբ:
Պարբերաբար փորձարկեք ձախողման գործընթացը ոչ արտադրական միջավայրերում: Ավտոմատ ձախողման գործընթացը, որը երբեք չի փորձարկվել, հուսալի վերականգնման ռազմավարություն չէ:
Կարգավորեք հասանելիության խմբի առողջական վիճակի փոփոխությունների, կրկնօրինակների դերերի անցումների և համաժամացման ձախողումների վերաբերյալ ծանուցումները՝ օգտագործելով SQL Server Գործակալ կամ նվիրված մոնիթորինգի գործիք, ինչպիսին է SQL Server Performance Monitor- ը.

7. ՀՏՀ

Հ. Ինչ է SQL Server Միշտ միացված՞ է։

A: SQL Server Always On-ը Microsoft-ի բարձր մատչելիության և աղետներից վերականգնման հարթակն է, որը ներկայացվել է 2009 թվականին։ SQL Server 2012թ.: Այն ներառում է երկու տեխնոլոգիա՝ Always On Availability Groups և Always On Failover Cluster Instances, որոնք ապահովում են ավտոմատացված failover, տվյալների ավելորդություն և տվյալների բազաներին անընդհատ մուտք՝ սարքավորումների, ծրագրային ապահովման կամ կայքի խափանումների դեպքում:

Հարց. Ի՞նչ տարբերություն կա «Միշտ հասանելի խմբերի» և «Անհաջող կլաստերային դեպքերի» միջև:

Հ. Հասանելիության խմբերը գործում են տվյալների բազայի մակարդակում, կրկնօրինակում են տվյալները անկախ երկրորդական կրկնօրինակների վրա՝ գրանցամատյանների առաքման միջոցով, և չեն պահանջում համատեղ պահեստավորում: Failover Cluster Instances-ները գործում են Instance մակարդակում, պահանջում են համատեղ պահեստավորում, որը հասանելի է բոլոր հանգույցների կողմից, և ձախողվում են բոլոր տվյալների բազաների վրա՝ որպես մեկ միավոր: AG-ն աջակցում է ընթեռնելի երկրորդականներին և ներկառուցված DR-ին, իսկ FCI-ն՝ ոչ:

Հարց. Արդյո՞ք ինձ անհրաժեշտ է համատեղ պահեստ «Միշտ հասանելի» խմբերի համար:

Ա. Ոչ: Յուրաքանչյուր AG կրկնօրինակ պահպանում է տվյալների բազաների իր սեփական անկախ պատճենը տեղական պահեստում: Համատեղ պահեստը պահանջվում է միայն այն դեպքում, եթե դուք օգտագործում եք Failover Cluster Instances՝ h-ի համար:ost AG կրկնօրինակներ։

Հարց. Կարո՞ղ եմ օգտագործել Always On-ը «Միշտ միացված» ռեժիմի հետ SQL Server Ստանդարտ տարբերակ՞

A: SQL Server Ստանդարտ հրատարակությունը աջակցում է հիմնական հասանելիության խմբերինtarզնգալ SQL Server 2016թ., սակայն էական սահմանափակումներով՝ մեկ տվյալների բազա յուրաքանչյուր AG-ի համար, առավելագույնը երկու կրկնօրինակ և ընթեռնելի երկրորդական աջակցության բացակայություն: FCI-ն հասանելի է Standard Edition-ում առանց այս սահմանափակումների: Always On լիարժեք ֆունկցիոնալության համար անհրաժեշտ է Enterprise Edition-ը:

Հարց. Որքա՞ն է առկայություն ունեցող խմբում կրկնօրինակների առավելագույն քանակը։

A: SQL Server Enterprise Edition-ը աջակցում է մինչև ինը կրկնօրինակ՝ մեկ հիմնական և ութ երկրորդական: Բաշխված հասանելիության խմբերը կարող են ընդլայնել այս թիվը մինչև 18 կրկնօրինակ՝ երկու առանձին հասանելիության խմբերում:

Հարց. Կարո՞ղ է FCI-h-ըostխմբագրված կրկնօրինակները օգտագործո՞ւմ են ավտոմատ AG failover:

Ա. Ոչ։ Երբ մատչելիության կրկնօրինակը h էosted-ի վրա Failover Cluster Instance, ավտոմատ հասանելիության խմբի failover-ը չի աջակցվում այդ կրկնօրինակի համար: FCI-h-ով ներառող բոլոր AG failover-ներըostխմբագրված կրկնօրինակները պահանջում են ձեռքով միջամտություն։

Հարց. Ի՞նչ տարբերություն կա սինխրոն և ասինխրոն կատարողական ռեժիմների միջև։

Ա. Սինխրոն հաստատման ռեժիմը պահանջում է, որ առաջնայինը սպասի, մինչև երկրորդայինը ամրացնի գրանցամատյանների գրառումները՝ հաստատումից առաջ, ապահովելով տվյալների զրոյական կորուստ (RPO = 0) c-ում։ost Ավելացված գրման լատենտության։ Ասինխրոն հաստատման ռեժիմը թույլ է տալիս առաջնայինին հաստատում կատարել առանց սպասելու, նվազեցնելով լատենտությունը, բայց վտանգելով տվյալների կորուստը, եթե առաջնայինը ձախողվի մինչև երկրորդայինը ստանա բոլոր գրանցամատյանի գրառումները։ Օգտագործեք սինխրոն տեղական HA կրկնօրինակների համար և ասինխրոն հեռավոր DR կրկնօրինակների համար։

Հարց. Որքա՞ն ժամանակ է պահանջվում SQL Server Միշտ միացված է ձախողման վերցմանը՞

Ա. Սինխրոն AG կրկնօրինակի ավտոմատ անցումը սովորաբար ավարտվում է 30 վայրկյանից պակաս ժամանակում՝ նորմալ պայմաններում: FCI անցումը սովորաբար տևում է 20-60 վայրկյան՝ կախված տվյալների բազայի վերականգնման ժամանակից: Իրական տևողությունը կախված է աշխատանքային ծանրաբեռնվածությունից, տվյալների բազայի չափից և WSFC-ում կարգավորված առողջության ստուգման ժամանակի ավարտի կարգավորումներից:

Հարց. Ի՞նչ է պատահում հաճախորդի միացումներին ձախողման ժամանակ:

Ա. Առկա կապերը ընդհատվում են, երբ տեղի է ունենում անհաջող միացում: Անհաջող միացման ավարտից հետո հասանելիության խմբի լսողն օգտագործող և կապի վերստուգման տրամաբանություն ներառող ծրագրերը ավտոմատ կերպով վերամիավորվում են նոր հիմնական խմբի հետ: MultiSubnetFailover=True-ի ավելացումը կապի տողերին բարելավում է վերամիացման արագությունը բազմաենթացանցային տեղակայումներում:

Հարց. Ինչպե՞ս դիմել SQL Server Միշտ միացված միջավայրում նվազագույն դադարի ժամանակով թարմացումներ;

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

Հարց. Կարո՞ղ եմ համատեղել «Միշտ միացված մատչելիության խմբերը» Failover կլաստերային օրինակների հետ:

Ա. Այո։ Դուք կարող եքost AG կրկնօրինակներ FCI օրինակների վրա՝ ինչպես օրինակի մակարդակի, այնպես էլ տվյալների բազայի մակարդակի ձախողման պաշտպանություն ապահովելու համար: Յուրաքանչյուր FCI հաշվվում է որպես մեկ AG կրկնօրինակ: Այս տոպոլոգիան պահանջում է WSFC հանգույցի ուշադիր պլանավորում՝ ապահովելու համար, որ մեկ հանգույց h չլինի:ostՆույն AG-ի երկու կրկնօրինակներ՝ FCI-ի ցանկացած հնարավոր ձախողումից հետո։

Հարց. Ի՞նչ պետք է անեմ, եթե իմ տվյալների բազան վնասվի «Միշտ միացված» միջավայրում:

Ա. Նախ, ստուգեք, թե արդյոք վնասը առկա է բոլոր կրկնօրինակների վրա, թե՞ միայն հիմնականի վրա: Եթե առկա է առողջ երկրորդային, անմիջապես անցեք դրան: Բոլոր կրկնօրինակների վնասման դեպքում վերականգնեք մաքուր պահուստային պատճենից: Պարբերաբար գործարկեք DBCC CHECKDB-ը երկրորդային կրկնօրինակների վրա՝ վնասը վաղ հայտնաբերելու համար: Եթե պահուստային պատճենները նույնպես տուժել են, մասնագիտացված SQL Server տվյալների վերականգման գործիք կարող է փորձել տվյալներ հանել վնասված MDF ֆայլերից որպես վերջին միջոց։

Հարց. Ինչպե՞ս է «Միշտ հասանելի» խմբերը համեմատվում ավելի հին խմբերի հետ։ SQL Server ՀԱ լուծումներ՞

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

8: եզրափակում

SQL Server Always On-ը ապահովում է ճկուն, ձեռնարկության մակարդակի հարթակ՝ բարձր մատչելիության և աղետների վերականգնման համար: Always On Availability Groups-ը ճիշտ ընտրություն է մ...ost ժամանակակից տեղակայումներ. այն վերացնում է համատեղ պահեստավորման անհրաժեշտությունը, աջակցում է ընթեռնելի երկրորդականներին և մեկ կոնֆիգուրացիայում կառավարում է ինչպես տեղական HA-ն, այնպես էլ միջկայքային DR-ը: Failover կլաստերային օրինակները մնում են հուսալի տարբերակ, երբ օրինակի մակարդակի failover-ը և առկա համատեղ պահեստավորման ենթակառուցվածքը հիմնական պահանջներն են: Երկու տեխնոլոգիաների համադրությունը ապահովում է առկա ամենախորը պաշտպանությունը՝ c-ում:ost ավելի մեծ ենթակառուցվածքային ներդրումների և շահագործման բարդության պատճառով։

Անկախ նրանից, թե որ լուծումն եք ընտրում, հիմունքները նույնն են. նախ սահմանեք ձեր RTO և RPO պահանջները, նախագծեք ձեր տոպոլոգիան դրանց շուրջ։ tarստանում է և պարբերաբար ստուգում է ձախողման գործընթացը: Լավ իրականացված Always On լուծումը, որը մանրակրկիտ փորձարկվել է, կանխատեսելիորեն կվերականգնվի, երբ արտադրական խափանումներ տեղի ունենան:

Հեղինակի մասին

Յուան Շենգ տվյալների բազայի ավագ ադմինիստրատոր (DBA) է՝ ավելի քան 10 տարվա փորձով։ SQL Server միջավայրերի և ձեռնարկությունների տվյալների բազայի կառավարման ոլորտում: Նա հաջողությամբ լուծել է տվյալների բազայի վերականգնման հարյուրավոր սցենարներ ֆինանսական ծառայությունների, առողջապահության և արտադրական կազմակերպություններում:

Յուանը մասնագիտանում է SQL Server տվյալների բազայի վերականգնում, բարձր մատչելիության լուծումներ և կատարողականի օպտիմալացում: Նրա լայնածավալ գործնական փորձը ներառում է բազմաբայթ ծավալով տվյալների բազաների կառավարում, միշտ հասանելի խմբերի ներդրում և կարևորագույն բիզնես համակարգերի համար ավտոմատացված պահուստավորման և վերականգնման ռազմավարությունների մշակում:

Իր տեխնիկական փորձագիտության և գործնական մոտեցման միջոցով Յուանը կենտրոնանում է համապարփակ ուղեցույցներ ստեղծելու վրա, որոնք կօգնեն տվյալների բազայի ադմինիստրատորներին և ՏՏ մասնագետներին լուծել բարդ խնդիրներ։ SQL Server արդյունավետորեն մարտահրավերներ է նետում։ Նա տեղեկացված է մնում վերջին նորություններից SQL Server թողարկումները և Microsoft-ի զարգացող տվյալների բազայի տեխնոլոգիաները, պարբերաբար փորձարկելով վերականգնման սցենարները՝ համոզվելու համար, որ նրա առաջարկությունները արտացոլում են իրական աշխարհի լավագույն փորձը։

Հարցեր ունեք SQL Server Վերականգնո՞ւմ, թե՞ անհրաժեշտ է տվյալների բազայի խնդիրների լուծման լրացուցիչ ուղեցույց: Յուանը ողջունում է ձեզ: արձագանքներ և առաջարկություններ այս տեխնիկական ռեսուրսները բարելավելու համար։