مریم حیات رمضانی
کارشناس شبکه های مایکروسافت و پایگاه داده

آموزش راه اندازی Replication در SQL Server + انواع Replication

چند نوع Replication در SQL سرور وجود دارد؟ چگونه SQL Replication را راه اندازی کنیم؟ در این مقاله قصد داریم عمل Replication در SQL Server  را مورد بحث قرار دهیم .قطعا افرادی که علاقه مند به مطالعه ی این مطلب هستند ، آشنایی کلی با محیط SQL دارند اما در اینجا سعی بر این است تا دوستان در ابتدا با مفهوم هر کدام از اصطلاحاتی که در این مطلب به کار گرفته شده، آشنایی پیدا کنند تا به هنگام مطالعه دچار ابهام نشوند . لذا دراین مقاله به تعریف مفاهیم Replication در SQL سرور پرداخته خواهد شد:

دوره های شبکه، برنامه نویسی، مجازی سازی، امنیت، نفوذ و ... با برترین های ایران

عمل Replication یکی از ویژگی های سطح بالای SQL Server محسوب می شود .Replication متقابل هنگامی استفاده می شود که تغییرات شمای DML یا DDL اجرا شده روی یک شی موجود در دیتابیس یک سرور نیازمند منعکس شدن بر روی پایگاه داده ی موجود بر روی سرور دیگر نیز باشد. این تغییرات تقریبا در یک بازه ی زمانی Real مثلا در ثانیه اتفاق می افتند. پس از بیان فنی ، حال به زبانی ساده و در قالب مثال به توضیح Replication می پردازیم :

همانطور که می دانیم افراد بسیاری وجود دارند که مشترک مجلات الکترونیکی بوده و یا اخبار روز جهان را از طریق ایمیل خود دریافت می کنند .بنابراین با عضویت و مشترک شدن در این مجلات و mailer ها به سادگی قادر به دریافت اخبار روز و مورد نظر خود هستند. بطور مشابه قابلیت Replication در MS SQL نیز همین نقش را ایفا کرده و داده ها را به عنوان مثال از یک سرور ریموت به Box های سرورهای لوکال از طریق مکانیزم نشرو اشتراک گذاری (publications and subscriptions) انتقال می دهد.

Replication در واقع به مجموعه ای از توپولوژی ها برای کپی و توزیع داده ها و اشیاء و یا Object های پایگاه داده ، از یک پایگاه داده به دیگری و نیز به هماهنگ سازی بین پایگاه های داده برای حفظ انسجام اطلاق می شود. با استفاده از Replication می توانیم داده ها را به مکانهای مختلف ومیان کاربران از راه دور یا ریموت در سراسر شبکه های محلی و نیز گسترده و ارتباطات dial-up وwireless و همچنین در اینترنت ، توزیع کنیم . دلایل و سناریو های مختلفی موجود است که موجب می شود که Replication به عنوان ابزاری قدرتمند برای پخش کردن و انتشار داده ها در نظر گرفته شود . در اینجا به دلایلی برای عمل Replication اشاره خواهیم کرد:

  • در نظر گرفتن replication برای از بین بردن اثرات عملیات متمرکز و فشرده ی Read مثل تولید گزارش و... . در واقع replication گزینه ی مناسبی است برای زمانی که اطلاعات مورد نظر read only بوده و نیازی به آپدیت کردن source نداریم.
  • در دسترس قرار دادن داده ها برای کاربر، به عنوان مثال سرور ITPro در تهران است و از آنجایی که سازماندهی بخش توزیع ویدیو های آموزشی آن در شهر اهواز صورت می گیرد ، برای چنین سازماندهی ،نیازمند اطلاعات کاملا مرتب هستیم . حال هر بار که ما نیاز به استفاده از داده های مربوط به محصولات و یا جداول فروش داشته باشیم از یک Linked Server برای برقراری ارتباط با سرور تهران و دریافت داده های مورد نظر استفاده خواهیم کرد.چنین شرایطی اثراتی را نیز به دنبال دارد:
  1. قطعا برای دریافت داده ها در هر زمان شدیدا به ارتباطات شبکه ای متکی خواهیم بود .
  2. سرور منبع یا همان Source Server نیز Load کاری بالایی را برای خواندن داده ها متحمل خواهد شد .

پیش از پرداختن به انواع replication و جزئیات مربوط به نصب آن ابتدا باید با مفهوم چند واژه آشنا شویم . عمل replication به طور سنتی از ساختار publisher//subscriber تبعیت می کند.همانند رابطه ی مشترکین و ناشران مجلات. برای هر مجله یک ناشر (publisher) وجود دارد که اطلاعات را در قالب مقالات (articles) منتشر می کند.

حال این مجله ای که دربردارنده ی مجموعه ای از مقالات است برای انتشار و در اختیار عموم و نیز مشترکان قرار گرفتن نیاز به یک توزیع کننده (distributer) دارد و این یک ساختار استاندارد برای چرخه ی publisher // subscriber محسوب می شود.اما گاها با تغییراتی در این روند نیز مواجه می شویم به عنوان مثال ممکن است که یک publisher به عنوان یک distributer یا توزیع کننده ایفای نقش کند و یا اینکه یک distributer یا توزیع کننده ایفاگر نقش یک subscriber نیز باشد. حال به توضیح هر یک از این واژه های کلیدی می پردازیم :

  • Article یا مقاله : به اطلاعاتی اطلاق می شود که قصد replicate آنها را داریم . این اطلاعات می تواند یک جدول یا یک روال یا procedure یا یک جدول فیلتر شده و ... را در برگیرد.
  • Publication یا نشریه: به گروهی از article ها اطلاق می شود. یک article به تنهایی قادر به انتشار نیست از این رو نیاز به ایجاد publication داریم. به بیان دیگرانتشار یا publication به معنی مجموعه ای از Article ها است (اشیاء مختلف پایگاه داده ) که توسط ناشر منتشر شده است.
  • Publisher یا ناشر: به database روی source سرور گفته می شود که در واقع قصد replicate داده های آن را داریم . به عبارت دیگر یک Publisher در واقع یک database Instance است که داده ها ی موجود در طی فرایند Replication به مکان های دیگر را در دسترس قرار می دهد . یک ناشر می تواند یک یا چندین نشریه و هر تعریف منطقی مرتبط با مجموعه ی اشیا و داده هایی برای Replicate را در بر داشته باشد.
  • Distributor یا توزیع کننده: یک توزیع کننده را می توان همانند پسر بچه ای در نظر گرفت که مسئولیت تحویل نشریات به مشترکین را به عهده دارد. یک توزیع کننده می تواند ایفا گر نقش ناشر یا مشترک نیز باشد.
  • Distribution Database یا پایگاه داده ی توزیع شده : این پایگاه داده دربردارنده ی تمامی خط فرمانهای replication است. زمانی که هرگونه از تغییرات شمای DML یا DDL در Publisher اجرا شود ، دستورات مربوط به این اعمال که توسط SQL سرور تولید می شود ، دراین بخش ذخیره خواهد شد .این پایگاه داده می تواند روی همان سرور Publisher موجود باشد اما معمولا برای عملکرد بهتر توصیه می شود که آن را بر روی یک سرور مجزا قرار دهند. به طور معمول مشاهده شده که اگر distribution database روی همان ماشینی باشد که پایگاه داده ی publisher روی آن قرار دارد ، در صورتیکه تعداد زیادی Publisher موجود باشد ، این موضوع عملکرد سیستم را تحت تاثیر قرار می دهد و این دلیلی است که برای هر Publisher یک فایل distrib.exe ایجاد می شود.
  • Subscriber یا مشترک : چرخه ی انتشار با دریافت داده ها توسط یک مشترک پایان می یابد. تغییرات منتشر شده میان تمامی مشترکین یک فرایند انتشار، از طریق یک توزیع کننده تکثیر می شود. بنابراین یک مشترک با اشتراک و عضویت در یک فرایند انتشار در نهایت قادر به دریافت داده ها خواهد بود. به عبارت دیگر Subscriber یک Database Instance است که داده های replicate شده را دریافت می کند و نیز می تواند داده ها را از چندین ناشر (publisher) یا نشریه (publishers) بگیرد. بسته به نوع Replication ای که انتخاب می شود ، یک Subscriber می تواند داده ها را متقابلا به ناشر انتقال داده و یا آنها را برای سایر مشترکین منتشر کند .
  • Subscription یا اشتراک : به درخواست یک مشترک یا subscriber برای دریافت نشریه یا publication اطلاق می شود و بر دو نوع است:Pull وPush که در واقع دو روش برای انتقال داده ها از distributor یا توزیع کننده به subscriber ها یا مشترکین محسوب می شوند. در ذیل به شرح آنها می پردازیم :
  1. Push Subscription: در روش push subscription یک distributor یا توزیع کننده مسئول داده های بر صف از یک publisher بوده و درنهایت آنها را در اختیارsubscriber ها قرار می دهد.این نوع اشتراک مدیریت را ساده و متمرکز می کند چون سناریوی replication معمولی ، یک publisher و چندین subscriber را شامل می شود .مزیت این اشتراک امنیت بالای آن است چرا که فرایند آغازین در یک مکان مدیریت می شود. به عبارت دیگر کارایی distributor ها کاهش می یابد زیرا کل توزیع subscriber ها یک دفعه اجرا می شود.
  2. Pull subscription: همانند روش push یک distributor یا توزیع کننده داده های بر صف یک publisher بوده و این وظیفه ی subscriber ها است که با distributor ارتباط برقرار کرده و داده های صف بندی شده ی آماده برای عمل replication را به تصرف خود درآورند. در مقایسه با روش push از روش pull برای نشریه هایی با امنیت پایین و تعداد بالای مشترک ها استفاده می شود. این نوع اشتراک رایج تربوده چرا که یک مشترک می تواند publication و یا نشریه هایی را انتخاب کند تا در آن شرکت کند.

