پیش از این در مقاله ای به بررسی اجزای تشکیل دهنده ی SQL Server Replication پرداخته بودیم و با توجه به آنکه این تکنولوژی از اهمیت ویژه ای برخوردار است، در این مقاله انواع آنرا مورد بحث و بررسی بیشتر قرار می دهیم. لازم به ذکر است که دلایل و سناریو های مختلفی موجود است که موجب می شود که Replication به عنوان ابزاری قدرتمند برای پخش کردن و انتشار داده ها در نظر گرفته  شود که از آن جمله می توان به از بین بردن اثرات عملیات متمرکز و فشرده ی Read مثل تولید گزارش و…  نام برد. به عبارتی دیگر Replication بیشتر در مواقعی که اطلاعات مورد نظر Read Only باشد و نیازی به آپدیت کردن source نباشد مورد استفاده قرار می‌گیرد.

انواع SQL Replication

SQL Server از سه نوع Replication پشتیبانی می‌کند: Snapshot، Transactional یا تراکنشی و Merge  یا ادغام. یک Peer-to-Peer Replication  نیز وجود دارد که نوعی Replication تراکنشی با کمی ارتقا است و اجازه به‌روزرسانی دوسویه (Bi-Directional) را فراهم می سازد.

Snapshot Replication

Snapshot Replication هربار که اجرا می‌شود، یک کپی یکسان از Objectهای Replicate شده و داده‌هایشان می‌سازد. هیچ قابلیت هماهنگ‌سازی برای Snapshot Replication در دسترس نیست؛ اجراهای بعدی همیشه تمام Dataset را با بازنویسی هر تغییر بیرونی که ممکن است به پایگاه داده‌ی مقصد اعمال شده باشد، مجددا کپی می‌کنند.

Snapshot Replication از ابزار bcpی SQL Server برای نوشتن محتوای هر جدول در درون پوشه‌ی Snapshot استفاده می‌کند. پوشه‌ی Snapshot، در زمانی که Replication پیکربندی شده باشد، یک پوشه‌ی اشتراکی نصب شده بر سرور Distributer است. هر جزئی که در Snapshot Replication شرکت می‌کند لازم است که به پوشه‌ی Snapshot دسترسی داشته باشد.

هربار که Snapshot Replication اجرا می‌شود، تمام Articleها و داده‌هایشان مجددا از ابتدا کپی می‌گردند و این فرایند ممکن است به منابع ذخیره‌ساز و پهنای باند کافی نیاز داشته باشد. تمام انواع دیگر Replication، حین نصب اولیه، به طور پیش‌فرض از تنها یک Snapshot Replication جهت Sync کردن Publisher با Subscriberهایش استفاده می‌کنند. لازم به ذکر است که  از Snapshot Replication به ندرت به تنهایی مورد استفاده قرار ‌‌می‌گیرد، بنابراین بیش از این در مورد صحبت نمی‌کنیم.

Replication تراکنشی

Replication تراکنشی داده‌ها را به صورت یک سویه (Uni-Directional) از دیتابیس اصلی به پایگاه داده‌ی مقصد کپی می‌کند. این نوع Replication برای Sync نگه‌داشتن داده‌ها از فایل‌های Log همراه پایگاه داده‌ی منبع استفاده می‌نماید. اگر تغییری بر پایگاه داده‌ی منبع صورت بگیرد، بلافاصله به پایگاه داده‌ی مقصد Sync می‌شود، یا این که همسان‌سازی را می‌توان زمان‌بندی کرد. هر‌چند، Replication تراکنشی نسبت به تغییرات بیرونی بر پایگاه داده‌ی مقصد حساس است. هریک از این گونه تغییرات بالقوه می‌تواند Replication را بشکند، بنابراین برای هر قصد و هدفی پایگاه داده‌ی مقصد باید Read-Only درنظر گرفته شود. به هر حال استثنائاتی برای این قاعده وجود دارند. به عنوان مثال کاربر می‌تواند Objectهایی را در دیتابیس مقصد اصلاح کند که جزو تنظیمات Replication نیستند.

Replication تراکنشی همان‌طور که از اسم آن پیداست بر پایه ی تراکنش کار می‌کند. Log Reader Agent نیز Log تراکنش پایگاه داده‌ی Publication را اسکن کرده و هر تراکنش صورت گرفته را بررسی می‌نماید تا مشخص شود که آیا تغییری بر Articleهای Replicate شده تاثیر داشته است یا خیر. اگر تاثیر داشته باشند، آن تغییرات در Distribution Database بصورت Log نگهداری می‌شوند. سپس Distribution Agent آن تغییرات را با Subscriber، باید Replicate کند.

Replication تراکنشی امکان همسان‌سازی بصورت Real-Time را فراهم نموده و ظرفیت کمی از Publisher را اشغال می‌کند. در Replication تراکنشی چند قابلیت هستند که امکان جابه‌جایی داده‌ی دوسویه (Bi-directional) را فراهم می‌کنند، مانند Peer-to-Peer Replication. به هر حال Replication تراکنشی یک سویه (Uni-Directional) رایج‌ترین شکل مورد استفاده است و روش‌های دیگر در این مطلب پوشش داده نمی‌شوند. برای آن که Replication تراکنشی کارامد باشد، هر جدولی را که کاربر می‌خواهد منتشر کند باید با یک Primary Key پیکربندی نمود.

بررسی Merge Replication

Replication ادغامی به دو یا چند پایگاه داده اجازه می‌دهد که Sync بمانند. هر تغییری که بر یک پایگاه داده اعمال گردد، به طور خودکار به پایگاه داده‌های دیگر نیز اعمال می‌شود و بالعکس. بطور کلیMerge Replication  طراحی شد تا توانایی تغییر داده‌ها را برای Publisher همانند Subscriber ایجاد کند، اما این Replication سناریوهای Disconnect شده را نیز ممکن می‌کند. به عنوان مثال، اگر ارتباط یک Subscriber در طول بخشی از روز از یک Publisher، قطع شده باشد، Subscriber و Publisher زمانی که مجددا متصل گردند، هماهنگ‌سازی می‌شوند.

Merge Agent مسئول همسان‌سازی تغییرات بین Publisher و Subscriberهایش است. این Agent، مجموعه‌ای از Triggerها را برای شناسایی Articleهایی که تغییر یافته‌اند و برای ثبت آن تغییرات به‌کار می‌گیرد. با  توجه به آنکه می‌توان داده‌ها را هم روی Subscriber و هم روی Publisher اصلاح نمود، ممکن است که یک ردیف همزمان در دو جای مختلف به‌روزرسانی گردد که این امر می‌تواند منجر به مغایرت بین داده‌ها شود. Replication ادغام با چند قابلیت Built-in همراه است که می‌تواند چنین مغایرت‌هایی را رفع کند.

Replication ادغامی ردیف‌ها را در سرتاسر سرورهای مختلف با استفاده از یک ستون Uniqueidentifier با مجموعه Propertyی ROWGUIDCOL و یک محدودیت منحصر به فرد تعریف شده بر آن ستون، شناسایی می‌کند. اگر کاربر جدولی منتشر کند که در حال حاضر چنین ستونی ندارد، یک ستون Uniqueidentifier با پیکربندی مناسب، به طور خودکار اضافه خواهد شد.

مقاله های مرتبط: