بخش سوم: Replication ادغامی

Replication ادغامی جایگزین دیگری است که می توان برای سیستم های با درجه دسترس پذیری بالا استفاده کرد. Replication ادغامی به طور عمده برای کاربران سیار نامتصل (disconnected) طراحی شده. مکانیسم هایی به صورت تو کار قرار داده شده که تغییرات هر مکانی را سنکرون می کند، بعلاوه در برابر failure ها مقاوم بوده و پردازش را ادامه می دهد. در این بخش مکانیسم های درونی که برای Replication ادغامی موجود است و همچنین نحوه اعمال ان به سیستم ها را برسی می کنیم.

پیگیری تغییرات(Change Tracking)

فرایند پیگیری تغییرات در Replication ادغامی به این صورت است:

· برنامه کاربردی یک تراکنش را صادر می کند.

· trigger پشت جدول اغاز می شود.

· Insert و update درون Msmerge_contents و delete درون Msmerge_tombstone ثبت می شود.

· Trigger پایان می یابد (commit).

· تراکنش پایان می یابد.

بر خلاف Replication تراکنشی، Replication ادغامی کپی های داده را به پایگاه داده توزیع انتقال نمی دهد. ثبت وقایع (logging) که در MSmerge_contents و Msmerge_tombstone رخ می دهد تنها نشانگر ان است که تغییری به یک سطر خاص اعمال شده است. داده واقعی مربوط به تغییر، کپی نمی شود؛ و فقط در جدول نگهداری می شود. این، نتیجه جالبی را در بر دارد.

اگر بین چرخه های موتور Replication، 10 تراکنش مجزا برای یک سطر صادر شود و جدول با replication تراکنشی پیکره بندی شده باشد، تمام 10 تراکنش توسط عامل Log Reader به پایگاه داده توزیع انتقال می یابد، سپس هر10 تراکنش به مشترک اِعمال می شود. نتیجه اینکه فقط 9 تا از تراکنش ها اعمال می شود و سپس اثر انها توسط تراکنش دهم جایگزین و خنثی می شود. با این حال، اگر جدول با Replication ادغامی پیکره بندی شده باشد، فقط اخرین وضعیت سطر (وضعیت بعد از تراکنش دهم) به مشترک منتقل می شود. برای این منظور از فرایند زیر برای سنکرون کردن تغییرات استفاده می شود:

· موتور ادغام به مشترک متصل می شود.

· موتور ادغام به منتشر کننده متصل می شود.

· موتور ادغام جدول MSmerge_genhistory روی مشترک را مورد پرس و جو قرار می دهد تا لیست نسل هایی (generations) که در منتشر کننده موجود نیست را بیابد. (نسل یک بسته از تغییرات است که با هم اعمال می شود).

· سپس موتور ادغام، لیست جدول ها و سطرهای جدول های موجود در MSmerge_contents و MSmerge_tomstone را برای نسل هایی که منتشر کننده ندارد، بیرون می کشد.

· موتور ادغام دستور های DELETE را از سطرهایی که از MSmerge_tombstone گرفته باز سازی می کند.

· موتور ادغام محتویات سطر های جدول های base در پایگاه داده را استخراج و تغییرات را دسته دسته می کند.

· تغییرات دسته دسته شده به منتشر کننده اعمال می شود.

· نسل هایی که به منتشر کننده ارسال شد در MSmerge_contents ثبت می شود.

· ناسازگاری ها کشف و رفع می شوند.

· موتور ادغام جدول MSmerge_genHistory روی منتشر کننده را مورد پرس و جو قرار می دهد تا لیست نسل هایی که در مشترک وجود ندارد را معین کند.

· موتور ادغام سپس لیست جدول ها و سطرهای موجود در MSmerge_contents و MSmerge_tombstone را برای نسل هایی که مشترک ندارد، بیرون می کشد.

· موتور ادغام دستور های DELETE را از سطرهایی که از MSmerge_tombstone گرفته باز سازی می کند.

· موتور ادغام محتویات سطرهای جداول base در پایگاه داده را استخراج و تغییرات را دسته دسته می کند.

· تغییرات دسته دسته شده به مشترک اعمال می شود.

· نسل هایی که به مشترک ارسال شد در MSmerge_contents ثبت می شود.

دیاگرام کلی Replication ادغامی با فرایند سنکرون سازی در زیر آمده است.

هربار که موتور ادغام اجرا می شود، یک درخواست از منتشر کننده و مشترک می کند: "چیزی که ندارم را به من بدهید". با وجود سادگی این درخواست، اثری قدرتمند دارد.

موتور تراکنشی تغییراتی را که باید انجام شود را ذخیره و سپس به مشترک ارسال می کند. هنگامی که یک تغییر اعمال می شود، از موتور Replication حذف می شود. این باعث می شود کهreplication تراکنشی فقط روی تغییراتی که در صف منتظر هستند کار کند که بدین معناست که فقط از این نقطه زمانی به جلو را می فهمد. موتور ادغام، زمانی که تغییر انجام شد و محل تغییرات را تمیز نمی دهد. موتور ادغام توانایی فهمیدن هر چیزی که در گذشته رخ داده را دارد و فقط تغییراتی که الان وجود ندارد را منتقل می کند. خلاصه، جداول متاداده (metadata) زیرین موتور ادغام، مانند یک رکوردر پرواز است که تغییرات پایگاه داده را از زمانی که ان رکوردر (موتور ادغام) روشن شده، توضیح می دهد.

همین پروسه است که موتور ادغام را اینقدر انعطاف پذیر کرده است. تمام تغییرات در MSmerge_contents، MSmerge_tombstone و MSmerge_gethistory ثبت می شود. مهم نیست تغییر توسط موتور replication انجام شده یا توسط یک برنامه کاربردی؛ جدول های متاداده ادغامی، همه چیز را ثبت می کنند.

یکی از مشکلات موتورهای تراکنشی این است که تغییرات در گستره سه کمپوننت مجزا پخش شده است: log تراکنش روی منتشر کننده، پایگاه داده توزیع و مشترک(subscriber) . بنابراین، به شدت مشکل است که در حالی که Replication فعال است از وضعیت سیستم بتوان پشتیبان گرفت و یا سیستم را بازیابی (restore) کرد.

replication ادغامی این مشکل را نیز حل کرده است. جدول های متاداده ادغام در همان پایگاه داده ای قرار دارند که article های منتشر شونده شما قرار دارد. بنابراین، هنگامی که از پایگاه داده پشتیبان می گیرید، همزمان از متاداده ادغام نیز پشتیبان می گیرید؛ ان متاداده کاملا با محتویات جداول سنکرون می باشد. شما بعدا می توانید هر backup از پایگاه داده را از زمانی که publication ادغامی replicate کردن تغییرات را شروع کرده، بازیابی کنید و همه کارها را به عهده موتور ادغام بگذارید. مهم نیست تغییرات از کجا شروع شده، موتور ادغام خیلی ساده نسل هایی که روی منتشر شونده یا مشترک وجود ندارد را یافته و همه چیزهایی که وجود ندارد را ارسال می کند. لازم نیست درباره بازیابی سیستم به وضعیتی خاص نگران باشید موتور ادغام ترتیب همه کارها را می دهد.

طی بحث پیگیری تغییرات و سنکرون سازی به کرات از نسل نام بردیم. جدول های متاداده ی ادغام، حاوی تاریخچه کاملی از تمام سطوری است که از زمان اغاز replication ادغامی تغییر کرده اند. پرس و جوی متاداده برای تغییرات به صورت سطر به سطر به شدت ناکارا است. برای کاهش سربار، موتور ادغام تغییرات را به دسته هایی به نام نسل (generation) بسته بندی می کند که به حالت همه-یا-هیچ بین منتشر کننده و مشترک اعمال می شود. موتور replication می تواند بر اساس نسل بدنبال تغییرات روی منتشر کننده یا مشترک بگردد.

