Съображения за администриране на MongoDB

По-долу е даден откъс от нашия бял документ „Управление и автоматизация на MongoDB с ClusterControl“, който може да бъде изтеглен безплатно.

Съображения за администриране на MongoDB

Вградено резервиране

Ключова характеристика на MongoDB е вграденото му резервиране под формата на репликация. Ако имате два или повече възли с данни, те могат да бъдат конфигурирани като набор от реплики, в който всички данни, записани на първичния възел, се репликират в почти реално време към вторичните възли,

осигуряване на множество копия на данните. В случай на първичен отказ, останалите възли в набора от реплики провеждат избор и издигат победителя като първичен, процес, който обикновено отнема 2-3 секунди и записът в набора реплики може да се възобнови. MongoDB също така използва дневник за по-бързо, по-безопасно записване на сървъра или набор от реплики, а също така използва метод „загриженост за записа“, чрез който се
конфигурира нивото на излишък при запис.

За ръчно разгръщане на набор от реплики, стъпките от високо ниво са както следва:

1. Разпределете един физически или виртуален хост за всеки възел на базата данни и инсталирайте клиента на командния ред MongoDB на вашия работен плот. За конфигурация на излишен набор от реплики са необходими минимум три възли, поне два от които ще бъдат възли с данни. Един възел в набора от реплики може да бъде конфигуриран като арбитър:това е процес mongod, конфигуриран само за съставяне на кворум чрез предоставяне на гласуване при избора на първичен, когато е необходимо. Данните не се репликират в арбитражни процеси.
2. Инсталирайте MongoDB на всеки възел. Някои дистрибуции на Linux включват MongoDB Community Edition, но имайте предвид, че те може да не включват най-новите версии. MongoDB Enterprise е достъпен само чрез изтегляне от уебсайта на MongoDB. Подобна функционалност на MongoDB Enterprise също е налична чрез Percona Server за MongoDB, добавен заместител на MongoDB Enterprise или Community Edition.
3. Конфигурирайте отделните конфигурационни файлове mongod.conf за вашия набор от реплики, като използвате „параметъра за репликация“. Ако ще използвате ключов файл за сигурност, конфигурирайте и това сега. Имайте предвид, че използването на защита на ключов файл също позволява удостоверяване, базирано на роли, така че ще трябва също да добавите потребители и роли, за да използвате сървърите. Рестартирайте процеса mongod на всеки сървър.
4. Осигурете свързаност между възлите. Трябва да гарантирате, че възлите на набора реплики на MongoDB могат да комуникират помежду си на порт 27017, както и че вашият клиент(и) могат да се свързват с всеки от възлите на набора реплики на същия порт.
5. Използвайки клиента на командния ред MongoDB, свържете се с един от сървърите и стартирайте rs.initiate(), за да инициализирате вашия набор от реплики, последвано от rs.add() за всеки допълнителен възел. rs.conf() може да се използва за преглед на конфигурацията.

Въпреки че тези стъпки не са толкова сложни, колкото разгръщането и конфигурирането на разделен клъстер на MongoDB или разделянето на релационна база данни, те могат да бъдат обременителни и податливи на грешки, особено в по-големи среди.

Мащабируемост

MongoDB често се нарича софтуер за база данни за "уеб мащаб", поради капацитета му за хоризонтално мащабиране. Подобно на релационните бази данни, възможно е да се мащабира вертикално MongoDB, просто чрез надграждане на физическия хост, на който се намира, с повече ядра на процесора, повече RAM, по-бързи дискове или дори увеличена скорост на шината. Вертикалното мащабиране обаче има своите граници, както по отношение на съотношението цена-полза и намаляващата възвръщаемост, така и по отношение на техническите ограничения. За да се справи с това, MongoDB има функция за „автоматично споделяне“, която позволява на базите данни да бъдат разделени на много хостове (или набори реплики, за излишък). Макар че разделянето е възможно и на релационни платформи, освен ако не е проектирано за създаване на база данни, това изисква основен редизайн на схема и приложение, както и редизайн на клиентско приложение, което прави това досаден, отнемащ време и податлив на грешки процес.

Разделянето на MongoDB работи чрез въвеждане на процес на рутер, чрез който клиентите се свързват с разчленения клъстер, и конфигурационни сървъри, които съхраняват метаданните на клъстера, местоположението в клъстера на всеки документ. Когато клиент подава заявка към процеса на рутера, той първо се позовава на конфигурационните сървъри, за да получи местоположението на документите, а след това получава резултатите от заявката директно от отделните сървъри или
набори реплики (шардове). Раздробяването се извършва за всяка колекция.

