عامل‌های تکرار push و pull از طریق VPN بین سایت‌ها

محل عامل، نه محل داده، تصمیمی است که شکل یک اشتراک SQL Server را می‌سازد. ماشینی که عامل را اجرا می‌کند اتصال را باز می‌کند، با حسابی مشخص کار می‌کند و وقتی همگام‌سازی متوقف شود بار سرزنش را برمی‌دارد. در VPN بین سایت‌ها این تفاوت خودِ طراحی است، نه یک جزئیات. پیش از رسم شبکه، اتصال‌های عامل را رسم کنید.

سه نقش، نه دو نقش

Publisher مالک داده‌های مقاله است، Distributor مالک پایگاه داده توزیع است و Subscriber تغییرات را دریافت می‌کند. Log Reader Agent برای تکرار تراکنشی روی Distributor اجرا می‌شود. Distribution Agent همان عاملی است که محلش با نوع اشتراک تغییر می‌کند، و به همین دلیل طراحی شبکه را تعیین می‌کند. پیش از صحبت درباره قواعد VPN این نقش‌ها را روشن کنید.

اشتراک push عامل توزیع را روی Distributor اجرا می‌کند و اشتراک pull آن را روی Subscriber اجرا می‌کند، همان‌طور که مستندات اشتراک مایکروسافت می‌گوید. همه چیز در گفت‌وگوی شبکه از این ناشی می‌شود که آن ماشین کدام است. برای هر اشتراک چهار واقعیت را بنویسید: میزبان عامل، هویت فرآیند آن، ورودهای پایگاه داده‌ای که استفاده می‌کند و منابعی که باید به آن‌ها برسد. این واقعیت‌ها، نه فلش نمودار، می‌گویند کدام جهت باید کار کند.

push یعنی عامل روی Distributor زندگی می‌کند

در اشتراک push، Distributor اتصال به Subscriber را از طریق VPN باز می‌کند. شنونده، دیوار آتش و ورود SQL در سمت مشترک باید اتصال‌های رسیده از سمت دور را بپذیرند. حساب سرویس Distributor هم به مجوز روی پایگاه داده مشترک نیاز دارد. این مسیر ورودی را پیش از ساخت اشتراک برنامه‌ریزی کنید، چون کشف آن بعداً معمولاً به معنای بازساختن آن است.

تحویل عکس فوری مسیری را اضافه می‌کند که تکرار پایدار هرگز از آن استفاده نمی‌کند. اگر عکس فوری روی اشتراک فایل قرار گرفته باشد، Distribution Agent از همان اشتراک می‌خواند و حساب مشترک باید به همان مسیر UNC برسد. جریانی از تغییرات که هفته‌ها ادامه دارد هیچ چیزی درباره کارکرد بازآغازسازی نمی‌گوید. به همین دلیل اشتراک فایل عکس فوری از همان ابتدا در طرح جای دارد.

push را ترافیک یک‌طرفه نخوانید. عامل به پاسخ‌ها، تأییدها و تبادل‌های احراز هویت خودش نیاز دارد. مسیر باید در سطح اتصال دوسویه باشد حتی وقتی داده در یک جهت حرکت می‌کند.

pull یعنی عامل روی Subscriber زندگی می‌کند

اشتراک pull اتصال را برمی‌گرداند: Subscriber عامل توزیع را اجرا می‌کند و به 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 تکرار کنید تا ببینید عامل چگونه بازیابی می‌شود. اشتراکی که از این آزمون جان سالم به در ببرد جای‌گیری‌ای دارد که می‌توانید مستند و دفاع کنید.