Replication Agent ها در SQL Server چه کاری انجام می دهند؟

حال به توضیح عواملی که برای انجام replication در پشت صحنه فالیت می کنند می پردازیم که Agent نامیده می شوند .این agent ها در فایلهای مربوطه با پسوند exe در مسیر………..\110\COM folder قرار دارند. همچنین تمامی اطلاعات مربوط به agent ها در جداول dbo.MSxxx_agents و dbo.MSxxx_history موجود در Distribution database ثبت شده اند. حال به شرح انواع agent ها و اینکه در کدام نوع از انواع replication کاربرد دارند می پردازیم (برای روشن شدن این مبحث در اینجا اشاره می کنیم که replication در SQL سرور به سه نوع Snapshot و transactional و merge تقسیم می شود که نیازمند Agent ها برای فعالیت خود هستند . در ادامه ی مقاله عناوین ذکر شده شفاف سازی خواهند شد :D) و اما شرح Agent ها :

  • Snapshot Agent: یک فایل اجرایی است که snapshot فایل های در بردارنده ی شماتیک یا ساختار و داده های جداول و اشیاء پایگاه داده را ایجاد کرده و آنها را در Distributor ذخیره می کند همچنین اطلاعات مربوط به وضعیت synchronization را در distribution database ثبت می کند.
  • Distribution Agent: برای انواع snapshot و transactional مورد استفاده قرار می گیرد. و فایل های snapshot را از distribution db به مشترکین انتقال می دهد همچنین تمامی تراکنش های منتظر برای انتشار را نیز به subscriberها منتقل می کند و برای هر دو push subscription و pull subscription قابل اجرا است .
  • Log Reader Agent: برای transactional replication استفاده می شود تراکنش های مشخص شده برای replication را از transaction log به distribution db روی publisher انتقال می دهد. هر پایگاه داده ای log reader مختص به خود را دارد که روی distributor اجرا شده و با publisher ارتباط بر قرار می کند.
  • Merge Agent: در merge replication کاربرد دارد و snapshot اولیه را برای subscriber ها اجرا کرده و تغییرات تدریجی به وجود آمده روی داده ها را نیز ادغام کرده وبه subscriber ها انتقال می دهد. هر اشتراک ادغامی merge agent خود را دارد که قادر به برقراری ارتباط با publisher و subscriber و به روزرسانی هر دوی آنها می باشد.
  • Queue Reader Agent: برای transactional replication کاربرد دارد و بر روی Distributor اجرا شده و تغییرات صورت گرفته در سمت subscriber را به publisher باز می گرداند. برخلاف merge agent وagent distribution تنها یک نمونه از Queue Reader Agent برای سرویس دهی به تمامی publisher ها و publication ها و برای یک distribution db معین وجود دارد.

Filter کردن داده ها چه امکاناتی به ما ارائه می دهد؟

فیلتر کردن جداول موجود در article ها ما را قادر می سازد تا پارتیشن هایی از داده ها را برای انتشار ایجاد کنیم .به کمک فیلتر کردن داده های منتشر شده می توان :

  • داده های ارسال شده روی شبکه را به حداقل رساند .
  • مقدار فضای ذخیره سازی مورد نیازبرای یک مشترک را کاهش داد.
  • نشریات یا publication ها را سفارشی سازی کرده و نیز شرایطی را فراهم کرد که application ها بر اساس نیازهای اختصاصی یک مشترک باشند.
  • اگر مشترکین داده ها را به روزرسانی کنند ، می توان از بروز conflict ها جلوگیری کرده و یا آنها را کاهش داد زیرا پارتیشن های داده های مختلف می توانند برای مشترکین مختلف ارسال شوند. ( در واقع در این شرایط هیچ دو مشترکی قادر به بروزرسانی داده های مشابه نخواهند بود)
  • می توان از انتقال اطلاعات مهم و حساس جلوگیری کرد. فیلتر های ردیف و فیلترهای ستون ها می توانند برای محدود کردن دسترسی مشترک به داده ها مورد استفاده قرار گیرند.