Критично важен параметър тук, за целите на производителността, е „ключът на сегмента“, индексирано поле или съставно поле, което съществува във всеки документ в колекция. Това е, което дефинира разпределението на запис в парчета от колекция. Като такъв, недобре избран ключ за фрагменти може да има много пагубен ефект върху производителността. Например, изцяло базиран на времеви серии ключ за сегменти може да доведе до това, че всички записи отиват в един възел за продължителни периоди от време. Въпреки това хешираният ключ на сегмента, макар и равномерно разпределяйки записите между фрагменти, може да повлияе на производителността на четене, тъй като наборът от резултати се извлича от много възли.

Арбитри

Арбитърът на MongoDB е процес на mongod, който е конфигуриран да не действа като възел за данни, а да предоставя само функцията за гласуване, когато трябва да бъде избран основен набор от реплика, за да прекъсне връзките и да се предпази от разделен вот. Арбитърът може да не стане Основен, тъй като не държи копие на данните или не приема запис. Въпреки че е възможно да имате повече от един арбитър в набор от реплика, обикновено не се препоръчва.

Членове на отложен набор от реплики

Членовете на отложен набор от реплики добавят допълнително ниво на излишък, поддържайки състояние, което е фиксиран брой секунди след Основния. Тъй като забавените членове представляват „променливо резервно копие“ или текуща „историческа“ моментна снимка на набора от данни, те могат да помогнат за възстановяване от различни видове човешки грешки.

Забавените членове са „скрити“ членове на набора от реплики, невидими за клиентските приложения и затова не могат да бъдат запитани директно. Те също може да не станат Основни по време на нормални операции и трябва да бъдат преконфигурирани ръчно, в случай че трябва да се използват за възстановяване от грешка.

Резервни копия

Архивирането на набор от реплики или разчленен клъстер се извършва чрез помощната програма на командния ред „mongodump“. Когато се използва с параметъра --oplog, това създава дъмп на базата данни, който включва oplog, за създаване на моментна снимка на състоянието на mongod екземпляр. Използвайки mongorestore с параметъра --replayOplog, можете да възстановите напълно състоянието на данните към момента на завършване на архивирането, като избягвате несъответствие.

За по-разширени изисквания за архивиране е наличен инструмент на трета страна, наречен „mongodbconsistent-backup“ – също базиран на команден ред – който осигурява напълно последователни архиви на разчленени клъстери, сложна процедура, като се има предвид, че разчленените бази данни се разпределят между множество хостове.

Наблюдение

Има редица търговски инструменти, както официални, така и неофициални, налични на пазара за наблюдение на MongoDB. Тези инструменти като цяло са помощни програми за управление на единични продукти, фокусирани изключително върху MongoDB. Много от тях се фокусират само върху определени специфични аспекти, като управление на колекция в съществуваща архитектура на MongoDB, или върху архивиране, или върху внедряване. Без правилно планиране това може да доведе до ситуация, при която във вашата среда трябва да се разгърнат и управляват множество допълнителни инструменти.

Инструментите на командния ред, предоставени с MongoDB, „mongotop“ и „mongostat“, могат да осигурят подробен изглед на производителността на вашата среда и могат да се използват за диагностициране на проблеми. В допълнение, клиентът на командния ред „mongo“ на MongoDB може също да стартира „rs.status()“ – или в раздробен клъстер „sh.status() – за да видите състоянието на набори от реплики или клъстери и техните хостове-членове. Командата „db.stats()“ връща документ, който се отнася до използването на хранилището и обемите на данни и те са еквиваленти за колекции, както и други извиквания за достъп до много вътрешни показатели.

Резюме

Това беше кратък синопсис на съображения за администриране на MongoDB. Дори и на такова високо ниво обаче, веднага трябва да е очевидно, че макар да е възможно да се администрира набор от реплики или разделен клъстер от командния ред с помощта на налични инструменти, това не се мащабира в среда с много набори реплики или с голямо производство раздробен клъстер. В средни до големи среди, включващи много хостове
и бази данни, бързо става невъзможно да се управлява всичко с инструменти и скриптове на командния ред. Докато вътрешните инструменти и скриптове могат да бъдат разработени за внедряване и поддържане на средата, това добавя тежестта на управлението на нови разработки, системи за контрол на ревизии и процеси. Простото надграждане на сървър на база данни може да се превърне в сложен процес, ако са необходими промени в инструментите за поддръжка на нови
сървър версии на базата данни.

Но без вътрешни инструменти и скриптове, как да автоматизираме и управляваме MongoDB клъстери? Изтеглете бялата книга, за да научите как!