Контролен списък за разработка и операции за MongoDB

Контролните списъци за работа и разработка на MongoDB са предназначени да помогнат на администраторите на бази данни да избягват проблеми в производствената среда на MongoDB. Контролният списък за разработка трябва да адресира проблеми като...

1. Дизайн на схема
2. Издръжливост на данните
3. Репликация
4. Дискове 
5. Разделяне 

Контролен списък за операции, от друга страна, адресира...

1. Репликация
2. Файлова система 
3. Разделяне
4. Хардуер
5. Журналиране (WiredTiger Storage Engine) 
6. Конфигурации на операционната система 
7. Внедряване в хардуер в облак 
8. Наблюдение
9. Архивиране и балансиране на натоварването

Преди започване на проект е препоръчително да работите върху контролния списък за експлоатация и разработка, за да позволите безпроблемна работа на  MongoDB в производството. Тази статия обяснява контролен списък за експлоатация и разработка преди внедряването на MongoDB.

Контролен списък за операциите на MongoDB

Репликация

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

Размерът на Oplog трябва да бъде конфигуриран правилно, за да отговори на оперативните нужди, така че:

• За да избегнете необходимостта от пълно повторно синхронизиране, прозорецът на приложението oplog копия трябва да покрива редовното време на престой и прозореца за поддръжка.
• За да възстановите член на набора за репликация, прозорецът на oplog на репликата трябва винаги да покрива необходимото време.

Производственият набор като минимум трябва да включва три възела, носещи данни, които работят с активирано водене на журнал. Освен това записванията трябва да се издават с w:„мнозинство“ при записване за целите на осигуряване на наличност и трайност на данните.

Разгръщането трябва да съдържа нечетен брой членове с право на глас, за да се улесни процеса на гласуване, когато основният възел в клъстера не успее.

Вместо да използвате IP адреси, които може да изискват такъв за промяна на конфигурациите поради промяна на IP, се препоръчва използването на логически DNS имена на хостове.

Уверете се, че екземплярите на mongod имат 0 или 1 глас.

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

Записване в дневник

Това е стратегия за записване напред за записване на дневни файлове на диск, използвана за осигуряване на трайност на данните в случай на неуспех. Поради тази причина всички екземпляри трябва да имат активирано дневникиране, особено когато се занимават с натоварвания с интензивно писане.

Въпреки това, имайте предвид, че това засяга подсилванията в стила на моментна снимка, тъй като записите, съставляващи състоянието на базата данни, ще се задържат върху разделени томове.

Файлова система

Не използвайте устройства за файлова система за новини (NFS) за dbPath. NFS устройствата вероятно могат да доведат до дестабилизирана производителност. Виртуалните устройства на VMware се препоръчват за използване от потребителите на VMware.

Уверете се, че вашите дискови дялове са подравнени с вашите RAIDON конфигурации.

За потребители на Linux/Unix се препоръчва използването на XFS. Известно е, че XFS работи по-добре с MongoDB.

За потребители на операционна система Windows се препоръчва файловата система NTFS. Трябва да избягвате използването на каквато и да е файлова система FAT.

Внедряване в хардуер в облак

Windows Azure:Променете TCP keepalive (tcp_keepalive_time) на 100-120. Времето за изключване на TCP в балансира на стека на Azure също е умерено за поведението на обединяването на асоциации на MongoDB

Използвайте MongoDB 2.6.4 или по-нови версии в рамки с висока латентност за съхранение, като Windows Azure, тъй като тези версии включват подобрения на изпълнението за тези рамки.

Разделяне

Поставете вашите конфигурационни сървъри на специален хардуер за идеално изпълнение в обширни клъстери.

Уверете се, че хардуерът има достатъчно RAM за съхраняване на информационните записи изцяло в паметта и има специално място за съхранение.

Разгръщайте рутери mongos в съответствие с указанията за настройка за генериране.

Синхронизирайте часовниците на всички компоненти на вашия разделен клъстер с помощта на NTP.

Осигурете пълна двупосочна мрежа между mongos, mongod и config сървъри.

Използвайте CNAME, за да разпознаете вашите конфигурационни сървъри в клъстера, така че да можете да преименувате и преномерирате своите конфигурационни сървъри без прекъсване.

Наблюдение

Можете да използвате инструменти като MongoDB Cloud Manager, ClusterControl или друга рамка за наблюдение, за да прегледате ключови показатели на базата данни и да настроите аларми. Включете сигнали за показателите:

• Опашки
• Прозорец на протокол за репликация
• Твърдения
• Грешки в страницата
• Закъснение при репликация

Наблюдавайте хардуерните показатели за вашите сървъри. Обърнете специално внимание на наличното дисково пространство, използването на диска, процесора

Хардуер

Използвайте RAID10 и SSD устройства за идеална производителност.

SAN и виртуализация:

Уверете се, че всеки от екземплярите на mongod е осигурил IOPS за своя dbPath или има физическо устройство за искане или LUN.

Избягвайте динамични акценти в паметта, като например подуване на паметта, когато работите във виртуална среда.

Избягвайте да настройвате всички лица от набора от копия в една и съща SAN, тъй като SAN може да бъде само една точка на разочарование.

Балансиране на натоварването

Проектирайте балансьори на натоварване, за да активирате „залепващи сесии“ или „клиентски афинитет“ с подходящо време за изчакване за съществуващи връзки.

Избягвайте да поставяте балансьори на натоварване между компонентите на клъстера MongoDB или комплекта реплики.

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