اعتبارسنجی

اعتبارسنجی یک publication ادغامی خیلی شبیه به اعتبارسنجی replication تراکنشی است. اعتبارسنجی را می توان در دو حالت انجام داد: فقط شمارش سطر و شمارش سطر بعلاوه checksum باینری. عملیات و سربار مانند replication تراکنشی است.

برای اعتبار سنجی یک publication کامل میتوانید sp_validatemergepublication و برای اعتبار سنجی فقط یک مشترک می توانید sp_validatemergesubscription را اجرا کنید، و یا می توانید آپشن –Validate را به عامل ادغام اضافه کنید.

پیاده کردن Replication ادغامی

در این تمرینها، با استفاده از پلیگاه داده AWMerge یک Replication ادغامی را پیکره بندی می کنیم.

تمرین اول: ساخت یک publication ادغامی

یک پایگاه داده به نام AWMergeSubscriber در همان نمونه ای که پایگاه داده ای که AWMerge روی ان است،بسازید.

1. در Object Browser، روی گره Replication کلیک راست مرده و New Publication را انتخاب کنید. روی Next کلیک کنید.

2. پایگاه داده AWMerge را انتخاب و روی Next کلیک کنید.

3. Merge Publication را انتخاب و روی Next کلیک کنید.

4. مطمئن شوید SQL Server 2008 انتخاب شده و روی Next کلیک کنید.

5. تمام جدول ها و UDF ها را انتخاب کنید، همانطوری که هنگام ساخت publication تراکنشی انجام دادید. روی Next کلیک کنید.

6. دوباره روی Next کلیک کنید. فیلترینگ انجام نخواهیم داد. دوباره روی Next کلیک کنید.

7. مطمئن شوید که Create A Snapshot Immediately انتخاب شده و تیک گزینه Schedule the Snapshot Agent To Run At The following Times برداشته شده باشد. روی Next کلیک کنید.

8. تنظیمات امنیتی را همانند publication تراکنشی مشخص کنید. روی Next کلیک کنید.

9. مطمئن شوید Create the Publication انتخاب شده باشد. روی Next کلیک کنید.

10. برای publication تان یک نام انتخاب کنید و Finish را کلیک کنید. بعد از اینکه publication ساخته شد روی Close کلیک کنید.

11. پایگاه داده AWMerge را برسی کنید، تا تمام تغییراتی که به triggerها، روال های ذخیره شده، ساختار جدول ها، ایندکس ها و view ها اعمال شده تا از پیگیری تغییر در replication ادغامی پشتیبانی کنند، را ببینید.

تمرین 2: ساخت یک Subscription ادغامی

1. Local Publication را بسط دهید، روی publication که بالا ساختید کلیک راست کرده و New Subscriptions را انتخاب کنید.

2. publication ادغامی تان را انتخاب و روی Next کلیک کنید.

3. مطمئن شوید گزینه Run All Agents As The Distributer انتخاب شده و روی Next کلیک کنید.

4. چک باکس کنار نمونه تان را انتخاب و پایگاه داده AWMergeSubscriber را از لیست پایی افاتدنی Subscription Database انتخاب کنبد.

5.

6. دکمه ... کنار مشترکتان را در پنجره Subscription Property بزنید.

7. گزینه Run Uner The SQL Server Agent Service Account را انتخاب و هر دو گزینه By Impersonating The Process Account. OK و بعد روی Next کلیک کنید.

8. در صفحه Synchronization Schedule، گزینه Run Continuously را از لیست پایین افتادنی Agent Schedule انتخاب و روی Next کلیک کنید.

9. مطمئن شوید مقدار Subscription Properties برابر Initialize Immediately است بعد روی Next کلیک کنید.

10. مقدار Subscription Type Of Server را پیش فرض نگه دارید و روی Next کلیک کنید.

11. مطمئن شوید گزینه Create Subscription(s) انتخاب شده باشد. روی Next کلیک کنید. و بعد Finish.

12. بعد از ساخته شدن Subscription روی Close کلیک کنید.

13. با استفاده از Replication Monitor، عامل ها، تاریخچه، و پیغام های خطا را برسی کنید.

14. پایگاه داده AwMergeSubscriber را برسی کنید تا ببینید بعد از اعمال Snapshot چه اشیائی ساخته شده.

15. منتشر کننده و مشترک را تغییر دهید تا ببینید چگونه داده ها در موتور حرکت می کند.

16. ناسازگاری داده ای تولید کنید و نحوه کشف و جل انرا مشاهده کنید.

خلاصه

· موتور ادغامی موتوری پرقدرت و انعطاف پذیر برای توزیع تغییرات است چون برای کاربرای سیار و نامتصل طراحی شده است.

· از انجا که موتور ادغام طوری نوشته شده تا از پس قطعی های زیاد و سنکرون داده های غیرمنتظره بر بیاید، می توان specification انرا که برای کاربران سیار و نامتصل طراحی شده، در محیط های سرور به سرور به کار برد.

· پیگیری تغییرات در یک مجموعه از جداول متاداده درون همان پایگاه داده ای که در حال انتشار و یا اشتراک است، رخ می دهد.

· از انجا که هم منتشر کننده و هم مشترک یک کپی کامل از تمام تغییرات انجام شده را نگه می دارند، موتور ادغام فقط یک درخواست ساده در هر چرخه می کند: "هر انچه را که ندارم برایم بفرستید".

Replication تراکنشی

replication تراکنشی به طور عمده توزیع یک طرفه تراکنش ها از منتشر کننده به مشترک را امکان پذیر می کند. از replication های تراکنشی می توان با پیکره بندی ها و option های مختلف استفاده کرد.

این بخش تمام معماری ها و ساختار هایی که می توان در انها از replication تراکنشی استفاده کرد را بر می شمرد و برخی از عملیات های درونی replication تراکنشی را توضیح می دهد.

پیگیری تغییر(Change tracking)

replication تراکنشی با استفاده از دو عامل replication مدیریت می شود: عامل Log Reader و عامل توزیع(Distribution agent) . عامل Log Reader مسئول انتقال تغییرات از log تراکنش ها روس منتشر کننده به پایگاه داده توزیع است. عامل توزیع مسئول انتقال دسته های تغییرات از پایگاه داده توزیع به هر مشترک.

عامل Log Reader

عامل Log Reader کارهای زیر را طی هر چرخه انجام می دهد:

1. به پایگاه داده توزیع متصل و replication watermark، آخرین شماره سری Log (LSN) طی چرخه قبلی، را از جدول MSlogreader_history می گیرد.

2. به log تراکنش منتشر کننده متصل و آخرین LSN را می یابد.

3. از LSN بعدی شروع به خواندن می کند تا به قدیمی ترین تراکنش باز برسد.

4. تراکنش ها را در جداول MSrepl_commands و MSrepl_transactions پایگاه داده توزیع، می نویسد. ترتیب تراکنش ها دقیقا همان ترتیبی است که روی منتشر کننده commit شده است.

5. Replication watremark را در جدول MSlogreader_history جلو می برد.

6. Replicated flag (نشانگر replicate شدن) موجود در log تراکنش ها را برای تمام تراکنش هایی که با موفقیت به پایگاه داده توزیع نوشته شده، set می کند.

7. اطلاعات خطا و تاریخچه(history) را در پایگاه داده توزیع ثبت می کند.

عامل توزیع(Distribution Agent)

عامل توزیع در هر چرخه کارهای زیر را انجام می دهد:

1. به پایگاه داده توزیع متصل شده و آخرین تراکنش اعمال شده به مشترک را از جدول MSdistribution_history می یابد.

2. تمام تراکنش هایی که برای یک مشترک در حالت معلق (pending) مانده را جمع می کند.

3. تمام تراکنش ها را دسته دسته می کند.

