Агенти реплікації 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, щоб побачити, як агент відновлюється. Передплата, яка переживає цю перевірку, має розміщення, яке можна задокументувати й захистити.