Push և pull ռեպլիկացիայի գործակալներ կայքերի միջև VPN-ով

Գործակալի տեղը, ոչ թե տվյալների տեղը, այն որոշումն է, որը ձևավորում է SQL Server-ի բաժանորդագրությունը։ Մեքենան, որը վարում է գործակալին, բացում է կապը, աշխատում է որոշակի հաշվի ներքո և պատասխանատվություն է կրում, երբ սինխրոնացումը կանգ է առնում։ Կայքերի միջև VPN-ում այդ տարբերությունը հենց ձևավորումն է, ոչ թե մանրուք։ Գծեք գործակալի կապերը նախքան ցանցը գծելը։

Երեք դեր, ոչ թե երկու

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

push բաժանորդագրությունը Distribution Agent-ին վարում է Distributor-ում, իսկ pull բաժանորդագրությունը՝ Subscriber-ում, ինչպես նշված է Microsoft-ի բաժանորդագրությունների փաստաթղթերում։ Ամեն ինչ ցանցային զրույցում բխում է նրանից, թե որ մեքենան է դա։ Յուրաքանչյուր բաժանորդագրության համար գրեք չորս փաստ՝ գործակալի հոսթը, նրա գործընթացի ինքնությունը, օգտագործվող տվյալների բազայի մուտքերը և այն ռեսուրսները, որոնց նա պետք է հասնի։ Այդ փաստերը, ոչ թե գծապատկերի սլաքը, ասում են, թե որ ուղղությունը պետք է աշխատի։

push նշանակում է, որ գործակալը ապրում է Distributor-ում

push բաժանորդագրության դեպքում Distributor-ը բացում է կապը Subscriber-ի հետ VPN-ով։ Բաժանորդի կողմի լսողը, firewall-ը և SQL մուտքը պետք է ընդունեն հեռավոր կողմից եկող կապերը։ Distributor-ի սպասարկման հաշվին նույնպես թույլտվություն է պետք բաժանորդի տվյալների բազայում։ Պլանավորեք այդ մուտքային ուղին նախքան բաժանորդագրությունը ստեղծելը, որովհետև այն ավելի ուշ հայտնաբերելը սովորաբար նշանակում է վերստեղծել այն։

Պատկերի առաքումը ավելացնում է մի ուղի, որը կայուն ռեպլիկացիան երբեք չի օգտագործում։ Եթե պատկերը տեղադրված է ֆայլային համօգտագործման վրա, Distribution Agent-ը կարդում է այդ համօգտագործումից, և բաժանորդի հաշիվը պետք է հասնի նույն UNC ուղուն։ Շաբաթներ տևող փոփոխությունների հոսքը ոչինչ չի ասում այն մասին, թե արդյոք կրկնակի սկզբնավորումը կաշխատի։ Այդ պատճառով պատկերի համօգտագործումը պլանի մեջ է հենց սկզբից։

Մի՛ կարդացեք push-ը որպես միակողմանի երթևեկություն։ Գործակալին պետք են պատասխաններ, հաստատումներ և իր իսկ նույնականացման փոխանակումները։ Ուղին պետք է լինի երկկողմանի կապի մակարդակում, նույնիսկ երբ տվյալները շարժվում են մեկ ուղղությամբ։

pull նշանակում է, որ գործակալը ապրում է Subscriber-ում

pull բաժանորդագրությունը շրջում է կապը՝ Subscriber-ը վարում է Distribution Agent-ին և դիմում է Distributor-ին։ Այդ դասավորությունը հարմար է VPN քաղաքականությանը, որը թույլատրում է մասնաճյուղից ելքային կապերը և արգելափակում մուտքայինները։ Այն նաև ժամանակացույցի որոշումը դնում է նրա ձեռքը, ով հոգ է տանում մասնաճյուղի սերվերի մասին։ Ընտրեք այն, երբ մասնաճյուղի թիմը պետք է տիրապետի սեփական սինխրոնացմանը և նկատի սեփական ձախողումները։

Բաժանորդի SQL Server Agent սպասարկման հաշվին անհրաժեշտ է ընթերցման հասանելիություն բաշխման տվյալների բազային և պատկերի համօգտագործմանը։ Այդ հաշիվն այն ինքնությունն է, որը հայտնվում է ռեպլիկացիայի սխալներում, և տիրույթի իրավունքներ չունեցող տեղական սպասարկման հաշիվը ձախողվում է մի կետում, որը նման է ցանցի խափանման, բայց իրականում հավատարմագրերի խափանում է։ Ստուգեք հաշիվը նախքան թունելը վրիպազերծելը։ Մուտքը ուղղելը սովորաբար ավելի արագ է, քան ցանցի անմեղությունը ապացուցելը։

Սեփականությունը հետևում է գործակալին։ Ընտրեք push, երբ կենտրոնական թիմը պետք է տիրապետի և՛ ժամանակացույցին, և՛ ձախողումներին։ Ինչ էլ ընտրեք, գրեք այն բաժանորդագրության կողքին, որպեսզի հաջորդ ինժեները իմանա՝ որտեղ նայել նախ։

Վերսհրապարակումը փոխում է ճյուղավորումը, ոչ թե սեփականությունը

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

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

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

Ապացուցեք տեղադրումը սկզբից մինչև վերջ

Կարդացեք բաժանորդագրության տեսակը բաշխման տվյալների բազայից՝ հիշողությանը վստահելու փոխարեն, ապա ստուգեք, որ փոփոխություններն իսկապես հասնում են՝

USE distribution;
SELECT publication, subscriber_db, subscription_type
FROM dbo.MSsubscriptions;
EXEC sp_replmonitorsubscriptionpendingcmds
  @publisher = 'PUB1', @publisher_db = 'Sales',
  @publication = 'SalesPub', @subscriber = 'BR1',
  @subscriber_db = 'Sales';

subscription_type-ի 0 արժեքը push է, իսկ 1-ը՝ pull, և այն տեղում հնարավոր չէ փոխել, ուստի անհամապատասխանությունը նշանակում է բաժանորդագրության վերստեղծում, ոչ թե խմբագրում։ Սպասվող հրամանների կանչը ձեզ ասում է՝ ընտրված գործակալը աշխատանք է տեղափոխում, թե պարզապես աշխատում է։ Այն բաժանորդագրությունը, որը հաղորդում է զրո սպասվող հրաման, մինչ բաժանորդի աղյուսակը մնում է դատարկ, տարբեր խափանում է, քան աճող հերթ հաղորդողը, և երկուսը տանում են տարբեր սեփականատերերի։

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