4. به مشترک متصل شده و دسته های تراکنش ها را اعمال می کند.

5. مدخل جدول MSdistribution_history را با شماره سری آخرین تراکنش که اِعمال شد آپدیت می کند.

6. اطلاعات خطا و تاریخچه(history) را در پایگاه داده توزیع ثبت می کند.

نکته: پاکسازی پایگاه داده توزیع

عامل توزیع مستقیما مدخل های جدول توزیع که با موفقیت به تمام مشترکین نوشته شده را پاکسازی نمی کند. یک کار جدا (به نام عامل پاکسازی(cleanup agent))، به طور دوره ای اجرا می شود و تراکنش هایی که به تمام مشترکین فرستاده شده را حذف می کند. این کار برای بالابردن کارایی مجزا شده است و عامل توزیع را قادر می سازد تا سریعتر از انچه عامل Log Reader تراکنش ها را به پایگاه داده توزیع می نوشت، تراکنش ها رابه مشترکین ارسال کند. این معماری پردازشی تضمین می کند که عامل توزیع حین کار، حتی وقتی تعداد مشترکین خیلی زیاد باشد، ایجاد گلوگاه (bottleneck) نمی کند.

تاثیر بر پایگاه داده

از انجا که موتور replication تضمین می کند تمام تراکنش های نوشته شده در منتشر کننده توسط مشترکین دریافت می شود، فشار زیادی بر پایگاه داده منتشر شده وجود دارد که باید مد نظر داشته باشید.

اگر پایگاه داده تان در مدل Simple recovery است، بخش راکد log در هر checkpoint حذف می شود.

معمولا، پشتیبان گیری از log تراکنش در پایان فرایند پشتیبان گیری بخش های راکد log را حذف می کند.موتور پشتیبان گیری با شروع از اول log و ادامه تا رسیدن به قدیمی ترین تراکنش باز، قسمت های راکد را حذف می کند. بعد از اینکه به قدیمی ترین تراکنش باز رسید، فرایند پشتیبان گیری متوقف می شود. برای تشخیص تراکنش های باز از تراکنش های commited، پروسه پشتیبان گیری یک flag یک بیتی را در هر رکورد از log تراکنش می خواند که نشانگر commited بودن یا نبودن ان تراکنش است.

موتور replication باید تضمین کند که تمام تراکنش های منتشر کننده به مشترک می رسد. اما پروسه پشتیبانی گیری از log تراکنش و یا پروسه checkpoint در مدل Simple Recovery ممکن است با این پروسه تداخل ایجاد کند. اگر SQL Server اجازه دهد بخش راکد log، قبل از اینکه عامل Log Reader بتواند تراکنش ها را در پایگاه داده توزیع بنویسد، حذف شود، تراکنش ها ممکن است گم شود. به همین خاطر، هنگامی که یک پایگاه داده، در یک replication تراکنشی مشارکت دارد، یک flag دوم درون یک رکورد log تراکنش فعال می شود. پشتیبان گیری از log تراکنش، در این حالت هم، بخش راکد log را پردازش می کند، اما مجاز نیست تا وقتی که هر دو flag، commited , replicated ست(set) نشده باشد، رکوردی را پاک کند. بنابراین، اگر عامل Log Reader تراکنش ها را به پایگاه داده توزیع ننویسد، log تراکنش روی منتشر کننده بزرگ می شود حتی اگر پشتیبان گیری از log تراکنش، و یا checkpoint گیری از پایگاه داده در مدلSimple Recovery، انجام شود. نتیجه اینکه replication تراکنشی با هر مدل recovery سازگار است.

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

گزینه های تراکنش(Transactional Options)

همان طور که در تصویر زیر می بینید، می توان replication تراکنشی را با دو گزینه پیکره بندی کنید، گزینه آپدیت صفی مشترک و آپدیت بلادرنگ مشترک.

گزینه آپدیت بلافاصله مشترک(Immediate Updating Subsciber)

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

پروسه اعمال تغییرات در مشترکی که با گزینه آپدیت بلادرنگ مشترک پیکره بندی شده به این صورت است:

· برنامه کاربردی تراکنشی را در مشترک صادر می کند.

· trigger اجرا می شود.

· Trigger از Microsoft distributed Transaction Coordinator (MS DTV) می خواهد تا به منتشر کننده متصل و تراکنش را مجددا صادر کند.

· تراکنش روی منتشر کننده با موفقیت تمام(commit) می شود.

· trigger روی مشترک با موفقیت تمام (commit) می شود.

· تراکنش با موفقیت روی مشترک تمام (commit) می شود.

مشکل اصلی در معماری های با درجه دسترس پذیری بالا (high-availability)، با آپدیت بلادرنگ مشترک، این است که تغیرات باید به منتشر کننده اعمال شود. اگر منتشر کننده در دسترس نباشد، تراکنش توزیع شده شکست می خورد(fail). چون تراکنش توزیع شده از طریق یک Trigger اجرا می شود، تراکنش اغاز کننده هم شکست می خورد و Rollback می شود. بنابراین، آپدیت بلادرنگ مشترک یک replication ناسازگار برای محیط های دسترس پذیری بالا است.

گزینه آپدیت صفی مشترک(Queued Updating subscriber)

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

فرایند اعمال تغییرات به مشترک با این گزینه به این شکل است:

· برنامه یک تراکنش را صادر می کند.

· trigger آغاز می شود.

· Trigger تراکنش را در یک صف (جدولی از پایگاه داده) قرار می دهد.

· Trigger با موفقیت تمام می شود.

· تراکنش با موفقیت تمام می شود.

عامل صف خوان (Queue Reader Agent) در فواصل معین، صف را به منتشر کننده انتقال و تمام تراکنش ها را صادر می کند. تغییراتی که به منتشر کننده انتقال می یابد دوباره به مشترک اولی که تراکنش را آغاز کرد، اعمال نمی شود. برای این کار به یک ستون timestamp در جدول نیاز است.

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

برتری گزینه آپدیت صفی مشترک این است که هنگامی که منتشر کننده دوباره آنلاین می شود، به طور خودکار میتوان تمام تغییراتی که در زمان عدم دسترسی به منتشر کننده، برروی مشترک انجام شده را به ان منتشر کننده اعمال کرد. تمام برنامه ها و پردازش هایی که در معماری های دیگر برای fail back لازم است در اینجا حذف شده است، چون آپدیت صفی مشترک به طور توکار قابلیت up to date کردن منتشر کننده را بعد از یک Failover داراست. تنها گام مورد نیاز برای fail back به منتشر کننده، repoint کردن برنامه های کاربردی است.

نکته: یک publication تراکنشی را می توان با هر دو گزینه آپدیت بلادرنگ مشترک و آپدیت صفی مشترک پیکره بندی کرد. از گزینه آپدیت صفی مشترک می توان در هنگام عدم دسترسی به منتشر کننده به عنوان یک مکانیسم failover استفاده کرد.

معماریهای تراکنشی

علاوه بر عملیات یک طرفه معمولی، که پیش فرض است، می توان Replication تراکنشی را بر اساس دو معماری متداول دیگر نیز پیکره بندی کرد. این معماری ها را با هیچ مکانیسمی در موتور replication اشتباه نگیرید. این معماری ها، Replication تراکنشی یک طرفه معمولی را بدون هیچ گزینه اپدیتی، پیاده سازی می کنند. پیاده سازی انجام شده باعث جریان تغییرات بین منتشر کننده و مشترک می شود، با این حال همچنان یک موتور تراکنشی است.

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

Replication نظیر به نظیر

replication نظیر به نظیر معماری است که در SQL Server 2005 معرفی شد و فقط در نسخه Enterprise موجود است. اصل این معماری این است که replication تراکنشی می تواند داده ها را بین دو یا چند نظیر (peer) جا به جا کند. دیاگرامی از معماری نظیر به نظیر در زیر آمده است.

