Агенты репликации push и pull через VPN между площадками

Расположение агента, а не расположение данных, — это решение, которое формирует подписку SQL Server. Машина, запускающая агента, открывает соединение, работает под определённой учётной записью и берёт на себя вину, когда синхронизация останавливается. В VPN между площадками это различие и есть проектирование, а не деталь. Нарисуйте соединения агента прежде, чем рисовать сеть.

Три роли, а не две

Publisher владеет данными статьи, Distributor владеет базой данных распространителя, а Subscriber получает изменения. Log Reader Agent работает на Distributor для транзакционной репликации. Distribution Agent — тот, чьё расположение меняется с типом подписки, и поэтому именно он определяет проектирование сети. Разберитесь с этими ролями, прежде чем говорить о правилах VPN.

Подписка push запускает Distribution Agent на Distributor, а подписка pull запускает его на Subscriber, как указывает документация по подпискам Майкрософт. Всё в сетевом разговоре следует из того, какая это машина. Запишите четыре факта для каждой подписки: хост агента, его идентичность процесса, используемые входы в базу данных и ресурсы, до которых он должен добраться. Эти факты, а не стрелка на схеме, говорят, какое направление должно работать.

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