Replication چهار نوع فیلتر را ارائه می دهد که در ذیل به معرفی آنها می پردازیم :

  • Static row filter ها یا فیلتر کردن ردیف ها به صورت استاتیک که برای تمامی انواع replication ازقبیل snapshot و transactional و merge کاربرد دارد . با استفاده از آن قادر خواهیم بود زیر مجموعه ای از ردیف هایی را که منتشر می شوند ،انتخاب کنیم و یا در واقع بر حسب نیازمان آنها را محدود کنیم .
  • Column filter یا فیلتر کردن ستون که این نوع فیلتر نیز برای تمامی انواع replication به کار می رود و به کمک آن می توان زیرمجموعه ای از ستونهایی را که منتشر می شوند، انتخاب کرد.
  • Parameterized row filtered یا فیلترهای پارامتری ردیف ها تنها برای merge replication به کار گرفته می شود . این نوع از فیلتر از نظر مفهوم همانند static filter است اما در اجرا تفاوت قابل توجهی با یکدیگر دارند .هدف parameterized filter ایجاد چندین پارتیشن از داده ها است که بدون ایجاد چندین نشریه یا publication بتوانند replicate داشته باشند. به عنوان مثال اگر ما از جدول پایه ی یکسانی استفاده کنیم و دو مشترک مختلف به نام های A و B نیز داشته باشیم که هر کدام به زیر مجموعه هایی متفاوتی از آن جدول نیاز داشته باشند ، هنگام استفاده از فیلترهای ردیفی استاندارد نیازمند ایجاد دو نشریه یکی برای مشترک A و دیگری برای مشترک B خواهیم بود .اما با استفاده از فیلتر های پارامتری می توانیم برای مشترکین A و B به صورت مجزامقادیر مورد نظر متفاوتی را در نظر بگیریم. اما در نهایت هر یک از این مقادیر و مجموعه داده ها به عنوان بخشی از یک نشریه محسوب می شوند.
  • Join filter یا فیلتر الحاق که تنها برای merge replication کاربرد دارد و این نوع فیلتر به طور معمول همراه با parameterized filter ها برای بسط وگسترش فیلترینگ به دیگرجداول مربوطه به کار می رود. مثلا یک نمایندگی فروش معمولا داده های جداول دیگر از قبیل مشتریان و دیگر جداول را دارد .این دادها می توانند فیلتر شده باشند به طوری که نماینده فروش تنها داده های مشتریان خود و سفارشات آنها را دریافت کند. این نوع فیلتر همچنین می تواند همراه با static filter ها نیز به کار گرفته شود.

SQL Server مایکروسافت چند نوع توپولوژی Replication دارد؟

Central Publisher: این یکی از پر کاربردترین نوع توپولوژی ها است که در replication مورد استفاده قرار می گیرد .در این سناریو یک سرور به عنوان publisher و distributor منظور شده و سرور و یا سرور های دیگر به عنوان subscriber ها در نظر گرفته می شوند.

وب سایت توسینسو

Central subscriber: این یک توپولوژی رایج درانبار داده ها است. سرورها یا پایگاه داده های متعددی داده های خود را با یک سرور مرکزی replicate می کنند.

وب سایت توسینسو

Central publisher with remote distributor : در این توپولوژی Distribution database روی یک سرور مجزا از Distributor در نظر گرفته می شود از این ساختار زمانی استفاده می شود که سطح فعالیت های replication افزایش پیدا می کند و یا اینکه سرور و یا منابع شبکه محدود شده اند . این توپولوژی زمان load را برای publisherکاهش داده اما بطور کلی موجب افزایش ترافیک شبکه می شود .

وب سایت توسینسو

Central distributor : در این توپولوژی publisher های متعدد تنها از یک distributor استفاده می کنند که روی سروری مجزا پیاده سازی شده است . این نوع توپولوژی عملا چندان مورد استفاده قرار نمی گیرد. چرا که تنها دارای یک point of failure می باشد (یعنی همان سروری که به عنوان distributor مرکزی پیکربندی شده است) و اگر سرور distributor دچار اختلال شده و یا از کار بیفتد ، کل عملیات replication ای که بر اساس این سناریو صورت می گیرد ، نابود خواهد شد.

وب سایت توسینسو

Publishing Subscriber : این توپولوژی دارای نقشی دوگانه است . در این ساختار دو سرور داده های یکسان را منتشر می کنند. یکی از سرورهایی که عهده دار نقش publisher است داده ها را برای subscriber ارسال کرده و سپس subscriber داده ها را برای هر تعداد از مشترکین موجود منتشر می کند. این توپولوژی هنگاهی کاربرد دارد که یک publisher قصد انتقال داده ها را از طریق لینکهای ارتباطی کُند و یا گران قیمت به subscriber ها داشته باشد.

وب سایت توسینسو

معرفی انواع Replication در SQL Server

انواع replication ای که در SQL Server 2008R2 صورت می گیرند به قرار زیر است :

  • Transactional Replication یا رونوشت تراکنش
  • Merge Replication یا رونوشت ادغامی
  • Snapshot replication یا رونوشت ثبت لحظه ای

نوع replication ای که ما انتخاب می کنیم به فاکتورهای مختلفی وابسته است این فاکتورها محیط فیزیکی replication ، نوع و کمیت داده هایی که قصد replicate آنها را داریم و اینکه آیا داده ها باید برای subscriber به روز رسانی شوند یا خیر را شامل می شود. محیط فیزیکی به تعداد و مکان کامپیوتر های درگیر در عمل replication اطلاق می شود .حال این کامپیوترها می توانند client هایی همچون workstation ها ، لپ تاپ ها و یا device های handle بوده و یا سرور ها را در بر گیرند.

هر نوع از replication بطور معمول با همگام سازی اولیه ی object های publish شده میان publisher و subscriber شروع می شود. این همگام سازی اولیه می تواند توسط replication و با یک snapshot ایجاد شود. Snapshot یک کپی از تمامی object ها و داده های مشخص شده توسط یک نشریه یا publication تهیه می کند.پس از اینکه snapshot ایجاد شد ، به مشترکین یا subscriber ها تحویل داده می شود.

برای برخی از نرم افزارهای کاربردی snapshot replication مورد نیاز می باشد و برای دیگر application ها این مساله مهم است که تغییرات ایجاد شده روی داده ها بصورت تدریجی در طول زمان در اختیار Subscriber قرار بگیرد.برخی از Application ها نیازمند بازگشت تغییرات صورت گرفته روی داده از از subscriber به publisher نیز هستند . transactional replication و merge replication آپشن هایی هستند که این امکان را برای اینگونه application ها فراهم می آورند.

تغییرات صورت گرفته روی داده ها ، از طریق snapshot قابل پیگیری نیست و هر زمان که یک snapshot گرفته شده تایید شود ، روی داده ی موجود overwrite خواهد شد. در transnational replicationپیگیری تغییرات از طریق transaction log های SQL Server و در merge replication نیز از طریق trigger ها و metadata table ها میسر خواهد بود . حال به شرح هرکدام از انواع replication می پردازیم :

Snapshot Replication یا رونوشت ثبت لحظه ای چیست؟

داده ها را دقیقا همانگونه که در یک لحظه ی خاص زمانی ظاهر می شوند توزیع می کند . و نمی توان بواسطه ی آن آپدیت و به روز رسانی داده ها را مانیتور کرد.وقتی که عمل synchronization اتفاق می افتد Snapshot تولید شده و برای subscriber ها ارسال می شود . باید این نکته را در نظر داشت که Snapshot Replication به خودی خود مورد استفاده قرار می گیرد

اما فرایند پردازش snapshot ها که در واقع مراحل کپی برداری از object ها و داده های تعیین شده توسط یک نشریه را نیزشامل می شود ومعمولا برای فراهم آوردن مجموعه ی اولیه ای از داده ها و object های پایگاه داده برای انواع transactional /merge replication کاربرد دارد.استفاده از snapshot replication به خودی خود هنگاهی مناسب است که موارد عنوان شده در ذیل محقق باشند:

  • داده ها به ندرت تغییر داشته باشند
  • قصد replicate کردن حجم کمی از داده ها را داشته باشیم .
  • اگر که حجم زیادی از داده ها در طی یک دوره کوتاه زمانی تغییر کند.

