সাইট-থেকে-সাইট 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 ব্যাঘাতের মধ্য দিয়ে আরেকবার এটি করুন, দেখুন এজেন্ট কীভাবে সেরে ওঠে। যে সাবস্ক্রিপশন সেই পরীক্ষা টিকে যায় তার এমন একটি স্থাপনা আছে যা আপনি নথিবদ্ধ করে রক্ষা করতে পারেন।