Агенты рэплікацыі 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, каб убачыць, як агент аднаўляецца. Падпіска, якая перажывае гэты тэст, мае размяшчэнне, якое можна задокументаваць і абараніць.