replication نظیر به نظیر پیاده سازی replication تراکنشی است. ایده اصلی این است که شما می توانید با استفاده از replication تراکنشی یک مجموعه از جداول را برداشته و از پایگاه داده 1 به پایگاه داده 2 Replicate کنید. می توانید با همان مجموعه داده روی پایگاه داده 2، publication بسازید و ان را با استفاده از replication تراکنشی به پایگاه داده 1 replicate کنید.

در عمل، تمام پایگاه های داده ای که در معماری نظیر به نظیر مشارکت دارند، تمام تغییرات را به تمام پایگاه های داده دیگر Replicate می کنند. برای جلوگیری از اینکه تراکنش ها در این معماری بدون پایان بچرخند، باید در جدول هایی که در replication مشارکت دارند یک ستون rowguid داشته باشید، که موتور را قادر می سازد پایگاه داده آغازگر تراکنش را تشخیص دهد.

replication نظیر به نظیر شرایط سفت و سختی دارد که باید بر آورده شود:

· هر نظیر باید توزیع کننده خود را داشته باشد.

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

· گزینه های آپدیت بلافاصله و صفی موجود نمی باشد.

· ناسازگاری داده ها رخ نمی دهد.

replication دو طرفه

پیکره بندی replication دوطرفه کمی با replication نظیر به نظیر متفاوت است. این معماری یک نوع replication تراکنشی است. همانطور که در تصویر زیر امده مجموعه جداولی که از پایگاه داده 1 به پایگاه داده 2 replicate می شود همان مجموعه جداولی است که از پایگاه داده 2 به پایگاه داده 1 replicate می شود.

برای جلوگیری از چرخیدن (looping) تراکنش ها بین دو پایگاه داده، باید به هر subscription ( اشتراک)، یک پارامتر @loopback_detection بیفزایید.

هر چند replication دو طرفه را می توان به عنوان زیر مجموعه ای از replication نظیر به نظیر انجام داد، هنگام پیاده کردن این replication کارایی بالاتری بدست می اورید.

در این معماری، نیازی نیست هر منتشرکننده یک توزیع کننده داشته باشد و جداولی که در replication مشارکت دارند نیازی به ستون rowguid ندارند. ساختار جداول هم می تواند متفاوت باشد، هر چند من با این نمونه برخورد نداشته ام.

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

مانیتورینگ

معمولا از Replication Monitor برای مانیتور کردن معماری های replication استفاده می شود. درون Replication Monitor، شما می توانید آماری از وضعیت تمام publication ها،Subscription ها و عامل ها را ببینید. همچنین می توانید اطلاعات تاریخچه وضعیت (status history) و خطا ها را به منظور عیب یابی، ببینید.

یکی از بزرگترین مشکلات محیط های replication در نسخه های قبلی SQL Server مربوط به گلوگاه (bottleneck) بود. با استفاده از یک روال ذخیره شده سیستمی (System-store procedure) به نام sp_browsereplcmds که در پایگاه داده توزیع وجود داشت، تعیین تعداد تراکنش هایی که موتور replication در پردازش انها عقب افتاده بود، سر راست بود. با این حال، غیر ممکن بود بتوان زمانی که طول می کشید تا موتور replication عقب افتادگی را جبران کند (تراکنش های عقب افتاده را انجام دهد)، را تعیین کرد، چون اطلاعات زمانی بین محیط نگهداری نمی شد.

درحالی که تغییرات توسط عامل Log Reader و عامل توزیع انتقال می یابد، موتور، آمار سرعت انتقال داده و مدت زمان انتقال داده را نگهداری می کند. با استفاده از این امار، Replication Monitor می تواند پیوسته اطلاعاتی را نمایش دهد که به شما نشان می دهد چند تراکنش دیگر باید به مشترکین فرستاده شود، بعلاوه مدت زمان تخمینی جبران عقب افتادگی.

هر چند امار Replication Monitor اطلاعات وضعیتی (status) خوبی را نشان می دهد، جزئیات دقیقتری را درمورد میزان عقب افتادگی مشترکین به دست نمی دهد. Replication Monitor برای تاخیر تنها یک رقم نشان می دهد، Administrator نمی تواند مشخص کند که گلوگاه (bottleneck) در عامل Log Reader است , یا اینکه عامل توزیع سعی در جبران عقب افتادگی دارد. به همین خاطر tracer token ها معرفی شدند تا این جزئیات را فراهم آورند.

tracer token یک تراکنش مخصوص است که برای موتور replication صادر می شود. Tracer token مانند دیگر تراکنش ها به log تراکنش ها فرستاده می شود. عاملین replication، tracer token را مانند دیگر تراکنش ها، در ساختار (معماری) انتقال می دهند. انچه tracer token را ویژه می کند، موتور replication تراکنش مخصوص را شناخته و امار زمانی ان را حین انتقال در ساختار معماری ثبت می کند. با استفاده از یک tracer token، می توانید زمان دقیقی که طول کشید تا ان token به پایگاه داده توزیع انتقال یابد و یا مدت زمانی که طول کشید تا ان به هر مشترک فرستاده شود، را داشته باشید؛ همچنین می توانید مجموع تاخیرهای کلی از منتشر کننده تا مشترک را بدست اورید.

با این اطلاعات، حالا می توانید تمام گلوگاه ها را در معماری replication ایزوله و رفع کنید.

اعتبارسنجی

موتور replication تضمین می کند که تراکنش هایی که از منتشر کننده به مشترک انتقال می یابد به همان ترتیبی است که صادر شد. از انجا که منتشر کننده و مشترک معمولا پایگاه های داده ای بر روی نمونه های مختلفی از SQL Server هستند که می توانند از لحاظ فیزیکی جدا باشند، یک سوال همواره مطرح است: از کجا بدانیم دو پایگاه داده سنکرون هستند؟

موتور replication مکانیسمی برای اعتبارسنجی سنکرون سازی دارد. دو روال ذخیره شده سیستمی فراهم شده تا اعتبار سنجی را انجام دهد:sp_publication_validation و sp_article_validation.

sp_publication_validation روال sp_article_validation را برای تمام Article های درون Publication، اجرا می کند.

هر دوی این روال ها می توانند با دو روش اعتبارسنجی را انجام دهند:

1. فقط تعداد سطرها

2. تعداد سطرها و checksum باینری

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

گسترده ترین روش اعتبارسنجی شمارش تعداد سطرها و انجام یک checksum باینری است. تعداد سطرهای جداول منتشرکننده و مشترک تطبیق داده می شوند. علاوه بر ان، یک checksum باینری محاسبه و مقایسه می شود. این روش تمام اختلافات تعداد سطور و محتوای ان ها را کشف می کند. با این حال، عملیاتی پر هزینه است که باعث سربار(overhead) در پردازش می شود. به خاطر حجم سربار، از این روش هر از چند گاه باید استفاده کرد.

اعنبار سنجی ممکن است باعت سربار زیاد، مخصوصا در محیط هایی که تعداد مشترکین یک publication زیاد است و یا publication ها دارای تعداد زیادیarticle هستند، بشود. معمولا روش تعداد سطور را روزانه و روش تعداد سطور و checksum باینری به صورت هفتگی انجام می شود.

پیاده سازی replication تراکنشی

در اینجا به طور عملی، با استفاده از پایگاه داده AWTransactional، یک replicationتراکنشی را پیکره بندی می کنیم.

تمرین 1: ساخت publication

یک publication می سازیم.

1. SSMS را باز و به نمونه ای که برای replication استفاده می کنید، متصل شوید.

2. پایگاه داده ای به نام AWTranSubscriber روی همان نمونه ای که پایگاه داده AWTransactional را دارد بسازید.

