Saytlar orasidagi VPN orqali push va pull replikatsiya agentlari

Agentning joylashuvi, ma’lumotlarning joylashuvi emas, SQL Server obunasini shakllantiradigan qaror. Agentni ishga tushiruvchi mashina ulanishni ochadi, muayyan hisob ostida ishlaydi va sinxronizatsiya to’xtaganda aybni o’z zimmasiga oladi. Saytlar orasidagi VPN da bu farq loyihalashning o’zi, mayda-chuyda emas. Tarmoqni chizishdan oldin agent ulanishlarini chizing.

Uch rol, ikkita emas

Publisher maqola ma’lumotlariga ega, Distributor tarqatish ma’lumotlar bazasiga ega, Subscriber esa o’zgarishlarni qabul qiladi. Log Reader Agent tranzaksiyaviy replikatsiya uchun Distributor da ishlaydi. Distribution Agent obuna turi bilan joyi o’zgaradigan agent bo’lib, shuning uchun u tarmoq loyihasini belgilaydi. VPN qoidalari haqida gapirishdan oldin bu rollarni aniqlang.

push obunasi Distribution Agent ni Distributor da ishga tushiradi, pull obunasi esa uni Subscriber da ishga tushiradi, Microsoft ning obunalar hujjati aytganidek. Tarmoq suhbatidagi hamma narsa bu qaysi mashina ekanligidan kelib chiqadi. Har bir obuna uchun to’rt fakt yozing: agentning xosti, uning jarayon identifikatori, ishlatadigan ma’lumotlar bazasi kirishlari va yetib borishi kerak bo’lgan resurslar. Diagrammadagi strelka emas, bu faktlar qaysi yo’nalish ishlashi kerakligini aytadi.

push agentning Distributor da yashashini bildiradi

push obunasida Distributor VPN orqali Subscriber tomon ulanish ochadi. Abonent tomonidagi tinglovchi, firewall va SQL kirish uzoq tomondan keladigan ulanishlarni qabul qilishi kerak. Distributor ning xizmat hisobiga ham abonent ma’lumotlar bazasida ruxsat kerak. Bu kirish yo’lini obuna yaratishdan oldin rejalashtiring, chunki uni keyin topish odatda qaytadan yaratishni bildiradi.

Snapshot yetkazib berish barqaror replikatsiya hech qachon ishlatmaydigan yo’lni qo’shadi. Agar snapshot fayl almashinuvida joylashgan bo’lsa, Distribution Agent o’sha almashinuvdan o’qiydi va abonent hisobi o’sha UNC yo’liga yetib borishi kerak. Haftalab davom etadigan o’zgarishlar oqimi qayta ishga tushirish ishlaydimi-yo’qmi haqida hech narsa aytmaydi. Shuning uchun snapshot almashinuvi boshidan rejada bo’lishi kerak.

push ni bir tomonlama trafik deb o’qimang. Agentga javoblar, tasdiqlar va o’zining autentifikatsiya almashinuvlari kerak. Ma’lumotlar bir yo’nalishda harakatlansa ham yo’l ulanish darajasida ikki tomonlama bo’lishi kerak.

pull agentning Subscriber da yashashini bildiradi

pull obunasi ulanishni teskari aylantiradi: Subscriber o’zi Distribution Agent ni ishga tushirib, Distributor ga murojaat qiladi. Bu tartib filialdan chiqadigan ulanishlarga ruxsat berib, kiradiganlarini bloklaydigan VPN siyosatiga mos keladi. Shuningdek jadval qarorini filial serveriga qaraydigan kishining qo’liga beradi. Filial jamoasi o’z sinxronizatsiyasiga ega bo’lishi va o’z muvaffaqiyatsizliklarini payqashi kerak bo’lganda uni tanlang.

Abonentning SQL Server Agent xizmat hisobiga tarqatish ma’lumotlar bazasiga va snapshot almashinuviga o’qish huquqi kerak. O’sha hisob replikatsiya xatolarida ko’rinadigan identifikatordir, domen huquqlari bo’lmagan mahalliy xizmat hisobi esa tarmoq nosozligiga o’xshab ko’rinadigan, lekin aslida ishonch ma’lumotlari nosozligi bo’lgan nuqtada muvaffaqiyatsizlikka uchraydi. Tunnelni tuzatishdan oldin hisobni tekshiring. Kirishni to’g’rilash odatda tarmoqning begunohligini isbotlashdan tezroq.

Egalik agentga ergashadi. Markaziy jamoa jadvalni ham, muvaffaqiyatsizliklarni ham egallashi kerak bo’lganda push tanlang. Nima tanlasangiz ham, keyingi muhandis birinchi qayerga qarashini bilishi uchun uni obuna yoniga yozing.

Qayta chop etish tarqalishni o’zgartiradi, egalikni emas

Abonentni keyingi abonentlarga qayta chop etish uchun sozlash mumkin, bu esa bitta filial ma’lumotlar bazasiga bir necha mahalliy iste’molchiga xizmat ko’rsatish imkonini beradi, har biri WAN orqali tortmasdan. O’rta ma’lumotlar bazasi endi nashr va o’z agentlarini saqlaydi. Shuningdek u ilgari bo’lmagan ruxsatlar, monitoring va tiklash rejasini meros oladi. Bu qo’shimcha rol takrorlanadigan WAN yetkazib berishni olib tashlashning narxidir.

Hujjatlashtirilgan tartib muhim: quyi nashrni yaratishdan oldin kiruvchi obunani ishga tushiring. Bunga o’tkazib yuboriladigan qog’ozbozlik emas, tekshiruvli hayot sikli bosqichi sifatida qarang. Uni teskari aylantirish sozlangan ko’rinadigan, lekin hech narsa yetkazmaydigan zanjir yaratadi.

Yozish modelini aniq ayting. Faqat o’qish uchun ma’lumotlar to’plamini mahalliy iste’molchiga replikatsiya qilish bir necha saytda yozuvlarni qabul qilishdan boshqa loyiha, strelkalar zanjiri esa ziddiyat hal qilishni yaratmaydi. Agar filial yozishi kerak bo’lsa, bu o’z topologiyasiga ega alohida qaror. Bog’liqlikni ham ko’rinadigan qiling: qayta chop etuvchi to’xtaganda, uning ostidagi har bir iste’molchi eskirgan bo’ladi.

Joylashuvni boshidan oxirigacha isbotlang

Xotiraga ishonish o’rniga tarqatish ma’lumotlar bazasidan obuna turini o’qing, so’ng o’zgarishlar haqiqatan yetib borishini tekshiring:

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 qiymati 0 bo’lsa push, 1 bo’lsa pull bo’ladi va uni joyida o’zgartirib bo’lmaydi, shuning uchun mos kelmaslik obunani tahrirlashni emas, qayta yaratishni bildiradi. Kutayotgan buyruqlar chaqiruvi tanlangan agent ishni ko’chiryaptimi yoki shunchaki ishlayaptimi, deb aytadi. Abonent jadvali bo’sh qolayotganda nol kutayotgan buyruq haqida xabar beradigan obuna o’sib borayotgan kechikish haqida xabar beradiganidan boshqa nosozlik, va ikkalasi turli egalarga olib boradi.

Haqiqiy o’zgarish bilan yakunlang: Publisher da bitta qatorni kiriting yoki yangilang, agent hisobotini kuting va o’sha qatorni Subscriber da o’qing. Agent qanday tiklanayotganini ko’rish uchun qisqa VPN uzilishi paytida buni yana bir marta qiling. Bu sinovdan o’tgan obunaning hujjatlashtirib, himoya qila oladigan joylashuvi bor.