مناسب ترین زمان برای استفاده از snapshot replication هنگامی است که تغییراتی اساسی و قابل توجه اما نادر برای داده ها اتفاق بیفتد. برای مثال اگر لیست قیمت محصولات موجود در فروشگاه ITPro ثابت بوده و یک یا دوبار درسال در یک زمان مشخص آپدیت و به روزرسانی می شوند ، در چنین وضعیتی استفاده از snapshot replication بعد از اعمال تغییرات روی داده ها توصیه می شود با توجه به انواع خاصی از داده ها ، ممکن است که Snapshot های مکرری نیاز باشد.

مثلا اگر یک جدول نسبتا کوچک در سرور publisher در طی روز آپدیت شده اما اندکی تاخیر نیز جایز باشد ، این تغییرات می توانند به عنوان یک Snapshot شبانه تحویل داده شوند. Snapshot replication دارای سربار مداوم کمتری نسبت به transactional replication بر روی publisher می باشد چرا که تغییرات تدریجی را دنبال نمی کند. با این حال اگر مجموعه داده ای که درحال replicate است بسیار بزرگ باشد به منابع قابل توجهی برای ساخت و به کار بردن snapshot نیاز دارد. هنگام ارزیابی شرایط برای استفاده از snapshot replication باید اندازه ی کل مجموعه داده ها و فراوانی تغییرات ایجاد شده روی آنها را در نظر گرفت .

Snapshot replication چگونه کار می کند؟

بطور پیش فرض هر سه نوع replication ازیک snapshot برای مقدار دهی اولیه به subscriber ها استفاده می کنند . همیشه Snapshot agent موجود در SQL Server وظیفه ی تولید فایل های snapshot را به عهده دارد اما agent مربوط به ارائه و تحویل این فایل ها بسته به نوع replication انتخاب شده ، متفاوت است.

Snapshot replication و transactional replication برای ارائه ی فایلها از distribution agent استفاده می کنند در حالی که merge replication برای این منظور از merge agent بهره می گیرد. Snapshot agent روی distributor اجرا می شود . distribution agent و Merge Agent روی یک Distributor برای push subscription ها اجرا شده و همچنین بر روی subscription ها برای pull subscriber ها اجرا می شوند.

Snapshot می تواند بلافاصله بعد از ایجاد یک subscription ، تولید و اعمال شود و یا اینکه بر اساس یک برنامه در زمان انتشار ساخته شود. Snapshot Agent فایلهای snapshot حاوی ساختار و داده ها ی جداول منتشر شده (published tables) و نیز اشیاء پایگاه داده را آماده کرده و این فایلها را برای ناشر یا publisher در Snapshot folder ذخیره می کند و مسیر ردیابی این اطلاعات را در Distribution database موجود در Distributor ثبت می کند. می توان snapshot folder پیش فرض را به هنگام پیاده سازی و پیکربندی یک Distributor مشخص کنیم اما می شود که محل دیگری نیز برای نشریه، به جای آن فولدر یا علاوه بر آن فولدر پیش فرض در نظر گرفت.

علاوه بر فرایند snapshot استاندارد که به توضیح آن پرداختیم ، یک فرایند دو بخشی snapshot نیز وجود دارد که در انتشار به صورت ادغام کاربرد دارد که از parameterized filter ها بهره می برد . همانگونه که قبلا گفتیم یک filter فرایندی است که اطلاعات را محدود و یک زیر مجموعه را تولید می کند.

استفاده از parameterized filter به ما این اجازه را می دهد که پارتیشن های مختلفی از داده ها را برای subscriber های متعدد ارسال کنیم بدون اینکه نیاز به ایجاد publication ها و یا همان نشریه های متعدد باشد .در تصویر زیر اجزای اصلی Snapshot replication نمایش داده شده که به درک بهتر مفاهیم گفته شده کمک خواهد کرد :

وب سایت توسینسو

Transactional Replication یا رونوشت تراکنشی چیست؟

عملیات transactional replication به طور معمول با گرفتن یک snapshot از اشیا و داده های پایگاه داده ی یک publication شروع می شود.به محض اینکه Snapshot اولیه گرفته شد ، تغییرات بعدی که روی داده ها و شماهای موجود در سمت ناشر یا publisher ایجاد شده به subscriber ها تحویل داده می شوند .

به طور جزئی تر می توان گفت که تغییرات و تراکنش هایی که روی article های منتشر شده رخ داده اند از سمت publisher برای distributor ارسال می شود تا آنها را برای subscriber ها و یا همان مشترکین بفرستد . subscriber ها تنها می توانند از این داده ها به صورت read only استفاده کنند چرا که در این نوع replication ، تغییراتی که صورت می گیرد مجددا برای publisher بازگردانده نمی شود. با این حال transactional replication آپشن هایی ارائه می دهد که شرایط به روز رسانی اطلاعات را برای Subscriber ها فراهم می آورند .

قطعا عنوان کردن یک مثال مساله را روشن تر می کند : یک وب سایت رزرو بلیط را در نظر می گیریم تمامی بلیط های رزرو شده به صورت متمرکز در پایگاه داده ی واقع در شهر تهران ذخیره می شوند و در هر شهر از کشور نیز یک مرکز توزیع یا distribution center قرار دارد که رزرو ها را گرفته و بلیط های رزرو شده را برای آدرس های موجود ارسال می کند.لازم است که تمامی بلیط های رزرو شده از اهواز برای مشتریان مربوطه ارسال شوند.

پایگاه توزیع مرکزی موجود در اهواز می تواند که یک transnational replication فیلتر شده را راه اندازی کند برای اینکه هر رزرو جدیدی (تراکنشی) که صورت گرفت با سایر شعب مربوط به این مرکز، در حداقل زمان ممکن replicate شود. ( فیلتر موجب می شود که این مرکز تنها رزرو ها را برای اهواز دریافت کند ) . این شعب نیازمند دسترسی read only برای استفاده از داده های replicate شده هستند که transnational replication این امکان را برای آنها فراهم می آورد .بنابراین مواردی را می شود برای transactional replication به خاطر سپرد:

  • از آنجایی که عمل replication در طی یک تراکنش اتفاق می افتد ، تاخیر تکرار و replicate داده ها بسیار ناچیز است.
  • مشترکین دسترسی read only به داده ها دارند ، از این رو تقریبا هیچ گونه استقلالی برای مشترکین یا subscribe ها وجود ندارد.
وب سایت توسینسو

Transactional replication بطور معمول برای محیط های سرور به سرور(server-to-server) استفاده می شود و برای هر یک از موارد زیر مناسب است :

  • زمانی که بخواهیم تغییرات تدریجی داده های مورد نظر را پس از وقوع برای مشترکین منتشر کنیم .
  • برای application هایی که به تاخیر کمی بین زمانی که یک تغییر در سمت ناشر ایجاد می شود تا زمانی که تغییر به یک مشترک می رسد نیاز دارند.
  • هنگامیکه publisher دارای حجم بسیار بالایی از فعالیت ها از قبیل درج ، به روزرسانی و یا حذف باشد .
  • برای زمانیکه Publisher یاSubscriber پایگاه داده ای غیر از SQL سرور باشد .مثلا Oracle باشد.
  • یک Application نیاز به دسترسی برای مداخله در وضعیت داده ها داشته باشد برای مثال اگر ردیفی از یک جدول پنج بار تغییر کند ، Transactional Replication به هر Application این امکان را می دهد که قادر باشد برای هر تغییر مداخله کند (مثلا استفاده از trigger ها ) و تغییرات داده ها به سادگی به ردیف ها اعمال نشوند.

Transactional Replication چگونه کار می کند؟

