Внедряването на MongoDB в производството може наистина да работи само ако се спазва правилният модел на внедряване. Разгръщането на набор от реплика в един хост не гарантира високата наличност на данни. Справянето с големи данни изисква задълбочени изследвания и оптимални внедрявания, или чрез комбиниране на наличните опции, или чрез избиране на тази с най-обещаващите ползи.
Моделите на внедряване за MongoDB включват:
- Набори реплики от три члена
- Набори реплики, разпределени в два или повече центъра за данни.
Набори реплики от три члена
Репликацията е стратегия за мащабиране за MongoDB, която подобрява високата наличност на данните. Наборът реплика включва:
- Основен възел:отговаря за всички операции с пропускателна способност на запис и може също да се чете от.
- Вторични възли:Могат да се използват само за операции за четене, но могат да бъдат избрани за първични, в случай че съществуващият се повреди. Те получават своите актуализации на данните от oplog, генериран от основния член на набора.
- Арбитър. Използва се за улесняване на избора на първични избори в случай, че има четен брой членове на набора реплики. Той не хоства копие на данните.
Предимствата от набор от реплика могат да бъдат постигнати само с минимален брой от трима членове със следната архитектура:
Основно-средно-средно
Това е най-препоръчителното, тъй като има по-висока толерантност на грешки и се справя с ограниченията за добавяне на трети член, носещ данни, като цена.
Това внедряване винаги ще предоставя две пълни копия освен основните данни, като по този начин гарантира висока наличност. Неуспехът на основния ще задейства набора реплика да избере нов първичен и операцията по обслужване ще се възобнови както обикновено. Ако старият основен член оживее, той ще бъде категоризиран като вторичен член.
По време на изборния процес членовете сигнализират един на друг чрез сърцебиене и през това време не се извършват операции по запис
След изборния процес приемаме, че архитектурата ще се реформира като:
Първичен-Вторичен-Арбитър
Това гарантира, че наборът от реплики остава наличен, дори ако основният или вторичният не са налични, като улеснява изборния процес на вторичен към първичен. Арбитрите не носят никакви копия на данните, следователно изискват по-малко ресурси за управление.
Ограничение с това внедряване е; няма излишък, тъй като има само два члена, носещи данни:първичен и вторичен. Това води до по-ниска толерантност на грешки.
Толерантността на грешки трябва да може да гарантира:
- Наличност за запис: е необходимо мнозинство от гласуващите членове на набора реплики, за да се поддържа или избира основният, който отговаря за операциите по запис.
- Резервиране на данни:записът може да бъде потвърден от множество членове, за да се избегне връщане назад
Конфигурацията Primary-Secondary-Arbiter поддържа аспекта на наличността на запис само така, че ако един член от набора е недостъпен, първичният все още може да се поддържа.
Въпреки това, липсата на поддръжка на втория аспект води до някои оперативни последици, ако вторичният член стане недостъпен:
- Няма да има активно репликация, особено ако вторичният е офлайн за дълго време. Когато вторичният елемент е офлайн твърде дълго, той може да падне от oplog, принуждавайки го да го синхронизира повторно по време на рестартиране.
- Резервирането на данни ще бъде саботирано, принуждавайки операцията на запис да бъде потвърдена само от текущия първичен.
- Опцията за мнозинство със загриженост няма да предостави най-новите данни на свързаните приложения и вътрешни процеси. Такъв е случаят, когато конфигурацията ви очаква записите да изискват потвърждение на мнозинството, следователно се блокира, докато по-голямата част от членовете, носещи данни, не са налични.
- Миграцията на парчета между фрагменти също ще бъде компрометирана, ако наборът от реплика е част от разчленен клъстер.
- Натиснете върху кеша на механизма за съхранение на WiredTiger, ако се случи връщане назад и точката на попълване не може да бъде напреднала.
За да се избегнат тези последствия, човек може да избере конфигурация първично-вторично-вторично , тъй като това повишава устойчивостта на грешки.
Забележка:Толерантността към грешки не идва само в случай на повреда, но също така някои системни операции, като надграждане на софтуер и нормална поддръжка, може да принудят член да бъде недостъпен за кратко.
Набори реплики, разпределени в два или повече центъра за данни
Високата наличност може да бъде издигната на друго ниво чрез разпределяне на членове на набора от реплики в географски различни центрове за данни. Този подход ще увеличи излишъка, освен че ще осигури висока толерантност на грешки в случай, че някой център за данни стане недостъпен.
Ако всички членове се намират в един център за данни, наборът от реплики е податлив на повреди в центъра за данни, като преходни процеси в мрежата и прекъсване на захранването.
Препоръчително е да запазите поне един член в алтернативен център за данни, използвайте нечетен брой центрове за данни и изберете разпределение на членовете, което ще предложи мнозинство за избори или поне ще предостави копие на данните в случай на неуспех.
Конфигурацията трябва да гарантира, че ако някой център за данни се повреди, наборът от реплики остава за запис, тъй като останалите членове могат да провеждат избори.
Разпространете данните си поне в три центъра за данни.
Членовете може да са ограничени до ресурси или да имат мрежови ограничения, което ги прави неподходящи да станат първични в случай на отказ. Можете да конфигурирате тези членове да не стават първични, като им дадете приоритет 0.
Членовете в даден център за данни може да имат по-висок приоритет от другите центрове за данни, за да им се даде приоритет на гласуване, така че да могат да избират първични преди членове в други центрове за данни.
Всички членове в набора реплики трябва да могат да комуникират помежду си.
Заключение
Ползите от репликацията могат да бъдат издигнати до по-обещаващ статус чрез разпределяне на членовете в редица центрове за данни. Това значително увеличава толерантността към грешки, освен че осигурява излишък на данни. Членовете на набора от реплики, когато са разпределени в два или повече центъра за данни, осигуряват предимства пред един център за данни, като например:
Ако един от центровете за данни изпадне, данните все още са налични за четене, за разлика от едно разпространение в центъра за данни.
Операциите за запис все още могат да бъдат потвърдени, когато център за данни с членове на малцинствата се повреди.
Операциите за четене все още могат да бъдат възможни, ако центърът за данни с членове с мнозинство с право на глас изпадне, за разлика от случая с един център за данни.
