در این روش جدول‌ها و موضوعات مشخص (Views، Store Procedures و…) یک یا چندین SQL را می‌توان همسان‌سازی کرد و روشی است که از لحاظ تئوری کامل به نظر می‌رسد، اما واقعیت این است که این روش برای HA طراحی نشده است.
با این روش می‌توانید دیتا را روی Instance های مختلف داشته باشید، دیتایی که می‌خواهید محافظت (Protect) شودرا فیلتر کنید و در گزارش‌گیری‌ها از قابلیت‌های آن بهره ببرید. این روش برای HA مناسب نیست زیرا:

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

در این روش به جای کپی کردن جدول‌ها و Stored Procedures ها از Transaction Logs (شامل هر چیزی است که در دیتابیس اتفاق می‌افتد) به عنوان منبع اطلاعاتی استفاده می‌شود و می‌توان این روش را روی یک یا چندین SQL Servers اعمال کرد.
Shipping در یک بازه زمانی مشخص اتفاق می‌افتد، به‌صورت پیش‌فرض هر ۱۵ دقیقه یکبار است، اما می‌توان آن را هر یک دقیقه یک‌بار یا هر یک روز یک‌بار نیز تنظیم کرد.
با استفاده از این روش شما یک یا چند دیتابیس پشتیبان آماده می‌توانید داشته باشید.

در این روش هم اگر سرور اصلی از دسترس خارج شود، لازم است تنظیمات به صورت دستی انجام شود و همچنین احتمال از دست دادن دیتا در این روش هم وجود دارد.
این روش در نسخه‌های SQL Server 2014, Enterprise, Business Intelligence, Standard, and Web editions پشتیبانی می‌شود ولی در دنیای واقعی طرفدار چندانی ندارد.

Mirroring اولین روشی است که مایکروسافت با هدف ارائه راه حلی برای HA ارائه کرده است. در این روش دو Instance از دیتابیس بر روی سرورهای جداگانه ایجاد می‌کنیم.
با توجه به خطرات احتمالی ( مثل آتش سوزی) نگهداری هر دو Instance در کنار هم و در یک مکان عاقلانه نیست، بهتر است هر Instance در یک دیتاسنتر یا مکان جغرافیایی جدا از هم نگهداری شود.
یکی از دیتابیس ها به عنوان دیتابیس اصلی مشخص می‌شود و سرور دیگر در حالت آماده باش قرار دارد. اجرا کردن این دیتابیس‌ها در حالت High-Safety این اطمینان را می‌دهد که دیتای هر دو دیتابیس دقیقا مشابه است.
در این روش درخواستی که از دیتابیس می‌شود در یک زمان در هر دو دیتابیس اعمال می‌شود.

چون از یک دیتابیس شاهد (Witness Server) استفاده می‌شود، از دست رفتن اطلاعات اتفاق نمی‌افتد. دیتابیس شاهد یک Microsoft SQL Server جداست که دیتابیس اصلی را مانیتور میکند و در زمان بروز مشکل به روی دیتابیس دوم سوییچ میکند.
اگر ارتباط دیتابیس ها قطع شود آنها اطلاعات خود را از دیتابیس شاهد دریافت می‌کنند. از آنجایی که دیتابیس‌ها کاملا مشابه و آنلاین هستند، به‌صورت دستی هم می‌توان بدون این‌که اتفاقی برای سایت رخ دهد بین آنها سوییج کرد.
با این توضیحات این روش ایده آلی به نظر می‌رسد اما این روش در Maintenance Mode قرار گرفته است و در نسخه‌های جدید Microsoft SQL Server حذف می‌شود.

کلاستر (Cluster) در لغت به معنای “یک گروه از چیزهای مشابه یا آدم‌ها که به‌صورت عمدی یا اتفاقی در کنار هم قرار گرفتند” است.
بنابراینClustering به معنای قرار گرفتن در یک Cluster یا یک گروه نزدیک است. کلاسترها چیزی شبیه SQL Server مشتری را از سخت افزاری که روی آن اجرا شده است، جدا می‌کنند.
یک نرم افزار اجرا شده از دو قسمت تشکیل شده است: قسمتی در RAM و هر چیزی که Cached می‌شود و هر Query که اجرا می‌شو و Hard Drives که دیتابیس در آن قرار دارد.