برای پیاده سازیtransactional replication عواملی مانند Snapshot Agent و Log Reader Agent و Distribution Agent ها دخیل هستند . Snapshot Agent درواقع snapshot فایلهای دربردارنده ی ساختارها (schema) و داده های جداول منتشر شده و اشیاء پایگاه داده را مهیا کرده و این فایلها را در فولدر Snapshot ذخیره می کند و نتیجه ی عمل synchronization را در Distribution database موجود روی Distributor ثبت می کند.

Log Reader Agent وظیفه ی مانیتور کردن transaction log های هر پایگاه داده ای که برای عمل transactional replication پیکربندی شده را به عهده داشته و تراکنش های مشخص شده برای عمل replication را از transaction log به distribution database کپی می کند. Distribution Agent نیز Snapshot فایلهای اولیه از پوشه ی snapshot و همچنین تراکنش های نگه داشته شده در جداول distribution database را برای مشترکین یا subscriber ها کپی می کند.

تغییرات تدریجی ایجاد شده سمت ناشر مطابق برنامه زمانبندی Distribution Agent در دسترس مشترکین قرار می گیرند که این جریان انتقال اطلاعات می تواند به طور مداوم با حداقل زمان تاخیر و یا در فواصل زمانی برنامه ریزی شده اجرا شود. از آنجا که تغییرات داده ها باید در سمت ناشر ایجاد می شوند. ( زمانیکه از transactional replication بدون آپشن های immediate updating و queued updating بهره می گیریم .

{ البته در ادامه به شرح کارایی این دو آپشن می پردازیم } ) باید ازایجاد conflict در به روزرسانی ها جلوگیری کرد .در نهایت تمامی مشترکین به مقادیر مشابه و یکسان از یک ناشر دست خواهند یافت. همچنین اگر از آپشن های immediate updating یا queued updatingبرای transactional replication بهره بگیریم ، به روزرسانی ها می توانند سمت مشترکین ایجاد شوند و با queued updating ، ممکن است تضاد و conflict اتفاق بیفتد.

  • Immediate Updating به مشترکین Snapshot // Transactional Replication اجازه می دهد تا داده های replicate شده را در سمت مشترک بروزرسانی کرده و تغییرات به وقوع پیوسته را به ناشر و دیگر مشترکین بازگردانی کند . این آپشن برای زمانی مفید است که قصد استفاده از Snapshot یا transactional replication را داشته باشیم اما نیازمند شرایطی باشیم که به روزرسانی های گاه به گاه در سمت مشترک صورت گیرد. برای استفاده از این آپشن ،ناشر و مشترک باید در دسترس بوده و ارتباط بین آن دو برقرار باشد.
  • Queued Updating به مشترکین Snapshot // Transactional Replication نیز اجازه می دهد داده های منتشر شده را بدون نیاز به یک اتصال شبکه ای اکتیو به publisher ، تغییر دهند. وقتی که یک نشریه یا publication را با استفاده از این آپشن ایجاد می کنیم و یکی از مشترکین عملیاتی چون Insert یا Update یا Delete را روی داده های منتشر شده پیاده سازی می کند ، این تغییرات دریک صف ذخیره می شوند. هنگامی که ارتباطات شبکه ای مجددا برقرار شود ، این تراکنش های بر صف به صورت غیر همزمان به publisher اعمال می شوند.

از آنجایی که که به روزرسانی داده ها به طور غیر همزمان برای publisher منتشر می شوند ، همان داده ها ممکن است توسط خود ناشر یا publisher و یا مشترک دیگری نیز آپدیت شده باشند در نتیجه به هنگام اعمال آپدیت های برصف ممکن است conflict یا ناسازگاری به وجود بیاید.

این conflict ها به کمک conflict resolution policy که به هنگام ایجاد یک publication تنظیم می شود ،شناسایی و حل و فصل می شوند .Queued updating برای Application هایی مناسب است که کاربران آنها اغلب داده ها را خوانده و گاه به گاه به به روز رسانی داده ها می پردازند. ارتباطات مشترکین نیز باید اکثر اوقات بر قرار باشد و اگر که مشترکین آقلاین باشند نیز عملیات به روزرسانی بدون وقفه ادامه خواهد یافت.

  • نکته: این آپشن ها قابلیت سوییچ شدن روی یکدگیر را دارند به عنوان مثال برای Subscription مشخص کرده ایم که از حالت immediate updating استفاده کند ، اما فرضا تحت شرایطی ارتباطات شبکه دچار مشکل شده بنابراین می توانیم برای دریافت آپدیت ها روی queued updating سوییچ کنیم . باید در نظر داشت که replication به صورت اتوماتیک نمی تواند بین حالات آپدیت سوییچ کند و برای این منظور باید تنظیمات مربوط به update mode از طریق SQL Server Management Studio انجام شود و یا application ما sp_setreplfailovermode را برای سوییچ بین دو حالت فراخوانی کند. (این روال به ما اجازه می دهد تا تنظیمات مربط به failover را برای مشترکین یا subscriber ها انجام دهیم تا قادر به تعویص وضعیت از حالت immediate updating به Queued updating باشند.) نحوه عملکرد transactional replication در تصویر زیر نمایش داده شده است:
وب سایت توسینسو

Merge Replication یا رونوشت ادغامی  چیست؟

در snapshot//transactional replication ناشران داده ها را ارسال کرده و مشترکین آنها را دریافت می کنند و احتمال اینکه یک مشترک داده های کپی شده را به ناشران ارسال کند ،وجود ندارد اما این امکان به کمک merge replication میسر شده است . Merge replicationنیز همانند transactional replication فعالیت خود را به طور معمول با گرفتن snapshot از اشیا و داده های موجود در پایگاه داده ی یک publication آغاز می کند.

تغییرات ثانویه داده ها و نیز تغییرات طرح یا schema در سمت ناشر صورت می گیرد و مشترکین نیز به واسطه ی trigger ها این تغییرات را دنبال می کنند. یک مشترک یا subscriber به هنگام اتصال به شبکه داده های خود را با ناشر تطبیق داده و synchronize می کنند و در واقع به مبادله ی تمامی ردیف هایی که از آخرین عمل synchronization بین ناشر و مشترک دچار تغییر شده اند، می پردازد.Merge replication معمولا برای محیط های سرور به سرویس گیرنده یا Server-to-Client کاربرد دارد وبه کار گیری آن درهریک از شرایط عنوان شده در زیر مناسب است :

  • در شرایطی که چندین مشترک ممکن است که داده های مشابه را در زمان های مختلفی بروزرسانی کرده و این تغییرات را برای ناشر و سایر مشترکین منتشر کنند.
  • زمانی که مشترکین نیاز به دریافت داده ها و ایجاد تغییرات به صورت آفلاین داشته باشند و بعدا این تغییرات را با ناشر و دیگر مشترکین synchronize کنند.
  • هر مشترک به یک پارتیشن متفاوت از داده ها نیاز داشته باشد.
  • هنگامیکه ممکن است conflict اتفاق بیفتد و در چنین شرایطی باید قادر به تشخیص و رفع این مشکل باشیم .

Merge replication به سایت های مختلف اجازه می دهد تا به صورت مستقل کار کنند و در نهایت آپدیت ها را بایکدیگر ادغام کرده تا به نتیجه ای یکسان و یکنواخت دست یابند. از آنجایی که به روزرسانی در بیشتر از یک گره صورت می گیرد ، داده های مشابه ممکن است توسط ناشر و نیز بیش از یک مشترک آپدیت شوند بنابراین ممکن است به هنگام ادغام این آپدیت ها تضاد یا conflict اتفاق بیفتد و merge replication راه هایی را برای رسیدگی به مشکل conflict ها فراهم می آورد.