3. اگر لازم است گره Replication را بسط دهید، روی Local Publications کلیک راست کرده و New Publication را انتخاب کنید. روی Next کلیک کنید.

4. پایگاه داده AWTransactional را انتخاب کنید و روی Next کلیک کنید.

5. Transcational Publication را انتخاب و روی Next کلیک کنید.

6. مانند شکل زیر، تمام جدول ها و توابع کاربر-تعریف (UDF) را انتخاب و روی Next کلیک کنید.

نکته: UDF ها

به این خاطر UDF ها را در publication قرار می دهیم که جداولی در پایگاه داده AdventureWorks وجود دارد که دارای محدودیت هایی(constraint) هستند که با UDF تعریف می شوند. اگر انها ساخته نشوند و یا به publication اضافه نشوند، اِعمال snapshot با شکست مواجه می شود.

7. فیلتری اعمال نمی کنیم پس روی Next کلیک کنید.

8. تیک گزینه "Create a Snapshot Immediately and Keep Snapshot available to Initialize Subscriptions" را زده و روی Next کلیک کنید.

9. Security settings (تنظیمات امنیتی) را انتخاب کنید.

10. گزینه های "Run under SQL Server Agent Service Account" و "By Impersonating Process Account" را انتخاب و روی Next کلیک کنید.

تذکر: تنظیمات امنیتی عامل

توصیه می شود عاملین Replication را تحت اکانت SQL Server Agent servcie اجرا نکنید. اکانت های عامل replication باید دارای مینیمم مجوزها (permission) در محیط باشند، اکانت SQL Server Agent service ان مجوزها را افزایش می دهد.

11. روی Next کلیک کنید. مطمئن شوید گزینه "Create the Publication" انتخاب شده است. روی Next کلیک کنید.

12. به publication یک نام داده و روی Finish کلیک کنید.

13. بعد از New Publication Wizard ، publication را ساخت، روی Close کلیک کنید.

تمرین 2: ساخت Subscription

1. در این تمرین، یک Subscription برای publication ی که در بالا ساختید، می سازیم.

2. Local Publications را بسط دهید، روی publication که الان ساختید کلیک راست کنید، New Subscriptions را انتخاب کنید. در New Subscription Wizard روی Next کلیک کنید.

3. مطمئن شوید publication شما انتخاب شده و روی Next کلیک کنید.

4. مطمئن شوید گزینه "Run All Agents At the Distribute" انتخاب شده باشد و روی Next کلیک کنید.

5. چک باکس کنار نمونه تان را انتخاب کنید. از منوی پایین افتادنی Subscription Database گزینهDatabase AWTranSubscriber را انتخاب کنید.

6. در صفحه Distribution Agent Security، دکمه ... کنار مشترکتان (subscriber) در پنجره Subscription Properties را انتخاب کنید.

7. گزینه های "Run under SQL Server Agent Service Account" و هر دو گزینه پایین "By Impersonating the Process Account" ، Connect to Distributer و Connect to Subscriber را انتخاب کنید. Ok و Next را کلیک کنید.

8. در صفحه Synchronization Schedule، مطمئن شوید Agent Schedule برابر Continuously (مقدار پیش فرض) است و روی Next کلیک کنید.

9. مطمئن شوید Subscription Properties برابر Initialize Immediately است و روی Next کلیک کنید.

10. مطمئن شوید گزینه Create Subscription(s) انتخاب شده باشد و روی Next و بعد finish کلیک کنید.

11. بعد از ساخته شدن Subscription روی Close کلیک کنید.

تمرین 3: استفاده از Replication Monitor

در این تمرین، از Replication Monitor برای مشاهده اطلاعاتی درباره publication و subscription استفاده و کمی با tracer token کار می کنیم.

1. در Object Explorer، روی Replication کلیک راست کرده و Launch Replication Monitor را انتخاب کنید.

2. در Replication Monitor، بخش ها و تب های مختلف را برسی کنید و اطلاعاتی که الان درباره publication و subscription ای که ساختیم، نمایش می دهد، را ببینید. با کلیک راست برروی هر مدخل می توان به ویژگی های ان شی و جزئیات بیشتر دست پیدا کرد.

3. چند Tracer token ارسال و نتایج را ببینید.

خلاصه بخش

· Replication تراکنشی از عامل Log Reader برای انتقال تراکنش ها از log تراکنش های منتشر کننده به پایگاه داده توزیع استفاده می کند. عامل توزیع، سپس تراکنش ها را از پایگاه داده توزیع به تک تک مشترکین انتقال می دهد.

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

· Replication تراکنشی با 3 معماری مختلف قابل پیکره بندی است. معماری پیش فرض داشتن یک منتشر کننده با یک یا چند مشترک است. به عنوان جایگزین می توان Replication تراکنشی را با معماری نظیر به نظیر و دوطرفه پیکره بندی کرد.

· Administrator می تواند با استفاده از tracer token، آمار زمانی درون replication را از منتشر کننده به مشترک، یا از توزیع کننده به مشترک بدست اورد. از این امار برای مانیتور کردن تاخیر های نقطه به نقطه استفاده می شود.

هدف اصلی از replication توزیع داده از یک پایگاه داده master به یک یا چند پایگاه داده ثانویه است. از انجا که replication یک کپی از داده را به شکل سنکرون با کپی اصلی پایگاه داده master نگهداری می کند، از این تکنولوژی می توان برای بالا بردن دسترس پذیری (availability) برنامه ها استفاده کرد.

در این بخش مروری ابتدایی بر موتور replication ، به علاوه ی گزینه هایی که برای توزیع داده می توانید استفاده کنید، خواهیم داشت. همچنین توضیح خواهیم داد چگونه می توان از مکانیسم های توزیع داده استفاده کرد تا راهکاری(solution) همواره در دسترس با زمان تاخیر به شدت کوتاه را فراهم اوریم که بتواند در صورت نیاز به failback، زمان خاموشی و عدم دسترسی برنامه را به کمترین حد برساند.

برای ادامه به ابزار زیر نیاز داریم:

یک نسخه از Microsoft SQL Server 2008، نسخه Enterprise، استاندارد و یا Developer.

پایگاه داده AdventureBooks باید نصب شود

دو پایگاه داده با نام های AWTransactional و AWMerge که کپی پایگاه داده AdventureBooks است.

توجه: اکانت های سرویس (SERVICE ACCOUNTS)

موتور replication برای امنیت بیشتر از اکانت های نام دار (named accounts) استفاده می کند، بنابر این اکانت سرویس که SQL Server و SQL Server Agent تحت ان اجرا می شوند باید اکانت local و یا اکانت دامین باشد. برای این اکانت سرویس نمی توان از localsystem استفاده کرد.

مروری بر replication

Replication به عنوان یک مکانیسم توزیع داده طراحی شده است. در پایین ترین سطح، تغییراتی که به یک پایگاه داده اعمال می شود به یک یا چند target (هدف) توزیع می شود. هسته موتور replication، برای پیاده سازی های خیلی انعطاف پذیر طراحی شده است، اما معماری هسته را می توان به کار بست تا قابلیت دسترس پذیری (availibility) یک پایگاه داده را افزایش داد، چون یک کپی اضافه از داده ها، به صورت سنکرون با کپی اصلی نگه داری می شود.

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

کمپوننت های replication

داده ای که قرار است replicate (کپی) شود توسط سه کمپوننت مرکزی تعریف می شود.

Article

Article بنیادی ترین عنصر سازنده replication است و درشت ترین (granular) سطح توزیع داده را تعریف می کند. یک Article را می توان بر اساس یک جدول، view، روال ذخیره شده(stored procedure) و تابع تعریف کرد.

مربوط ترین نوع Article برای دسترس پذیری بالا بر اساس جدول تعریف می شود. Article مجموعه داده ای را مشخص می کند که SQL Server به یک یا چند پایگاه داده replicate می کند.

