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 за да видите како агентот се обновува. Претплата што го преживува тој тест има распоредување што можете да го документирате и одбраните.