د push او pull د تکرار ایجنټونه د سایټونو ترمنځ VPN باندې
د ګډون د ایجنټ ځای ټاکي چې کومه ماشین د VPN له لارې اړیکې پرانیزي۔ push یا pull د دې پر بنسټ وټاکئ چې کار څوک لري، نه د انځور د غشو له مخې۔
د ایجنټ ځای، نه د معلوماتو ځای، هغه پرېکړه ده چې د SQL Server ګډون جوړوي۔ هغه ماشین چې ایجنټ چلوي اړیکه پرانیزي، تر یو ځانګړي حساب لاندې کار کوي او کله چې همغږي ودرېږي تور په ځان اخلي۔ د سایټونو ترمنځ VPN کې هغه توپیر خپله ډیزاین دی، نه جزئیات۔ د شبکې له رسمولو دمخه د ایجنټ اړیکې رسم کړئ۔
درې رولونه، نه دوه
Publisher د مقالې معلومات لري، Distributor د وېش ډیټابیس لري، او Subscriber بدلونونه ترلاسه کوي۔ Log Reader Agent د معاملوي تکرار لپاره په Distributor کې چلیږي۔ Distribution Agent هغه دی چې ځای یې د ګډون له ډول سره بدلیږي، او له همدې امله د شبکې ډیزاین ټاکي۔ د VPN قواعدو په اړه له خبرو دمخه دا رولونه روښانه کړئ۔
push ګډون Distribution Agent په Distributor کې چلوي، او pull ګډون هغه په Subscriber کې چلوي، لکه څنګه چې د Microsoft د ګډون اسناد وایي۔ په شبکهیي خبرو کې هر څه له دې څخه راځي چې کومه ماشین دی۔ د هر ګډون لپاره څلور حقایق ولیکئ: د ایجنټ کوربه، د بهیر پېژندنه، هغه ډیټابیس ننوتنې چې کاروي او هغه سرچینې چې باید ورته ورسیږي۔ د انځور غشه نه، دا حقایق وایي چې کوم لوری باید کار وکړي۔
push مانا دا ده چې ایجنټ په Distributor کې اوسیږي
په push ګډون کې Distributor د VPN له لارې Subscriber ته اړیکه پرانیزي۔ د ګډونوونکي خوا اورېدونکی، 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 وقفې په جریان کې یو ځل بیا وکړئ۔ هغه ګډون چې دغه ازموینه تېروي، داسې ځای لري چې تاسو یې مستند او دفاع کولی شئ۔