در یک محیط کلاستر شده، می‌توانیم پیکربندی (Configured) بیش از یک سرور را طوری انجام دهیم که از یک مجموعه Hard Drive مشترک استفاده کنند به‌طوری که در یک زمان تنها یک سرور از Hard Drive ها استفاده کند.
در این روش در هر سرور SQL Server اجرا می شود و یک Hard drive اشتراکی بینشان وجود دارد و زمانی‌که سرور اصلی از دسترس خارج شود، Hard drive به سرور دیگر اختصاص داده می‌شود و کار ادامه پیدا می‌کند و این همان چیزی است که به دنبالش هستیم، کم‌ترین زمان پایین بودن سرویس (downtime)
یکی دیگر از مزیت‌های این روش، زمانی است که می‌خواهیم سرویس پک جدیدی روی SQL نصب کنیم (دیتابیس را به‌روزرسانی کنیم) در حالت عادی لازم است سرویس را متوقف کنیم و دیتابیس از دسترس خارج شود، معمولا این‌کارها را در نیمه شب روزهای تعطیل زمانبندی می‌کنند که آن‌هم به معنای حضور ادمین در آن زمان در شرکت است که چندان خوش آیند نیست. با استفاده از کلاستر، این مسئله به راحتی حل می‌شود.
سرور A ، SQL را اجرا می‌کند و سرور B در حالت انتظار قرار دارد و کاری انجام نمی‌دهد، پس می‌توان در این زمان آن را به‌روزرسانی کرد و سپس وظیفه اجرای SQL را به آن سپرد و سرور A را به‌روزرسانی کرد، به این ترتیب هر دو سرور بدون اینکه کاربران متوجه شوند به‌روزرسانی می‌شوند.
خب کمی هم در رابطه با معایب این روش صحبت کنیم، تا به‌این جا که همه چیز عالی بوده است. مهم‌ترین موضوع این روش هزینه آن است. برای ارائه یک سرویس لازم است دو سرور داشته باشید و این یعنی دو برابر شدن هزینه‌ها !
از طرفی Hard Drive ها به صورت اشتراکی در این روش بین سرورها قرار می‌گیرند و اگر مشکلی برایشان پیش بیاید که نیاز به جابجایی داشته باشند بازهم DownTime برای سرویس ایجاد می شود.
برای راه اندازی این حالت حداقل از دو سرور استفاده می‌شود، پس نگرانی بابت خرابی مادربرد (Mother Board)، پاور (Power)، مموری (Memory) یا هرچیز دیگر وجود ندارد اما اگر ساختمان نگهداری سرورها آتش بگیرد چه اتفاقی می‌افتد؟
از آنجایی‌که کلاسترها نیاز دارند با هم در ارتباط باشند بنابراین نمی‌توانیم آنها را در دو مکان جغرافیایی متفاوت قرار دهیم. راه‌هایی هست که بتوانیم این‌کار را انجام دهیم، اما تاخیر ایجاد می‌کند که خب چندان جالب نیست.
بنابراین اگر نیاز هست که سرورها در مکان‌های جغرافیایی مختلف قرار بگیرد ، این روش کارآمد نیست و لازم است از روش‌های دیگر مثل Mirroring،Log Shipping یا Availability Group (در ادامه توضیح داده ایم) استفاده شود.

آخرین روش برای HAدر SQL Server 2012 با هدف فراهم کردن بیش‌ترین میزان دسترسی برای یک یا چند دیتابیس، به جای روش Mirroring ارائه شد.
مشابه روش Failover Clustering این روش هم به Windows Clustering وابسته است، بنابراین به یک نقطه مرکزی نیاز دارد تا با دیتابیس‌ها در ارتباط باشد.
برخلاف روش Failover Clusteringبه Shared Storage نیازی ندارد، که این موضوع زمانی که مشتری بخواهد روی Cloud هاست شود و در هزینه‌ها صرفه جویی کند اهمیت پیدا می‌کند.
Availability Group مشابه روش Mirroringدیتا را تکثیر می‌دهد.

مشتری می‌تواند یک سرور با هارد SSD را نزدیک سرور اصلی داشته باشد و دیگری را در یک منطقه یا یک کشور متفاوت داشته باشد. از مزایای این روش این است که سرورها را به صورت دستی می توان خارج کرد.
راه اندازی و نگهداری از Availability Group سخت نیست اما با توجه به اینکه Microsoft SQL Server Enterprise نیاز داد و لازم است چند سرور آنلاین و Idle داشته باشیم هزینه هنگفتی دارد.
بنابراین این روش بهتر است برای وضعیت‌های خاص و حساس راه اندازی شود به‌طوری که هزینه‌ها در واقع یک سرمایه گذاری محسوب شوند.