సైట్ 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 అంతరాయం మీద దీన్ని మరోసారి చేయండి. ఆ పరీక్షను దాటిన సబ్స్క్రిప్షన్కు మీరు పత్రబద్ధం చేసి రక్షించగలిగే స్థానం ఉంటుంది.