سائٹ 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 کی طرف کنکشن کھولتا ہے۔ سبسکرائبر کی طرف سننے والا، فائر وال اور 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 تعطل کے دوران یہ ایک بار پھر کریں۔ جو سبسکرپشن وہ امتحان برداشت کر لے اس کا ایسا مقام ہے جسے آپ دستاویز کر سکتے ہیں اور بچا سکتے ہیں۔