Merge Replication چگونه کار می کند؟

Merge replication توسط عاملهایی چون snapshot agent و merge agent اجرا می شود. اگر publication یا نشریه فیلتر نشده باشد و یا از فیلترهای استاتیک استفاده می کند ، Snapshot agent تنها یک snapshot ایجاد می کند و اگر که publication از فیلتر های پارامتری یا parameterized filter ها بهره می گیرد ،snapshot agent ازهر پارتیشن داده ها یک snapshot تهیه می کند.merge agent نیز snapshot های اولیه ی تهیه شده را به مشترکین اعمال می کند.

این عامل همچنین تغییرات تدریجی که روی داده ها در سمت ناشر و یا مشترکین پس از ایجاد snapshot اولیه صورت گرفته را ادغام کرده وبا توجه به قوانینی که برای آن پیکربندی می کنیم به تشخیص و حل وفصل conflict های ایجاد شده می پردازد. به هنگام استفاده از Merge replication سه تغییر برای ساختار پایگاه داده ی نشریه اتفاق می افتد:

  • یک ستون منحصر بفرد را برای هر سطر کپی شده تعیین می کند
  • چندین جدول سیستمی اضافه می شود
  • Trigger هایی برای جداولی که داده های آنها کپی شده اند،ایجاد می کند.

برای ردیابی تغییرات ، merge replication و نیز transactional replication ای که از قابلیت queued updating استفاده می کند باید قادر به شناساسی هر ردیف از جدول منتشر شده به گونه ای منحصر بفرد باشند. برای انجام این عمل merge replication ستون rowguid را به هر جدول اضافه می کند مگر اینکه جدول در حال حاضر دارای ستونی با نوع داده ی uniqueidentifier و ویژگی ROWGUIDCOL باشد که در این صورت از همین ستون برای شناسایی هر سطر و تغییرات آنها استفاده می شود.

SQL سرور چندین جدول سیستمی برای پشتیبانی از ردیابی داده ها ، انجام عمل synchronization به صورت کارامد و برای تشخیص Conflict ها و نیز برای گزارش دهی ، را به پایگاه داده اضافه می کند.تمامی تغییرات مربوط به داده ها در جداول سیستمی msmerge_contents و msmerge_tombstone ذخیره می شوند. این نوع از replicatin ها trigger هایی را نصب می کند که تغییرات داده های هر ستون و یا هر ردیف از جدول را دنبال می کنند.

trigger ها تغییرات ایجاد شده روی جدول منتشر شده را ضبط کرده و این تغییرات را در جدول های سیستمی msmerge_contents و msmerge_tombstone ثبت می کنند. این trigger ها هنگامی که snapshot agent برای اولین بار برای یک نشریه یا publication اجرا می شود، ایجاد می شوند . trigger ها در سمت یک مشترک نیز هنگامی بوجود می آیند که snapshot برای مشترک استفاده شود. در تصویر زیر اجزایی که درmerge replication به کار گرفته می شوند نمایش داده شده است:

وب سایت توسینسو

تا اینجای مقاله حتی الامکان سعی کردیم به توضیح مفاهیم replication در SQL سرور به زبانی ساده بپردازیم.

در قسمت قبل به توضیح مفاهیم replication پرداختیم حال قصد داریم تا کاربرد و پیاده سازی این مفاهیم را به صورتی ساده عنوان کنیم . بنابراین یک سناریو طراحی کرده و به انجام عملیات می پردازیم البته با توجه به این نکته که اطلاعات و جداول این سناریو کاملا فرضی بوده و از استاندارد لازم نیز برخوردار نیستند.

بنابراین تمرکز ما در اینجا صرفا بر روی نحوه ی پیکربندی Replication در SQL سرور 2008 خواهد بود. Replication انواع مختلف و نیز توپولوژی های متفاوتی دارند که با مراجعه به قسمت پیشین مقاله توضیحات مربوط به آنها را می توان مطالعه کرد.در این سناریو ما از Transactional replication و نیز توپولوژی Central publisher بهره می گیریم .

معرفی سناریوی راه اندازی Replication در SQL Server مایکروسافت

در سناریوی فرضی ما سه سرور وجود دارد. سرور اصلی ITPro در تهران که نقش Publisher وDistributor را ایفا می کند و دو سرور دیگر در شهر های اهواز و شیراز که در واقع Subscriber های سرور تهران محسوب می شوند. حال می خواهیم که سرور تهران هر گونه تغییری که در جدول مرتبط با لیست کاربران برتر ایجاد می شود را با جداول موجود روی سرور های اهواز و شیراز Replicate کند.بنابراین باید تنظیمات لازم برای توزیع و انتشار ( Distribution و Publication) را روی سرور تهران و تنظیمات مربوط به اشتراک ( Subscription) را روی سرور های اهواز و شیراز انجام دهیم.

وب سایت توسینسو

آموزش راه اندازی Replication  در SQL سرور مایکروسافت

اول از هر چیز باید در نظر داشته باشیم که موقع نصب SQL سرور، قابلیت Replication را نیز فعال کنیم . نصب SQL سرور در مقاله های مهندس نصیری مرحله به مرحله توضیح داده شده است .کاملترین آموزش نصب SQL سرور | گام به گام | تصویری + نکات مهم

وب سایت توسینسو

برای سهولت کار و مشاهده ی تمامی سرور ها در تصویر در اینجا ما سه سرور را به صورت متمرکز از طریق کنسول مدیریتی SQL Server Management Studio مدیریت خواهیم کرد.( برای این منظور سرویس SQL Browser می بایست فعال باشد).

وب سایت توسینسو

تنظیمات بخش توزیع یا Distribution در SQL Replication

در ابتدای کار به سراغ Distribution بر روی سرور ITPro1 در تهران می رویم .برای این منظور روی گزینه ی Replication در کنسول مدیریتی راست کلیک کرده و عبارت Configure Distribution را انتخاب می کنیم تا ویزارد پیکربندی برای ما نمایش داده شود.

وب سایت توسینسو

در این مرحله سرور توزیع کننده یا Distributor را انتخاب می کنیم که می توان خود سرور فعلی را انتخاب کرده و یا سرور دیگری را به عنوان توزیع کننده در نظر بگیریم. فقط باید در نظر داشته باشیم که پیکربندی Distribution روی سرور دیگر که آن را به عنوان توزیع کننده انتخاب می کنیم، از قبل انجام شده باشد. در اینجا ما سرور فعلی را برگزیده و به مرحله ی بعد می رویم.

وب سایت توسینسو

این بخش مربوط به تعیین مسیر فولدری است که Snapshot های گرفته شده از تغییرات در آن کپی می شوند. برای اینکه Distribution agent و Merge agent های اجرا شده روی Subscriber ها بتوانند به Snapshot های publication ها دسترسی داشته باشند، در این قسمت باید مسیر فولدر در نظر گرفته شده برای ذخیره ی Snapshot ها را به ویزارد معرفی کنیم.

در واقع باید network path پوشه ی نگهدارنده ی snapshot ها را مشخص کنیم . مسیر لوکال و پیش فرضی که در ویزارد مشخص شده pull Subscription های ایجاد شده سمت مشترکین را پشتیبانی نمی کند چرا که این مسیر یک مسیر تحت شبکه نمی باشد و برای ایجاد pull Subscription باید یک مسیر شبکه ای را در اینجا معرفی کنیم که به پوشه ی Snapshot ها اشاره کند.