Publication (انتشارات)

یک publication درشت ترین سطح در معماری replication است. Publication به معنای گروه بندی Article های تعریف کننده مجموعه replication است.

Filter

از این لحاظ که replication قادر است فقط بخشی از پایگاه داده را کپی کند، در میان تکنولوژی های با قابلیت دسترسی بالا (high-availability) بی نظیر است. با اعمال فیلتر به Article می توان مجموعه داده ای که قرار است replicate شود را محدود کرد.

Article ها را می توان بر اساس سطر یا ستون فیلتر کرد.

داده ای که درون replication جابجا می شود را Publication یا مجموعه داده می گویند. این داده همیشه درون context زیرمجموعه داده ای است که بر اساس Article های تعریف شده و سطر و ستون های فیلتر شده، برای Replication مشخص شده است. این ویژگی یکتای Replication است که ما را قادر می سازد دسترس پذیری به فقط یک بخش از پایگاه داده را بالا ببریم.

یک فیلتر ستونی یک زیر مجموعه از ستون های جدول را مشخص می کند. فیلتر ستونی اجازه replicate کردن داده را می دهد ولی داده های حساس را می توان خارج کرد.

یک فیلتر سطری تعداد سطرهایی که قرار است replicate شود را محدود می کند. از سه نوع فیلتر سطری می توان استفاده کرد:

• فیلتر سطری استاتیک هنگامی که Article تولید می شود پیش تعریف می شود و Article را، سوای Subscriber، محدود به یک زیر مجموعه از داده ها می کند. یک مثال از فیتلر سطری استاتیک در زیر امده است:

   1: WHERE State = 'TX'

• فیلتر سطری پویا، فقط در Replication ادغامی (merge) موجود است، امکان تعریف فیلتری را فراهم می اورد که بر روی یک Article ثابت نیست. در زمان پروسه سنکرون سازی، فیلتر دوباره، بر اساس اطلاعات مشترک (Subscriber) محاسبه می شود تا یک publication بتواند مجموعه متفاوتی از داده را به هر مشترک توزیع کند. یک نمونه از این فیلتر ها در زیر امده است:

   1: WHERE UserName = suser_sname()

• فیلتر join، فقط برای Replication ادغامی، امکان فیلتر کردن یک جدول را براساس رابطه اش با یک جدول parent (والد) فراهم می اورد. برای نمونه، ممکن است جدولی شامل مشتری ها، سفارش هایشان و جزئیات ان سفارش ها داشته باشید. اگر جدول مشتری های شما دارای فیلتری باشد که مجموعه داده ها را به یک حالت خاص محدود کند، شما احتمالا می خواهید جدول های سفارش ها و جزئیات سفارش ها را نیز به همان شکل فیلتر کنید. با استفاده از فیلتری join، می توانید جدول مشتری ها را بر اساس یک حالت فیلتر و سپس جداول سفارش ها و جرئیات سفارش ها را بر اساس زیر مجموعه ی جدول مشتری ها که replicate می شود، فیلتر کنید.

نکته

هر چند Replication توانایی اعمال فیلترها به Article ها را داراست، این قابلیت در معماری های برای دسترسی بالا به کار نمی رود. یک معماری دسترسی بالا بیشتر درگیر نگهداری یک کپی کامل و منسجم از داده ها بر روی یک نمونه مجزای SQL Server است.

نقش ها در Replication

با سه نقش (role) مختلف می توان پایگاه داده – و به تبع ان نمونه هایی (instance) که پایگاه داده را میزبانی می کند – را پیکره بندی کرد:

Publisher (منتشر کننده) کپی داده master را درون یک معماری Replication نگهداری می کند. نمونه ای(instance) که میزبان پایگاه داده Publisher است را با publication ی که مجموعه داده های Replication را مشخص می کند، پیکره بندی می کنیم.

Subscriber (مشترک) پایگاه داده ای است، که تغییرات را از موتور Replication که بر اساس publication تعریف شده، دریافت می کند.

Distributer (توزیع کننده) موتور اصلی درون معماری Replication است. پایگاه داده توزیع(distribution database) ، برروی نمونه ای ذخیره شده که به عنوان Distributer پیکره بندی شده، نصب شده است. در تمام معماری های Replication، Distributer جایی است که تمام عاملان (agent) Replication به طور پیش فرض، در حال اجرا هستند.

یک نمونه از SQL Server را می توان به عنوان توزیع کننده پیکره بندی کرد. یک پایگاه داده را می توان به عنوان منتشر کننده، مشترک و یا هر دو پیکره بندی کرد.

توپولوژی های Replication

توپولوژی Replication یک دیاگرام جریان فرایند (process flow diagram) را فراهم می اورد که نحوه جریان داده درون معماری Replication را توصیف می کند.

توپولوزی منتشر کننده مرکزی

یک توپولوژی منتشر کننده مرکزی شامل یک منتشر کننده است که یک یا چند مشترک دارد. منتشر کننده مرکزی حاوی کپی master از داده ها است و برای بر پا سازی معماری Replication به کار می رود. در این توپولوژی، تغییرات داده معمولا در یک نقطه، یعنی منتشر کننده، رخ می دهد و سپس، همانطور که در شکل زیر امده، به یک یا چند مشترک جریان می یابد. منتشر کننده مرکزی متداول ترین توپولوژی مورد استفاده در Replication است.

توپولوژی مشترک مرکزی

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

توپولوزی های دیگر

در منابع مختلف توپولوژی های Replication مختلفی مستند شده است، به طور ساده همه انها نمونه ای تغییر یافته از توپولوژی های منتشر کننده مرکزی و مشترک مرکزی هستند. یکی از این توپولوژی ها "توپولوژی دوطرفه" است که در واقع دو منتشر کننده مرکزی است که روی هم قرار گرفته و واقعا یک توپولوژی نیست؛ بلکه یک پیاده سازی ساختاری از Replication تراکنشی است. دو توپولوژی دیگر شامل یک منتشر کننده مرکزی همراه با یک توزیع کننده از راه دور(remote distributer) و یک مشترک مرکزی همراه با توزیع کننده از راه دور است. این توپولوژی ها نیز به ترتیب یک منتشر کننده مرکزی و مشترک مرکزی هستند؛ محل قرارگیری توزیع کننده یک موضوع مربوط به پیاده سازی فیزیکی است و در دیاگرام جریان فرایند business قرار نمی گیرد.

عاملین Replication (Replication Agents)

هنگام اغاز کار با Replication، بیشتر مردم از نحوه برخورد موتور Replication با حالت های مختلف عدم موفقیت (failure) گیج می شوند. روی هم رفته، SQL Server نمی داند چگونه یک تراکنش را time out کند و یا یک عملیات را دوباره انجام دهد.

نکته اصولی که باید درباره Replication بدانیم این است که ان جزئی از موتور هسته SQL Server نیست. Replication با استفاده از یک سری فایل های اجرایی به نام عاملین Replication (replication agents) ، خارج از موتور SQL Server کار می کند. به این صورت موتور Replication در واقع مانند برنامه های دیگری است که به SQL Server متصل و داده را پردازش می کند. به عنوان یک برنامه کاربردی، موتور Replication مانند هر برنامه دیگری که باید اتصالی Object Linking and Embedding database (OLE DB) با SQL Server برقرار کند، محدود است و مانند انها واکنش نشان می دهد.

عامل Snapshot (Snapshot agent)

عامل Snapshot در واقع همان snapshot.exe است. این عامل مسئول استخراج داده و شمائی (schema) است که قرار است از منتشر کننده به مشترک فرستاده شود. Snapshot.exe در Replication ادغامی، تراکنشی و snapshot استفاده می شود.

عامل Log Reader