Планирайте периодични тестове на процеса на архивиране и възстановяване, за да имате под ръка измерватели на времето и да потвърдите неговата полезност.

Конфигурация на операционната система

Windows

Помислете за деактивиране на надстройките за „последен достъп“ на NTFS.

Форматирайте NTFS дискове, като използвате размера на единицата за разпределение по подразбиране от 4096 байта.

Linux

Изключете огромните прозрачни страници.

Направете корекции в настройките за четене на заровете, където се съхраняват вашите файлове с база данни. Readahead на механизма за съхранение на WiredTiger трябва да бъде настроен между 8 и 32.

Ако използвате настроен на RHEL / CentOS, трябва да персонализирате коригирания си профил. Много от настроените профили, които се доставят с RHEL / CentOS, могат да повлияят неблагоприятно на изпълнението с техните настройки по подразбиране. Персонализирайте избрания от вас настроен профил за:

Деактивирайте директните огромни страници.

Задайте напред за четене между 8 и 32 във всеки случай на сортиране на носител с капацитет.

Използвайте планировчиците на дискове noop или крайния срок за SSD устройства.

Използвайте планировчика на дискове noop за виртуализирани устройства във виртуални машини за гости.

Деактивирайте NUMA или задайте vm.zone_reclaim_mode на 0 и стартирайте mongod събития с преплитане на възли.

Коригирайте граничните стойности на вашия хардуер, за да съответстват на вашия случай на употреба. В случай, че различни събития mongod или mongos се изпълняват под един и същ клиент, мащабирайте стойностите на ulimit по подобен начин.

Проектирайте адекватни манипулатори на запис (fs.file-max), частично ограничение на pid (kernel.pid_max), максимална нишка на процес (kernel.threads-max) и максимален брой очертани области на паметта на процес (vm.max_map_count) за вашето изпращане. За обширни рамки следните стойности дават чудесна начална точка:

fs.file-max value of 98000,

kernel.pid_max value of 64000,

kernel.threads-max value of 64000, and vm.max_map_count value of 128000

Уверете се, че вашата рамка има конфигурирано пространство за размяна.

Намеквайте към документацията на вашата операционна система за интересни точки относно правилния размер.

 Уверете се, че поддържането на TCP по подразбиране на системата е зададено точно. Стойност от 300 често дава превъзходна производителност за набори от реплики и разчленени клъстери.

Контролен списък за разработка на MongoDB

Репликация

Използвайте нечетен брой лица с право на глас, за да гарантирате, че изборите ще продължат ефективно. Ще имате до 7 лица с право на глас. В случай, че имате четен брой лица с право на глас и ограничения, като цена, забраняват включването на друг вторичен да бъде член с право на глас, ще можете да включите арбитър, който да гарантира нечетен брой гласове.

Гарантирайте, че вашите вторични файлове остават актуални, като използвате инструменти за наблюдение и като посочите подходяща загриженост за запис.

Не използвайте помощни четения за мащабиране на общата пропускателна способност на четене.

Дизайн на схема

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

Определете набора от колекции, които просто ще ви трябват, и индексите, необходими за поддържане на вашите заявки. Със специалния случай на индекса _id трябва да направите всички индекси изрично:MongoDB естествено не прави никакви индекси освен _id.

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

Уверете се, че вашият план за схема не зависи от индексирани клъстери, които растат по дължина без ограничения. Обикновено най-доброто изпълнение може да се постигне, когато такива индексирани клъстери имат по-малко от 1000 компонента.

Помислете за ограниченията за оценка на документа, когато проектирате вашата схема. Ограничението BSON Document Estimate е 16MB на документ. В случай, че имате нужда от по-големи отчети, използвайте GridFS.

Драйвери

Използвайте обединяването на асоциации. Повечето драйвери на MongoDB поддържат обединяване на асоциации. Променете размера на пула за асоциации, за да отговаря на вашия случай на използване, като се започне от 110-115% от нормалния брой едновременни изисквания за база данни.

Уверете се, че вашите приложения обработват временни грешки при запис и четене на фона на избори на набор от реплики.

Гарантирайте, че вашите приложения обработват неуспешни заявки и ги опитайте отново, ако е необходимо. Шофьорите не го правят

естествено повторете неуспешни заявки.

Използвайте експоненциална обосновка за отмяна за повторни опити на заявка за база данни.

Използвайте cursor.maxTimeMS() за четене и wtimeout за запис, в случай че искате да ограничите периода на изпълнение за операции с база данни.

Издръжливост на данните

Уверете се, че вашият набор от реплики включва най-малко три хъба, носещи данни, със загриженост за композиране на w:majority. Необходими са три хъба, носещи данни, за широка стабилност на данните с реплика.

Гаранция, че всички екземпляри използват журналиране.

Разделяне

Гарантирайте, че вашият ключ за шард пренася натоварването по равно на вашите фрагменти.

Използвайте насочени операции за натоварвания, които трябва да се мащабират с броя на фрагментите.

За MongoDB 3.6 и по-нататък вторичните вече не връщат осиротели данни, освен ако не използват загриженост за четене „налично“ (което е загрижеността за четене по подразбиране за четения спрямо вторични, когато не са свързани с причинно-следствено надеждни сесии).

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

Загрижеността за "достъпно" четене може да върне осиротели документи от спомагателни членове, тъй като не проверява за преработени метаданни на парчета. Във всеки случай, в случай че връщането на осиротели документи е незначително за дадено приложение, проблемът „налично“ за четене дава възможно най-малко четене при неактивност сред различните проблеми за четене.

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

Заключение 

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