وب سایت توسینسو

در این صفحه از ویزارد، نام پایگاه داده ی Distribution و نیز لوکیشن آن را مشخص می کنیم . این پایگاه داده برای داده هایی با پسوند (.MDF) و برای Log فایل ها با پسوند (.ldf) پیکربندی می شود. پایگاه داده ی مربوط به Distribution تغییرات ایجاد شده در داده ها را در transactional publication ذخیره می کند تا زمانی که مشترکین یا همان Subscriber ها بتوانند آپدیت شوند.

همچنین این دیتابیس اطلاعات را بر حسب تاریخ برای Snapshot publication و merge publication ذخیره می کند. مسیری که در اینجا در نظر می گیریم حتما باید یک آدرس لوکال باشد و با یک drive letter و علامت دو نقطه شروع شود( به عنوان مثال C:) و در اینجا استفاده از Drive letter ها ی map شده و مسیر های تحت شبکه غیر مجاز می باشد.

وب سایت توسینسو

سرور و یا سرور هایی که قرار است به عنوان ناشر و یا همان publisher فعالیت کنند را در این مرحله مشخص می کنیم . این سرور و یا سرور ها از Distributor برای انجام توزیع انتشارات و یا publication های خود استفاده می کند. به صورت پیش فرض سرور فعلی به عنوان publisher در نظر گرفته می شود که بسته به ساختار پایگاه های داده و سناریو ی مورد نظر با کلیک روری گزینه Add می توانیم سرور های دیگری نیز برای این بخش در نظر بگیریم.

وب سایت توسینسو

در این قسمت چگونگی خاتمه یافتن تنظیمات انجام شده را مشخص می کنیم . به صورت پیش فرض گزینه ی Configure distribution مارکدار شده است.

وب سایت توسینسو

در آخرین صفحه از ویزارد خلاصه ای از تنظیمات انجام شده نمایش داده می شود. برای تکمیل فرایند پیکر بندی روی گزینه Finish کلیک می کنیم .

وب سایت توسینسو

در نهایت در صورت عدم بروز مشکل ، با نمایش عبارت success در قسمت وضعیت، انجام موفقیت آمیز تنظیمات را مشاهده خواهیم کرد.

وب سایت توسینسو

تنظیمات نشریه یا Publication در SQL Replication

انجام تنظیمات این بخش نیز روی سرور اول (ITPRO1) صورت خواهد گرفت چرا که طبق سناریو این سرور هر دو نقش ناشر و توزیع کننده را ایفا می کند. بنابراین روی گزینه Local Publication در کنسول مدیریتی راست کلیک کرده و گزینه ی New Publication را انتخاب می کنیم به این ترتیب ویزارد نصب نمایش داده می شود.

وب سایت توسینسو

در این صفحه لیستی از پایگاه های داده ی در بردارنده ی داده ها و یا اشیایی که قصد انتشار آنها را داریم نمایش داده می شود. دراینجا تنها دیتابیس مورد نظر ما نمایش داده شده، آن را برگزیده و به مرحله ی بعد می رویم.

وب سایت توسینسو

در این قسمت انواع نشریه و یا همان publication ها نمایش داده می شود و درواقع بخشی است که در آن نوع replication مشخص می شود. همانگونه که در تصویر می بینیم به دو صورت می توان عمل transactional replication را انجام داد. نمونه ای که ما در اینجا به پیکربندی آن می پردازیم و نیز transactional replication با قابلیت آپدیت توسط مشترکین تمامی این انواع در قسمت قبلی مقاله توضیح داده شده اند. در این قسمت گزینه ی Transactional publication را انتخاب کرده و روی Next کلیک می کنیم.

وب سایت توسینسو

در این بخش نیز داده ها و اشیای موجود در دیتابیس انتخابی لیست می شوند که در این قسمت می توانیم آنهایی که برای عمل replication مورد نظر ما هستند را انتخاب کنیم. این سناریو در یک محیط آزمایشی است بنابراین در اینجا تنها یک جدول داریم .

وب سایت توسینسو

در همین مرحله از تنظیمات با کلیک روی گزینه ی Article properties می توانیم جزئیات توضیحات مرتبط با جدولی را که انتخاب کردیم و یا توضیحات مربوط به تمامی اشیاء موجو در Article را مشاهده کرده و درصورت نیاز تغییراتی را در آن ایجاد کنیم . در این جا ما همان تنظیمات پیش فرض را دست نخورده باقی می گذاریم .

وب سایت توسینسو

در قسمت قبلی مقاله در رابطه با فیلترینگ ، انواع و مزیت های آن توضیح دادیم . از جمله دلایل استفاده از فیلتر می توان به، به حداقل رساندن داده های ارسالی روی شبکه و کاهش مقدار فضای ذخیره سازی برای یک مشترک را یاد آور شد. در این بخش از تنظیمات با ایجاد فیلترینگ می توانیم به حذف ردیف هایی که به آنها نیاز نداریم از جدول منتشر شده بپردازیم.

یک مثال ساده برای درک فیلتر کردن این است که مثلا نام و نام خانوادگی کاربران برتر تغییر نخواهد کرد بنابراین نیاز به انتشار مجدد آن ها نداریم. در این تصویر با کلیک روی گزینه Add صفحه ی مربوط به ایجاد فیلترینگ نمایش داده می شود .در این سناریو ما هیچ گونه فیلتری را در نظر نگرفته و با کیلک روی Next به مرحله ی بعدی می رویم .

وب سایت توسینسو

در اینجا تعیین می کنیم که چه زمانی Snapshot agent اجرا شود . مشترکین بواسطه ی snapshot های داده و طرح های یک نشریه مقداردهی می شوند و این Snapshot agent است که snapshot را ایجاد می کند. در این تصویر دو گزینه وجو دارد اولین گزینه بیانگر ایجاد یک Snapshot به صورت فوری و در دسترس نگه داشتن آن برای مقدار دهی اولیه به مشترکین است و گزینه ی دوم شرایط زمانبندی را برای فعالیت Snapshot agent فراهم می آورد. گزینه ی اول را مارکدار می کنیم .

وب سایت توسینسو

این مرحله مرتبط با مشخص کردن حساب کاربری برای هر Agent می باشد که اجرا و تنظیمات ارتباطات آن تحت این Account انجام خواهد شد. برای انجام این تغییرات روی گزینه ی Security Settings کلیک می کنیم . در صفحه ی نمایان شده گزینه ی Run under the SQL Server Agent account را مارکدار می کنیم.

اگر سرویس SQL Server Agent سطح دسترسی و مجوزهای لازم را برای دسترسی به پوشه ای که برای نگه داری Snapshot ها انتخاب کرده ایم نداشته باشد، باید روشی دیگر از احراز هویت حساب کاربری را برای فراهم آوردن این دسترسی در نظر بگیریم. در نهایت تنظیمات صورت گرفته همانند کادر کوچک مشخص شده در صفحه نمایش داده خواهند شد.

وب سایت توسینسو

در این قسمت چگونگی پایان یافتن تنظیمات انجام شده را مشخص می کنیم . به صورت پیش فرض گزینه ی Configure distribution مارکدار شده است.

وب سایت توسینسو

در این بخش خلاصه ای از تنظیماتی که انجام دادیم، نمایش داده می شود. نام مورد نظر برای نشریه یا publication ای را که ایجاد کرده ایم در این بخش مشخص کرده و در نهایت روی گزینه ی Finish کلیک می کنیم.

