چند نوع 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 و جزئیات مربوط به نصب آن ابتدا باید با مفهوم چند واژه آشنا شویم . عمل replication به طور سنتی از ساختار publisher//subscriber تبعیت می کند.همانند رابطه ی مشترکین و ناشران مجلات. برای هر مجله یک ناشر (publisher) وجود دارد که اطلاعات را در قالب مقالات (articles) منتشر می کند.
حال این مجله ای که دربردارنده ی مجموعه ای از مقالات است برای انتشار و در اختیار عموم و نیز مشترکان قرار گرفتن نیاز به یک توزیع کننده (distributer) دارد و این یک ساختار استاندارد برای چرخه ی publisher // subscriber محسوب می شود.اما گاها با تغییراتی در این روند نیز مواجه می شویم به عنوان مثال ممکن است که یک publisher به عنوان یک distributer یا توزیع کننده ایفای نقش کند و یا اینکه یک distributer یا توزیع کننده ایفاگر نقش یک subscriber نیز باشد. حال به توضیح هر یک از این واژه های کلیدی می پردازیم :
حال به توضیح عواملی که برای انجام 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 ها :
فیلتر کردن جداول موجود در article ها ما را قادر می سازد تا پارتیشن هایی از داده ها را برای انتشار ایجاد کنیم .به کمک فیلتر کردن داده های منتشر شده می توان :
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 2008R2 صورت می گیرند به قرار زیر است :
نوع 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 می پردازیم :
داده ها را دقیقا همانگونه که در یک لحظه ی خاص زمانی ظاهر می شوند توزیع می کند . و نمی توان بواسطه ی آن آپدیت و به روز رسانی داده ها را مانیتور کرد.وقتی که عمل synchronization اتفاق می افتد Snapshot تولید شده و برای subscriber ها ارسال می شود . باید این نکته را در نظر داشت که Snapshot Replication به خودی خود مورد استفاده قرار می گیرد
اما فرایند پردازش snapshot ها که در واقع مراحل کپی برداری از object ها و داده های تعیین شده توسط یک نشریه را نیزشامل می شود ومعمولا برای فراهم آوردن مجموعه ی اولیه ای از داده ها و object های پایگاه داده برای انواع transactional /merge replication کاربرد دارد.استفاده از snapshot replication به خودی خود هنگاهی مناسب است که موارد عنوان شده در ذیل محقق باشند:
مناسب ترین زمان برای استفاده از snapshot replication هنگامی است که تغییراتی اساسی و قابل توجه اما نادر برای داده ها اتفاق بیفتد. برای مثال اگر لیست قیمت محصولات موجود در فروشگاه ITPro ثابت بوده و یک یا دوبار درسال در یک زمان مشخص آپدیت و به روزرسانی می شوند ، در چنین وضعیتی استفاده از snapshot replication بعد از اعمال تغییرات روی داده ها توصیه می شود با توجه به انواع خاصی از داده ها ، ممکن است که Snapshot های مکرری نیاز باشد.
مثلا اگر یک جدول نسبتا کوچک در سرور publisher در طی روز آپدیت شده اما اندکی تاخیر نیز جایز باشد ، این تغییرات می توانند به عنوان یک Snapshot شبانه تحویل داده شوند. Snapshot replication دارای سربار مداوم کمتری نسبت به transactional replication بر روی publisher می باشد چرا که تغییرات تدریجی را دنبال نمی کند. با این حال اگر مجموعه داده ای که درحال replicate است بسیار بزرگ باشد به منابع قابل توجهی برای ساخت و به کار بردن snapshot نیاز دارد. هنگام ارزیابی شرایط برای استفاده از 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 به طور معمول با گرفتن یک 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 به خاطر سپرد:
Transactional replication بطور معمول برای محیط های سرور به سرور(server-to-server) استفاده می شود و برای هر یک از موارد زیر مناسب است :
برای پیاده سازی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 اتفاق بیفتد.
از آنجایی که که به روزرسانی داده ها به طور غیر همزمان برای publisher منتشر می شوند ، همان داده ها ممکن است توسط خود ناشر یا publisher و یا مشترک دیگری نیز آپدیت شده باشند در نتیجه به هنگام اعمال آپدیت های برصف ممکن است conflict یا ناسازگاری به وجود بیاید.
این conflict ها به کمک conflict resolution policy که به هنگام ایجاد یک publication تنظیم می شود ،شناسایی و حل و فصل می شوند .Queued updating برای Application هایی مناسب است که کاربران آنها اغلب داده ها را خوانده و گاه به گاه به به روز رسانی داده ها می پردازند. ارتباطات مشترکین نیز باید اکثر اوقات بر قرار باشد و اگر که مشترکین آقلاین باشند نیز عملیات به روزرسانی بدون وقفه ادامه خواهد یافت.
در snapshot//transactional replication ناشران داده ها را ارسال کرده و مشترکین آنها را دریافت می کنند و احتمال اینکه یک مشترک داده های کپی شده را به ناشران ارسال کند ،وجود ندارد اما این امکان به کمک merge replication میسر شده است . Merge replicationنیز همانند transactional replication فعالیت خود را به طور معمول با گرفتن snapshot از اشیا و داده های موجود در پایگاه داده ی یک publication آغاز می کند.
تغییرات ثانویه داده ها و نیز تغییرات طرح یا schema در سمت ناشر صورت می گیرد و مشترکین نیز به واسطه ی trigger ها این تغییرات را دنبال می کنند. یک مشترک یا subscriber به هنگام اتصال به شبکه داده های خود را با ناشر تطبیق داده و synchronize می کنند و در واقع به مبادله ی تمامی ردیف هایی که از آخرین عمل synchronization بین ناشر و مشترک دچار تغییر شده اند، می پردازد.Merge replication معمولا برای محیط های سرور به سرویس گیرنده یا Server-to-Client کاربرد دارد وبه کار گیری آن درهریک از شرایط عنوان شده در زیر مناسب است :
Merge replication به سایت های مختلف اجازه می دهد تا به صورت مستقل کار کنند و در نهایت آپدیت ها را بایکدیگر ادغام کرده تا به نتیجه ای یکسان و یکنواخت دست یابند. از آنجایی که به روزرسانی در بیشتر از یک گره صورت می گیرد ، داده های مشابه ممکن است توسط ناشر و نیز بیش از یک مشترک آپدیت شوند بنابراین ممکن است به هنگام ادغام این آپدیت ها تضاد یا conflict اتفاق بیفتد و merge replication راه هایی را برای رسیدگی به مشکل conflict ها فراهم می آورد.
Merge replication توسط عاملهایی چون snapshot agent و merge agent اجرا می شود. اگر publication یا نشریه فیلتر نشده باشد و یا از فیلترهای استاتیک استفاده می کند ، Snapshot agent تنها یک snapshot ایجاد می کند و اگر که publication از فیلتر های پارامتری یا parameterized filter ها بهره می گیرد ،snapshot agent ازهر پارتیشن داده ها یک snapshot تهیه می کند.merge agent نیز snapshot های اولیه ی تهیه شده را به مشترکین اعمال می کند.
این عامل همچنین تغییرات تدریجی که روی داده ها در سمت ناشر و یا مشترکین پس از ایجاد snapshot اولیه صورت گرفته را ادغام کرده وبا توجه به قوانینی که برای آن پیکربندی می کنیم به تشخیص و حل وفصل conflict های ایجاد شده می پردازد. به هنگام استفاده از Merge replication سه تغییر برای ساختار پایگاه داده ی نشریه اتفاق می افتد:
برای ردیابی تغییرات ، 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 بهره می گیریم .
در سناریوی فرضی ما سه سرور وجود دارد. سرور اصلی ITPro در تهران که نقش Publisher وDistributor را ایفا می کند و دو سرور دیگر در شهر های اهواز و شیراز که در واقع Subscriber های سرور تهران محسوب می شوند. حال می خواهیم که سرور تهران هر گونه تغییری که در جدول مرتبط با لیست کاربران برتر ایجاد می شود را با جداول موجود روی سرور های اهواز و شیراز Replicate کند.بنابراین باید تنظیمات لازم برای توزیع و انتشار ( Distribution و Publication) را روی سرور تهران و تنظیمات مربوط به اشتراک ( Subscription) را روی سرور های اهواز و شیراز انجام دهیم.
اول از هر چیز باید در نظر داشته باشیم که موقع نصب SQL سرور، قابلیت Replication را نیز فعال کنیم . نصب SQL سرور در مقاله های مهندس نصیری مرحله به مرحله توضیح داده شده است .کاملترین آموزش نصب SQL سرور | گام به گام | تصویری + نکات مهم
برای سهولت کار و مشاهده ی تمامی سرور ها در تصویر در اینجا ما سه سرور را به صورت متمرکز از طریق کنسول مدیریتی SQL Server Management Studio مدیریت خواهیم کرد.( برای این منظور سرویس SQL Browser می بایست فعال باشد).
در ابتدای کار به سراغ 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 در قسمت وضعیت، انجام موفقیت آمیز تنظیمات را مشاهده خواهیم کرد.
انجام تنظیمات این بخش نیز روی سرور اول (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 ها می پردازیم .
همانطور که قبلا گفتیم در اینجا هر سه سرور موجود در سناریو را از طریق کنسول 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 نیز اعمال خواهد شد.امیدوارم این مقاله مورد توجه شما دوستان قرار گیرد...