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-ის ხანმოკლე შეწყვეტის დროს, რათა ნახოთ როგორ აღდგება აგენტი. გამოწერას, რომელიც ამ გამოცდას გაუძლებს, აქვს განლაგება, რომლის დოკუმენტირებაც და დაცვაც შეგიძლიათ.