دیتابیس مونگو به عنوان یک نمونه بسیار قوی از دیتابیس های no sql
بوده که علاوه بر
کاربردهای ساده و معمولی که عموما موتورهای دیتابیس ارائه می دهند راهکارهایی در زمینه
کارآیی و سرعت عمل و پایداری را معرفی کرده است.
یکی از مهمترین این موضوعات replication
می باشد. که از قابلیت های این ویژگی می توان به نکات زیر
اشاره نمود:
- افزایش تحمل در برابر خرابی
- افزایش تعداد درخواستهای قابل پردازش
- انعطاف پذیری در اعمال تغییرات روی ساختار دیتابیس های بسیار بزرگ
- کم کردن نقطه قطعی
- ضریب بهره وری بسیار بالا
مکانیزم عملکرد
در حالتی که فقط از یک پایگاه داده استفاده شود تمام درخواستها توسط یک پایگاه داده انجام میشود. در این حالت فقط تعداد محدودی درخواست در واحد زمان پاسخ داده میشود. اگر پایگاه دادهها در یک کلاستر قرار بگیرند، درخواستهای write توسط Primary و درخواستهای read توسط Secondary انجام میشوند. به این ترتیب تعداد درخواستهای read به ازای هر نود Secondary افزایش مییابد. همچنین Primary فقط روی درخواستهای write تمرکز دارد که نسبت به حالت قبل تعداد درخواست write افزایش مییابد.
نحوه ایجاد رپلیکیشن
در ابتدا باید یک کلاستر خالی ایجاد کرد. برای اینکار بهتر است تعداد سرورها فرد باشد. هر یک از نودها را با دستور زیر بالا میآوریم:
mongod --bind_ip 0.0.0.0 --directoryperdb --replSet "rs0" --setParameter --logpath=/var/logs/mongod.log --quiet
در دستور بالا replSet
نام کلاستر را نشان میدهد که باید در همه نودها یکسان باشد.
پس از اینکه تمام نودها بالا آمدند در نودی که قصد داریم Primary باشد کلاستر را معرفی و آغاز میکنیم:
rs.initiate(
{
_id: "rs0",
version: 1,
members: [
{ _id: 0, host : "192.168.1.10:27017" },
{ _id: 1, host : "192.168.1.2:27017" },
{ _id: 2, host : "192.168.1.4:27017" }
]
}
پس از اجرای این دستور کلاستر شروع به کار میکند.
تغییر اولویت نودها
در ابتدای ایجاد کلاستر همه نودها اولویت یکسان دارند، یعنی هر وقت نود Primary متوقف شود هر یک از نودهای Secondary شانس یکسانی برای انتخاب شدن به عنوان Primary جدید دارند. این امکان وجود دارد که به نودها اولویت داد، به این ترتیب وقتی نود Primary متوقف شود؛ نود Secondary با بالاترین اولویت به Primary ارتقا پیدا میکند. برای تغییر اولویت دستورات زیر در Primary اجرا میشود:
cfg = rs.conf()
cfg.members[0].priority = 0.5
cfg.members[1].priority = 2
rs.reconfig(cfg)
نکته: هنگامی که یک نود با اولویت بالاتر نسبت به بقیه نودها به کلاستر اضافه میشود، ابتدا خود را با کلاستر یکسانسازی میکند سپس وضعیت خود را از Secondary به Primary تغییر میدهد.
اضافه کردن نود جدید به کلاستر
مراحل انجام کار:
1- ابتدا یکی از نودهای Secondary را متوقف میکنیم.
2- دیتاهای این نود را به سرور جدید منتقل میکنیم.
3- پس از اینکه انتقال تمام شد ابتدا نودی که در مرحله اول متوقف شده بود را بالا میآوریم تا با کلاستر سازگار شود.
4- سپس پایگاه جدید را به صورت سایر نودها بالا میآوریم.
در نهایت در نود Primary دستور زیر اجرا میکنیم:
rs.add("192.168.1.5:27017")
نکته: هر کلاستر میتواند تعداد زیادی نود داشته باشد ولی فقط ۷ نود حق دارند برای انتخاب نود Primary رای دهند. به همین دلیل اگر تعداد نودها بیشتر از ۷ شد باید پیش از اضافه کردن این نود حق رای یکی از نودهای دیگر را از بین برد.
cfg = rs.conf()
cfg.members[2].votes = 0
rs.reconfig(cfg)
پیکربندی یک عضو Replica Set با تأخیر و مدیریت خودکار
برای پیکربندی یک نود رپلیکا با تأخیر، مقدار members[n].priority
را روی صفر قرار دهید،
مقدار members[n].hidden
را روی true
تنظیم کنید، و مقدار members[n].secondaryDelaySecs
را برابر
با تعداد ثانیههای تأخیر مورد نظر قرار دهید.
نکته مهم
مدت زمان members[n].secondaryDelaySecs
باید در بازه زمانی oplog
جا بگیرد. اگر طول oplog
کمتر
از بازه تأخیر تعیینشده باشد، عضو تأخیری نمیتواند بهدرستی replicate
کند.
وقتی یک نود تأخیری را پیکربندی میکنید، این تأخیر هم برای تکرار دادهها و هم برای oplog
آن نود اعمال میشود.
در مثال زیر، یک تأخیر یک ساعته برای نودی از Replica Set
در موقعیت صفر از آرایه members
تعیین
میشود. برای اعمال تأخیر، در نود primary، دستورات زیر را اجرا کنید:
cfg = rs.conf()
cfg.members[0].priority = 0
cfg.members[0].hidden = true
cfg.members[0].secondaryDelaySecs = 3600
rs.reconfig(cfg)
پس از اعمال پیکربندی جدید، نود با تأخیر دیگر نمیتواند به primary
تبدیل شود و از دید برنامهها پنهان
است. مقدار members[n].secondaryDelaySecs
هم تکرار و هم oplog
نود را به مدت ۳۶۰۰ ثانیه(۱ ساعت)
به تأخیر میاندازد.