Агенти за репликация 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. Слушателят, защитната стена и 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, за да видите как агентът се възстановява. Абонамент, който издържа този тест, има разположение, което можете да документирате и защитите.