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

[fmka2f]

سلام دوستان
من یه سناریو رو برای شما تعریف میکنم اگه اساتید لطف کنن و راه حل بدن خیلی ممنون میشم.بخصوص اقای صادقیان که به نظر تو این زمینه تجربه خوبی دارن
ما دوتا سرور دیتابیس داریم که یکی اصلی و یکی پشتیبانه.نرم افزارهای دستکتاپ متعددی به بانک اطلاعاتی اصلی متصل اند و در اون داده ذخیره میکنن.من با سرچی که داشتم متوجه شدم 3 راه وجود داره که من هم زمان اطلاعات دیتابیس سرور اصلیمو رو دیتابیس سرور پشتیبان هم داشته باشم Log shipping و mirror و Replication
من میخوام همه ی تغییرات دیتابیس اول رو دومی هم اعمال بشه.مثلا تغییر استورپروسیجر هم رو دوتا دیتابیس اعمال بشه.و اینکه با خرابی سرور اول به سرعت بتونم به سرور دوم سوئیچ کنم و کاربرا راحت اطلاعات خودشون رو ذخیره و یا فراخوانی کنند و اینکه بعد از درستی سیستم اول اطلاعات ذخیره شده در سیستم دوم چطور انتقال پیدا کنه.صحت اطلاعات هم خیلی اهمیت داره
هر کدوم از این روشها چه مزایا و معایبی داره و رفرنسی برای استفاده از این روشها معرفی کنید.دوستان پیشاپیش خیلی ممنونم

[fmka2f]

سلام دوستان خواهش میکنم کمکم کنید.یکی تفاوت کامل این روش هارو بگه و بگه من برای داشتن ویژگی های سناریوی بالا باید چکار کنم؟ اساتییییید الان نیازمند یاریتان هستم

[esteghamat]

سلام
چند مورد براي مقايسه بين اين روش ها :
1- Replication
- اول اينكه با توجه به زمان تنظيم sync ، همان زمان سرور پشتيبانت از سرور اصلي عقب تر است.
- دوم اينكه سرور دومت ، مشخصات واقعي يك سرور دوم را دارد و اگر سرور يك شما از دست برود بايد با سرعت و بصورت دستي ، مشخصات IP و نام سرور بانك اطلاعاتي رو مثل سرور اول بكني كه كسي در لاگين به اون با مشكل مواجه نشه .
- سوم اينكه نگهداري replication خودش كار پر دردسريه . گرچه به نوع replication هم بستگي داره . مثلا اون نوعي كه شما مي خواهي (يك طرفه) درد سر زيادي نداره ولي در هر صورت يه نظارت خوبي نياز داره .
- چهارم اينكه وقتي سرور اصلي ات برگشت باز بايد همان عمليات تغيير نام رو انجام بدي بعد از سرور دومت يك backup بگيري و روي سررو اصلي برگردوني .

سادگي روش : يكي از مزاياي اين روش هست.

2- Log shipping : در اين روش در واقع هر چند وقت (كه شما تنظيم مي كني)، يك backup از نوع log از سرور اصلي تهيه مي شه و روي سرور دوم يا همان stand by server بصورت Non recovery برگردانده restore مي شه .
خوب هر وقت به گير خوردي ، status سرور دومت را به حالت recovery در مياري.
در اين روش هم بايد اسم و IP سرور دوم را بعد از خروج سرور اول از خط عوض كني و اينجا هم چند دقيقه اي كار را از دست مي دهي .

3- يكي از بهترين روش ها تا قبل از 2012 همان database mirroring است .
يك سرور primary مي شود و يك سرور mirror . همان log shipping است با اين تفاوت كه منتظر نمي شود كه تغييرات يك فايل شود و سپس منتقل و restore شود . بلكه با هر transaction، اين tran منتقل مي شود .
حال اگر در اين روش بخواهي automatic failover داشته باشي ، بايد خوب خرج كني و سرور سومي هم داشته باشي. اين سومي هي به اولي سرو مي زند و وقتي جواب نگرفت دومي را به عنوان primary معرفي مي كند.
mirroring به چهار حالت پياده سازي مي شود. ... كه حسابي بايد بهش مسلط بشي.

4- از 2012 به بعد خود sql server بحث failover cluster را بصورت خاص پشتيباني كرده كه اصطلاحا always on مي باشد. ظاهرا اين بهترين تكنولوژي HA تا كنون است. اما من اطلاعي ندارم و يك post هم گذاشتم كه تا حالا كسي جوابي نداده .
------------------------------------------------------------------------------
اگر بخواهيم جمعبندي كنيم :
1- بايد به شرايط خودت نگاه كني . آيا واقعا به HA نياز داري ؟ اگر از ويندوز سرورت خوب محافظت كني و بحث backup رو مرتب داشته باشي مي توني يه جورايي پاسخگو باشي . اما دقت كن كه HA روش هزينه بري است و اگر سمتش مي ري بايد اونقدر مسلط بشي كه واقعا در زمان fail بتوني روش switch كني وگرنه جواب شركت رو دادن خودش مساله اي ست.
2- بايد ببيني كه اگر HA مي خواهي ، شركت چقدر زمان توقف را قبول مي كند ؟ و چقدر زمان از دست رفتن اطلاعات را قبول مي كند ؟
موفق باشي