وب سایت توسینسو

پس از پیکربندی موفقیت آمیز Publication می توانیم همانند تصویر Publication ایجاد شده را در بخش Replication کنسول مدیریتی مشاهده کنیم.

وب سایت توسینسو

در قسمت بعدی و پایانی مقاله به پیکربندی و انجام تنظیمات مربوط به مشترکین یا همان Subscriber ها خواهیم پرداخت ...

در قسمت قبل پیاده سازی Transactional replication یک سناریو طرح کرده و به صورت قدم به قدم به اجرای آن پرداختیم در ابتدا پیکربندی Distribution را انجام دادیم و سپس تنظیمات مربوط به ایجاد یک publication را پیاده سازی کردیم. بدین ترتیب توزیع کننده و ناشر مشخص شده در سناریو ایجاد شدند. حال در این قسمت به پیکربندی و انجام تنظیمات برای مشترکین یا Subscriber ها می پردازیم .

تنظیمات بخش اشتراک یا Subscription در SQL Replication

همانطور که قبلا گفتیم در اینجا هر سه سرور موجود در سناریو را از طریق کنسول Management Studio مدیریت می کنیم. در سرور دوم (ITPRO2) یا همان سرور مستقر در اهواز، روی Local Subscription زیر مجموعه ی Replication این سرور در کنسول مدیریتی راست کلیک کرده و گزینه ی New Subscription را برای مشاهده ی ویزارد مربوطه انتخاب می کنیم.

وب سایت توسینسو

در این تصویر همانطور که نشان داده شده است باید سرور publisher و یا نشریه ای را که می خواهیم Subscription ها را برای آن ایجاد کرده، تعیین کنیم. پس در پنجره ی publisher از قسمت نوار کشویی گزینه ی Find SQL Server Publisher را باز کرده و پس از انتخاب سرور مورد نظر (در اینجا ITPRO1) نام publication ایجاد شده در قسمت قبلی نمایان خواهد شد.

وب سایت توسینسو

در این بخش باید محلی که Distribution Agent ها روی آن اجرا می شوند را مشخص کنیم . برای این منظور دو گزینه پیش روی ماست : اجرای همه ی Agent ها روی Distributor یا Push subscription و اجرای هر Agent روی subscriber خود یا Pull subscription .

در مقاله مفاهیم replication به توضیح pull\Push Subscription ها پرداختیم بر حسب شرایط می توان یکی از این دو نوع را برای Agent ها در نظر گرفت. در قسمت قبل ما یک مسیر لوکال را برای دسترسی به پوشه ی Snapshot ها تعیین کردیم و می دانیم آدرس لوکال Pull Subscription را پشتیبانی نمی کند، بنابراین در اینجا گزینه ی اول یعنی Push Subscription را انتخاب می کنیم.

وب سایت توسینسو

در این قسمت باید subscriber ها یا مشترکین و دیتابیس آنها را مشخص کنیم. به صورت پیش فرض ویزارد سروری را که تنظیمات در حال حاضر روی آن صورت می گیرد به عنوان یکی از مشترکین انتخاب می کند. با کلیک روی گزینه ی Add SQL Server Subscriber می توانیم سرورهای دیگری را به عنوان مشخص کنیم. در سناریو ما دو Subscriber وجود دارد: سرور های ITPRO2 در اهواز و ITPRO3 در شیراز.

پس از انتخاب این سرور ها حال نوبت به تعیین دیتابیسی که قرار است عمل Replicate با آنها صورت گیرد، می باشد.بدین منظور با کلیک روی نوار کشویی مقابل سرورهای انتخابی، دیتابیس مورد نظر را برمی گزینیم. اگر دیتابیسی را روی سرور برای Replication در نظر نگرفته باشیم، با توجه به تصویر دوم و کلیک روی گزینه ی New Data base نیز می توان دیتابیس مورد نظر را در لحظه ایجاد کرد.

وب سایت توسینسو
وب سایت توسینسو

در اینجا باید آپشن های مرتبط با ارتباطات و پردازش ها را برای Distribution Agent مشخص کنیم.برای تعیین حساب کاربری که Distribution Agent تحت آن اجرا شده و عمل همگام سازی با مشترکین را انجام خواهد داد گزینه ی Run the SQL Server Agent Service Account را مارکدار کرده و برای برقراری ارتباط با Distributor و Subscriber نیز گزینه ی By impersonation the process account را بر می گزینیم. این تنظیمات باید برای هر دو سرور انتخاب شده به عنوان Subscriber، به صورت مجزا انجام شود.

وب سایت توسینسو

پس از انجام تنظیمات بالا نتیجه ی آن همانند تصویر زیر در ویزارد نمایش داده می شود.

وب سایت توسینسو

در این مرحله باید برنامه ی زمانبندی همگام سازی را برای هر Agent مشخص کنیم. منوی کشویی در اینجا سه گزینه در اختیار ما قرار می دهد که بواسطه ی آنها Distribution agent به ترتیب می تواند در حالت اجرا به صورت مداوم، اجرا بر برحسب تقاضا و یا اجرا براساس برنامه ی زمانبندی تعیین شده، قرار گیرد. پس از اطمینان از قرار گرفتن agent در وضعیت Run continuously روی Next کلیک می کنیم.

وب سایت توسینسو

نحوه ی مقداردهی اولیه هر اشتراک بواسطه ی یک Snapshot از داده ها و طرح های Publication یا نشریه در این قسمت مشخص می شود. دو روش برای مقداردهی اولیه ی Subscription ها وجود دارد: به صورت فوری و در اولین همگام سازی یا Synchronization. از منوی کشویی موجود گزینه ی Immediately یا بلافاصله را برای هر دو سرور موجود انتخاب کرده و روی Next کلیک می کنیم.

وب سایت توسینسو

در این قسمت می توانیم تعیین کنیم که تنها Subscription ایجاد شده و یا فایل اسکریپت پیکربندی Subscription نیز ایجاد شود. در این بخش گزینه ی اول را انتخاب می کنیم.

وب سایت توسینسو

در این تصویر خلاصه ای از تنظیماتی که برای ایجاد Subscription ها انجام دادیم نمایش داده شده است.

وب سایت توسینسو

با کلیک روی گزینه ی Finish در مرحله قبل فرایند ایجاد subscription ها آغاز خواهد شد و در نهایت با نمایش عبارت success در قسمت Status، انجام موفقیت آمیز تنظیمات را مشاهده خواهیم کرد.

وب سایت توسینسو

به این ترتیب مراحل پیاده سازی Transactional Replication پایان می یابد و شرایط برای replicate اطلاعات میان SQL سرور ها مهیا می شود. بنابراین هر گونه تغییرایجاد شده در جدول کاربران برتر که روی دیتابیس THR.ITPro در SQL سرور ITPRO1 قرار دارد، به جدوال موجود در دیتابیس های AWZ.ITPro روی سرور ITPRO2 ودیتابیس SYZ.ITPro روی سرور ITPRO3 نیز اعمال خواهد شد.امیدوارم این مقاله مورد توجه شما دوستان قرار گیرد...


مریم حیات رمضانی
مریم حیات رمضانی

کارشناس شبکه های مایکروسافت و پایگاه داده

کارشناس سیستم عامل و زیرساخت های مایکروسافت MCTS:Active Directory 2008 MCTS:Network Infrastruture 2008 MCTS:Application Infrastructure 2008 MCTS:Active Directory 2008 MCITP:Enterprise Administrator MCSA 2008

نظرات