Конфигуриране на сървърни протоколи
MongoDB 3.0 и по-ранни версии поддържат само един тип протокол за разгръщане на конфигурационен сървър, който се нарича наследен SCCC (Конфигурация на свързване на синхронизиращ клъстер) от MongoDB 3.2. Внедряването на SCCC има или 1 конфигурационен сървър (само за разработка) или 3 конфигурационни сървъра (производствен).
MongoDB 3.2 отхвърля протокола SCCC и поддържа нов тип разполагане:Конфигуриране на сървъри като комплекти реплики (CSRS). Внедряването на CSRS има същите ограничения като стандартен набор от реплики, който може да има 1 конфигурационен сървър (само за разработка) или до 50 сървъра (производство), както при MongoDB 3.2. Препоръчват се минимум 3 CSRS сървъра за висока наличност при производствено внедряване, но допълнителни сървъри може да са полезни за географски разпределени внедрявания.
SCCC (Конфигурация на връзката на синхронизиращ клъстер)
Със SCCC сървърите за конфигурация се актуализират с помощта на двуфазов комит протокол, който изисква консенсус от множество сървъри за транзакция. Можете да използвате един конфигурационен сървър за целите на тестване/разработка, но при производствена употреба винаги трябва да имате 3. Практически отговор защо не можете да използвате само 2 (или повече от 3) сървъра в MongoDB е, че кодовата база на MongoDB само поддържа 1 или 3 конфигурационни сървъра за SCCC конфигурация.
Три сървъра предоставят по-силна гаранция за съгласуваност от два сървъра и позволяват дейност по поддръжка (например резервни копия) на един конфигурационен сървър, като същевременно имате два налични сървъра за вашия mongos за запитване. Повече от три сървъра биха увеличили времето, необходимо за предаване на данни във всички сървъри.
Метаданните за вашия шардинг клъстер трябва да бъдат идентични във всички конфигурационни сървъри и се поддържат от изпълнението на шардинг на MongoDB. Метаданните включват основните подробности за това кои шардове в момента съдържат диапазони от документи (известни още като chunks ). В конфигурация на SCCC конфигурационните сървъри не са набор от реплики, така че ако един или повече конфигурационни сървъри са офлайн, тогава конфигурационните данни ще бъдат само за четене -- в противен случай няма начин данните да се разпространят до офлайн конфигурационните сървъри, когато те отново са онлайн.
Ясно е, че 1 конфигурационен сървър не осигурява излишък или резервно копие. При 2 конфигурационни сървъра, потенциален сценарий за повреда е, когато сървърите са налични, но данните на сървърите не са съгласни (например един от сървърите е имал някаква повреда в данните). С 3 конфигурационни сървъра можете да подобрите предишния сценарий:2/3 сървъра може да са последователни и можете да идентифицирате странния сървър.
CSRS (Конфигуриране на сървъри като комплекти реплики)
MongoDB 3.2 отхвърля използването на три огледални mongod екземпляри за конфигурационни сървъри и започвайки от 3.2 конфигурационните сървъри (по подразбиране) се разполагат като набор от реплики. Сървърите за конфигурация на реплики трябва да използват WiredTiger 3.2+ машина за съхранение (или друга система за съхранение, която поддържа новия readConcern
чете семантиката на изолацията). CSRS също така забранява някои опции за конфигуриране на набор от реплики, които не са по подразбиране (напр. arbiterOnly , buildIndexes и slaveDelay ), които са неподходящи за случай на използване на метаданни на фрагментиран клъстер.
Внедряването на CSRS подобрява последователността и наличността за конфигурационните сървъри, тъй като MongoDB може да се възползва от протоколите за четене и запис на стандартния комплект реплики за разделяне на конфигурационни данни. В допълнение, това позволява на шардирания клъстер да има повече от 3 конфигурационни сървъра, тъй като набор от реплики може да има до 50 члена (както при MongoDB 3.2).
При внедряване на CSRS наличността на запис зависи от поддържането на кворум от членове, които могат да видят текущия основен за набор от реплики. Например набор от реплики с 3 възела ще изисква 2 налични члена за поддържане на основен. Могат да се добавят допълнителни членове за подобрена толерантност към грешки , предмет на същите изборни правила
като нормален комплект реплики. readConcern от majority се използва от mongos за да се гарантира, че фрагментираните метаданни на клъстера могат да бъдат прочетени само след като бъдат ангажирани към по-голямата част от членовете на набор от реплики и readPreference от nearest се използва за насочване на заявки към най-близкия конфигурационен сървър.