عامل Log Reader، همان logread.exe، فقط در Replication تراکنشی استفاده می شود. از ان برای استخراج تراکنش های commit شده از log تراکنشی موجود در منتشر کننده که باید replicate شود، استفاده می شود. بعد از استخراج تراکنش های commit شده، عامل Log Reader اطمینان حاصل می کند که تمام تراکنش ها، دقیقا به همان ترتیبی که در منتشر کننده صادر شده، دوباره در پایگاه داده توزیع نوشته می شود. بسیار حیاتی است که این تراکنش ها به همان ترتیب به مشترک اعمال شود.

عامل توزیع (Distribution Agent)

عامل توزیع، distrib.exe، با Replication های تراکنشی و snapshot استفاده می شود. عامل توزیع دو کار انجام می دهد: اعمال کردن snapshot ها و ارسال تراکنش ها. عامل توزیع مسئول اعمال تمام snapshot های تولید شده در Replication تراکنشی و snapshot، به تمام مشترک ها است. ان همچنین مسئول اعمال تمام تراکنش هایی که عامل Log Reader در پایگاه داده توزیع نوشته، به تمام مشترکین است.

عامل ادغام (Merge Agent)

عامل ادغام، replmerg.exe، برای Replication ادغامی به کار می رود. عامل ادغام snapshot تولید شده هنگام initialize شدن مشترک را، اعمال می کند. عامل ادغام همچنین مسئول مبادله تراکنش ها بین منتشر کننده و مشترک است.

عامل صف خوان (Queue Reader Agent)

عامل صف خوان، qrdrsvc.exe، فقط زمانی که گزینه آپدیت صف بندی شده (Queued Updating) فعال باشد مورد استفاده قرار می گیرد. عامل صف خوان مسئول انتقال صف روی مشترک به منتشر کننده است.

پروفایل های عامل (Agent Profile)

تمام عاملین Replication دارای پارامترهای زیادی برای پیکره بندی است که رفتار ان ها را تغییر می دهد. 12 تا از متداول ترین گزینه ها با هم ترکیب و واحدی به نام پروفایل عامل تشکیل شده است. برخی از گزینه های متداول تری که می توانید پیکره بندی کنید در زیر امده است:

Polling Interval – مشخص می کند عامل چند وقت یکبار دنبال تراکنش جدیدی برا replicate کردن بگردد. مقدار پیش فرض 5 ثانیه است.

Query timeout – مشخص می کند عامل چقدر منتظر اتمام یک پرس و جو بماند. مقدار پیش فرض 1800 ثانیه است.

Login timeout - مشخص می کند عامل چقدر منتظر ساخت اتصال (connection) بماند. مقدار پیش فرض 15 ثانیه است.

روش های Replication

موتور replication سه روش متفاوت برای replicate کردن داده ها دارد: snapshot replication، replication تراکنشی و replication ادغامی.

Snapshot replication

Snapshot replication تمام مجموعه داده ها را گرفته و در هر چرخه از موتور replication ان ها را ارسال می کند. این داده یک کپی کامل از داده ها است که به مشترک اعمال می شود. تمام تراکنش هایی که روی منتشر کننده رخ داده، گرفته و دفعه بعد که snapshot اجرا می شود، به مشترک فرستاده می شود.

Snapshot replication از عامل Snapshot و عامل توزیع استفاده می کند. هنگامی که snapshot اغاز می شود، عامل Snapshot شماء (schema) را استخراج و داده ها را به پوشه snapshot، BCP (bulk copy program) می کند (به صورت دسته ای کپی می کند).

توجه: پوشه snapshot

پوشه snapshot دایرکتوری است که هنگام پیکره بندی replication مشخص می کنید، و از ان به عنوان مکان پیش فرض snapshot استفاده می شود. هنگام ساخت یک publication، برای ان publication می توانید محلی متفاوت را به عنوان پوشه snapshot مشخص کنید.

بعد از اینکه شماء و تمام داده ها استخراج شد، عامل Snapshot خاموش می شود (بسته می شود). از انجا عامل توزیع ادامه می دهد و تمام snapshotها را به تمام مشترکین(Subscribers) اعمال می کند. طی این فرایند، جدول های موجود حذف و بر اساس اسکریپت های شماء موجود در پوشه snapshot دوباره ساخته می شوند؛ سپس با استفاده از کپی دسته ای (BCP)، داده ها به درون جدول های تک تک مشترکین کپی می شود.

توجه: اِعمال یک snapshot

به طور پیش فرض، یک snapshot ساختار جدول، کلید اصلی، اندیس clustered، constraint های یکتا و داده ها را به مشترک (Subscriber) اعمال می کند. بقیه اشیاء مرتبط با جدول مانند check constraint ها و foreign key constraint ها فرستاده نمی شود. با تغییر ویژگی های article (article properties) می توانید این رفتار پیش فرض را تغییر دهید.

هنگام اعمال یک snapshot چهار گزینه وجود دارد. گزینه پیش فرض حذف شی موجود و دوباره سازی ان است. می توانید انتخاب کنید که جدول موجود بدون تغییر بماند، داده های مشابه داده های snapshot ارسال شده، حذف شود، و یا ساختار جدول دست نخورد اما کوچک (truncate) شود تا فقط داده های snapshot را بپذیرد.

در اینجا ما از تنظیمات پیش فرض استفاده می کنیم.

یک دیاگرام از فرایند انتقال داده با snapshot replication در زیر امده است.

Snapshot replication تمام داده های مشترک را جایگزین می کند. از ان معمولا برای بالا بردن دسترس پذیری استفاده نمی شود، چون تراکنش هایی که بین اِعمال های snapshot به مشترک، صادر می شود، ارسال نمی شود.

Replication تراکنشی

هنگام اغازReplication تراکنشی، یک snapshot اولیه به مشترک (Subscriber) اعمال می شود تا مطمئن شویم که دو پایگاه داده با هم سنکرون هستند. با ادامه صدور تراکنش ها برای منتشر کننده، موتور replication انها را به مشترک اعمال می کند. جریان افزایش (incremental) تراکنش ها از منتشر کننده به مشترک، replication تراکنشی را گزینه ای مناسب برای نگهداری یک کپی ثانویه از پایگاه داده برای دسترس پذیری بیشتر و یا برای offload کردن عملیات های گزارش گیری، کرده است. متعول ترین پیکره بندی برای replication تراکنشی در محیط های سرور-به-سرور است.

می توانید replication تراکنشی را در دو حالت اختیاری پیکره بندی کنید تا امکان انجام تراکنش بر روی مشترک فراهم شود. این دو حالت عبارتند از آپدیت بلادرنگ مشترکین و آپدیت صفی مشترکین. علاوه بر ارسال تراکنش ها از منتشر کننده به مشترک، replication تراکنشی را می توان در دو معماری به کار برد: replication تراکنشی دوطرفه و replication تراکنشی نظیر به نظیر (peer to peer).

تراکنش ادغامی

تراکنش ادغامی به طور عمده برای پردازش های سیار و نامتصل (disconnected) طراحی شده است. در این روش replication، منتشر کننده و مشترک همیشه متصل نیستند.

همانند replication تراکنشی، برای اطمینان از سنکرون بودن، یک snapshot اولیه به مشترک اعمال می شود، و سپس تغییراتی که بعد رخ می دهد به مشترک ارسال می شود. بر خلاف replication تراکنشی، replication ادغامی طراحی شده تا، به طور پیش فرض، اِعمال تغییرات هم در منتشر کننده و هم در مشترک را امکان پذیر سازد. موتور ادغام طی هر چرخه عامل، تغییرات ان دو را مبادله می کند.

نکته: چرخه عامل (Cycle of Agent)

Replication را می توان در دو حالت پیوسته (continuous) یا زمانبندی شده (scheduled) اجرا کرد. در حالت زمانبندی شده، عامل replication به صورت دوره ای اجرا می شود. در حالت پیوسته، موتور replication هممواره در حال اجراست. در هر دو حال، موتور replication در چرخه ی زیر کار می کند: برسی وجود تغییری برای replicate کردن، انتقال تغییرات به مشترک، تایید وصول (receipt) تغییرات. به این فرایند فرایند چرخه عامل replication می گویند. در حالت زمانبندی شده، چرخه عامل واضح تر است چون عامل شروع می شود، کاری را انجام می دهد و بعد بسته می شود. این چرخه در حالت پیوسته خیلی واضح نیست چون عامل هیچ گاه بسته نمی شود، در عوض به محض تکمیل یک چرخه، چرخه بعدی را اغاز می کند. برای درک بسیاری از حالت هایی که ممکن است پیش بیاید – مهمترین انها ناسازگاری داده ها (data conflict) – فهمیدن مفهوم چرخه عامل بسیار مهم است.

ناسازگاری داده ها (Data Conflicts)

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

برنامه هایی که تغییرات یک پایگاه داده را پردازش می کنند روشی برای پردازش تغییرات ناسازگار دارند – یا تمام تغییرات را با اخرین تغییر رونویسی (overwrite) می کنند و یا با رد کردن تغییرات به کاربر اطلاع می دهند که داده از اخرین زمان دستیابی، تغییر کرده است. هر چند این فرایند ها در سطح برنامه های کاربردی عملی اند ولی در محیط های توزیع شده کمکی نمی کنند چون هر برنامه روی یک کپی محلی (local) از داده ها کار می کند. ناسازگاری داده ها فقط زمانی رخ می دهد که موتور replication سعی می کند تمام تغییرات را سنکرون کند.

ناسازگاری داده ها تنها بین رخه های عامل replication رخ می دهد، بنابراین احتمال رخداد ان مینیمم است. بعد از اتمام یک چرخه عامل، می توان از مکانیسم های آشکار ساز (detection mechanisms) عادی درون برنامه های کاربردی استفاده کرد، چون تمام مجموعه داده ها برای برنامه به شکل محلی (local) است.

ناسازگاری داده ها فقط در replication ادغامی، replication تراکنشی با آپدیت صفی مشترکین، replication تراکنشی دوطرفه و replication تراکنشی نظیر به نظیر رخ می دهد، چون در این حالات، تغییرات را می توان هم روی منتشر کننده و هم روی مشترکین پردازش کرد.

انواع ناسازگاری ها

3 نوع ناسازگاری ممکن است رخ دهد:

افزودن کلید اصلی (primary key) تکراری، زمانی رخ می دهد که دو کاربر روی منتشر کننده و مشترک، یک کلید اصلی را وارد می کنند.

آپدیت ناسازگار، زمانی رخ می دهد که دو کاربر یک سطر داده را، یکی از روی منتشر کننده و دیگری از روی مشترک تغییر می دهند.

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

حلال ناسازگاری ها

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

بخشی که کار حل ناسازگاری ها را انجام می دهد را حلال ناسازگاری ها(Conflict Resolver) می گویند. SQL Server دارای چندین حلال ناسازگاری است. دو نمونه متداول، که برای

replication ادغامی و replication تراکنشی با آپدیت صفی مشترکین قابل استفاده است، عبارتند از:

• منتشر کننده همیشه برنده است.
• مشترک همیشه برنده است

اگر طوری حلال ناسازگاری را تنظیم کنید که همیشه منتشر کننده برنده باشد، تغییرات روی منتشر کننده همواره تغییرات روی مشترک را override می کند. در این حالت، تغییری که روی مشترک رخ داده، در منتشر کننده دور انداخته شده و در یک جدول ناسازگاری ها ثبت (log) می شود و تغییری که روی منتشر کننده رخ داده به مشترک ارسال می شود. این، تغییرات رخ داده روی مشترک را بی اثر می کند.

اگر طوری حلال ناسازگاری را تنظیم کنید که همیشه مشترک برنده باشد، تغییرات روی مشترک همواره تغییرات روی منتشر کننده را override می کند.

استفاده از هر روش تضمین می کند که یک کپی سازگار و منسجم از داده ها در معماری replication نگهداری می شود. با این حال، یک وضعیت خطیر ممکن است پیش بیاید. تغییراتی که روی منتشر کننده و مشترک انجام شده بود تراکنش هایی معتبر بوده و commit شده بودند. ممکن است یک کاربر دیگر اطلاعات را گرفته و بر اساس ان داده ها تصمیم تجاری مهمی گرفته باشد. سپس موتور replication داده ها را مبادله می کند، یک ناسازگاری کشف و داده ها overwrite می شود. از دید تجاری، تصمیم ان کاربر ممکن است الان نامعتبر باشد.

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

تذکر: تراکنش هایی که تا کمترین حد ثبت (log) می شوند

اگر پایگاه داده در یک replication شرکت دارد، باید به شدت مواظب مدل های Bulk-logged و Simple recovery باشید. وقتی یک پایگاه داده در مدل های Bulk-logged و Simple recovery قرار داده می شود، تراکنش هایی اجرا می شود که به کمترین حد ثبت می شوند. این نوع تراکنش ها فقط تخصیص و آزادسازی صفحه را در log تراکنش ثبت می کنند؛ انها trigger ها را فعال نمی کنند.

5 تراکنش از این نوع عبارتند از:

1. CREATE INDEX
2. TRUNCATE TABLE
3. BULK INSERT
4. BCP
5. SELECT…INTO

Replication فقط با 3 تا از اینها برخورد دارد – TRUNCATE TABLE، BULK INSERT ، BCP – چون انها بر داده جدول ها تاثیر می گذارند. اگر یک پایگاه داده در مدل های Bulk-logged و Simple recovery قرار داده شود و یکی از این دستور ها اجرا شود، موتور Replication نمی تواند تغییرات را بیابد چون replication تراکنشی به تراکنش های ثبت شده در log تراکنش ها، و replication ادغامی به trigger ها متکی اند.

پیکره بندی انتشار (Publishing)

در این تمرین، انتشار را روی نمونه SQL Server تان پیکره بندی می کنید.

1. SQL Server Management Studio (SSMS) را باز کنید و در Object Browser به نمونه SQL Server تان متصل شوید.
2. روی گره Replication کلیک راست کرده و Configure Distribution را انتخاب کنید. روی Next کلیک کنید.
3. اولین گزینه را انتخاب کنید تا نمونه تان به عنوان توزیع کننده خودش کار کند. Next را کلیک کنید.
4. مقدار پوشه snapshot را پیش فرض گذاشته، روی Next کلیک کنید.
5. مانند تصویر زیر، نام و مکان پایگاه داده توزیع را مقادیر پیش فرض گذاشته و روی Next کلیک کنید.

1. مطمئن شوید نمونه SQL Server تان به عنوان منتشر کننده (publisher) انتخاب شده است. Next را بزنید.
2. برسی کنید Configure Distribution تیک خورده باشد. روی Next کلیک کنید.
3. روی Finish کلیک کنید تا انتشار فعال شود، بعد Close را بزنید.

برسی کنید یک پایگاه داده به نام Distribution در نمونه SQL Server تان ساخته شده باشد.

خلاصه بخش

با ترکیب یک یا چند article و تشکیل یک publication می توان مجموعه داده ای برای انتقال توسط موتور Replication تعریف کرد.

یک پایگاه داده می تواند نقش منتشر کننده، مشترک و یا هر دو را بازی کند.

3 نوع replication وجود دارد: snapshot، تراکنشی و ادغامی.

تمام کارهای موتور replication را پنج عامل انجام می دهند: عامل Snapshot، عامل Log Reader، عامل توزیع، عامل ادغام و عامل صف خوان (Queue Reader).

در حالاتی که امکان اعمال تغییر هم در منتشر کننده و هم در مشترک وجود دارد، ممکن است ناسازگاری و تضاد داده ها رخ دهد.