Най-новата ни версия на ClusterControl превръща някои от най-проблемните задачи на MongoDB в работа само за 15 секунди. Добавени са нови функции, за да ви дадат повече контрол върху вашия клъстер и да извършвате промени в топологията:
- Преобразуване на MongoDB replicaSet в разчленен MongoDB клъстер
- Добавяне и премахване на фрагменти
- Добавяне на маршрутизатори за сегменти към разчленен MongoDB клъстер
- Отстъпете или замразете възел
- Нови съветници на MongoDB
Ще опишем тези добавени функции подробно по-долу.
Преобразуване на MongoDB ReplicaSet в разчленен MongoDB клъстер
Тъй като повечето потребители на MongoDB ще започнат с replicaSet, за да съхраняват своята база данни, това е най-често използваният тип клъстер. Ако случайно срещнете проблеми с мащабирането, можете да мащабирате този replicaSet или като добавите още вторични елементи, или го намалите чрез раздробяване. Можете да конвертирате съществуващ replicaSet в раздробен клъстер, но това е дълъг процес, при който лесно можете да направите грешки. В ClusterControl ние автоматизирахме този процес, при който автоматично добавяме конфигурационните сървъри, маршрутизаторите за сегменти и активираме разделяне.
За да конвертирате replicaSet в разделен клъстер, можете просто да го задействате чрез падащото меню за действия:
Това ще отвори диалог в две стъпки за това как да конвертирате това в шард. Първата стъпка е да дефинирате къде да разположите Configserver и маршрутизаторите за шард към:
Втората стъпка е къде да се съхраняват данните и кои конфигурационни файлове трябва да се използват за конфигурационния сървър и рутера за шард.
След като задачата за мигриране на фрагменти приключи, прегледът на клъстера вече показва фрагменти вместо екземпляри на replicaSet:
След конвертиране в разделен клъстер могат да се добавят нови фрагменти.
Добавяне или премахване на части от разчленен MongoDB клъстер
Добавяне на парчета
Тъй като MongoDB фрагмент технически е replicaSet, добавянето на нов фрагмент включва и разполагането на нов replicaSet. В рамките на ClusterControl първо разгръщаме нов replicaSet и след това го добавяме към раздробения клъстер.
От потребителския интерфейс на ClusterControl можете лесно да добавяте нови фрагменти с помощта на съветник в две стъпки, отворен от падащото меню за действия:
Тук можете да дефинирате топологията на новия шард.
След като новият фрагмент бъде добавен към клъстера, рутерът на MongoDB ще започне да му присвоява нови парчета и балансира автоматично ще балансира всички парчета върху всички парчета.
Премахване на парчета
Премахването на фрагменти е малко по-трудно, отколкото добавянето на фрагмент, тъй като това включва преместване на данните към другите фрагменти, преди да премахнете самия фрагмент. За всички данни, които са били разделени върху всички сегменти, това ще бъде работа, извършена от балансира MongoDB.
Въпреки това всяка неразчленена база данни/колекция, на която е присвоен този шард като негов основен шард, трябва да бъде преместен в друг шард и да се направи нов основен шард. За този процес MongoDB трябва да знае къде да премести тези бази данни/колекции без разделяне.
В ClusterControl можете просто да ги премахнете чрез падащото меню за действия:
Това ще ви позволи да изберете фрагмента, който искате да премахнете, и този, към който искате да мигрирате всички основни бази данни:
След това задачата, която премахва фрагмента, ще извърши подобни действия, както е описано по-рано:ще премести всички първични бази данни към определения шард, ще активира балансира и след това ще изчака да премести всички данни от фрагмента.
След като всички данни бъдат премахнати, частта ще бъде премахната от потребителския интерфейс.
Добавяне на допълнителни MongoDB Shard рутери
След като започнете да мащабирате приложението си с помощта на разчленен клъстер MongoDB, може да откриете, че имате нужда от допълнителни маршрутизатори за сегменти.
Добавянето на допълнителни рутери за шард MongoDB е много прост процес с ClusterControl, просто отворете диалога Добавяне на възел от падащото меню за действия:
Това ще добави нов рутер за шард към клъстера. Не забравяйте да зададете правилния порт по подразбиране (27017) на рутера.
Намаляване на сървъра
В случай, че искате да извършите поддръжка на първичния възел в replicaSet, по-добре е той първо да „отстъпи“ по изящен начин, преди да го изведете офлайн. Оттеглянето на основно основно означава, че хостът престава да бъде основен и става вторичен и не отговаря на условията да стане основен за определен брой секунди. Възлите в MongoDB replicaSet с право на гласуване ще изберат нов първичен с изключен първичен надолу за определения брой секунди.
В ClusterControl сме добавили функцията за понижаване като действие на страницата Nodes. За да се оттеглите, просто изберете това като действие от падащото меню:
След като зададете броя на секундите за понижаване и потвърждение, първичният ще се оттегли и ще бъде избран нов първичен.
Замразяване на възел
Тази функционалност е подобна на командата step down:това прави определен възел недопустим да стане основен за определен брой секунди. Това означава, че можете да предотвратите един или повече вторични възли да станат първични, когато оттеглите основния, и да принудите определен възел да стане нов първичен по този начин.
В ClusterControl сме добавили функционалността на възел за замразяване като действие на страницата Nodes. За да замразите възел, просто изберете това като действие от падащото меню:
След като зададете броя на секундите и потвърдите, възелът няма да отговаря на условията като основен за зададения брой секунди.
Нови MongoDB съветници
Съветниците са мини програми, които предоставят съвети по конкретни проблеми с базата данни. Добавихме три нови съветника за MongoDB. Първият изчислява прозореца за репликация, вторият наблюдава прозореца за репликация, а третият проверява за неразчленени бази данни/колекции.
Съветник за забавяне на репликацията на MongoDB
Закъснението при репликация е много важно, за да следите, ако увеличавате четенията чрез добавяне на още вторични. MongoDB ще използва тези вторични данни само ако не изостават твърде много. Ако вторичният има забавяне на репликацията, рискувате да обслужите остарели данни, които вече са били презаписани на основния.
За да проверите забавянето на репликацията, достатъчно е да се свържете с основния и да извлечете тези данни с помощта на командата replSetGetStatus. За разлика от MySQL, първичният следи състоянието на репликация на своите вторични.
Внедрихме тази проверка в съветник в ClusterControl, за да гарантираме, че вашето забавяне на репликацията винаги ще бъде наблюдавано.
Съветник за прозорец за репликация на MongoDB
Точно като забавянето на репликацията, прозорецът за репликация е също толкова важен показател, който трябва да се разгледа. Съветникът за изоставане вече ни информира за броя секунди, в които вторичният възел е зад основния/главния. Тъй като oplog е ограничен по размер, наличието на подчинено забавяне налага следните рискове:
- Ако възел изостава твърде много, той може да не е в състояние да навакса повече, тъй като транзакциите, необходими за наваксване, вече не са в oplog на основния.
- Изоставащият вторичен възел е по-малко предпочитан при избори в MongoDB за нов първичен. Ако всички вторични елементи изостават в репликацията, ще имате проблем и този с най-малко забавяне ще бъде направен първичен.
- Вторичните, изоставащи, са по-малко предпочитани от драйвера на MongoDB при мащабиране на четения с MongoDB, той също така добавя по-голямо натоварване на останалите вторични.
Ако имаме вторичен възел, изоставащ с няколко минути (или часове), би било полезно да имаме съветник, който да ни информира колко време ни остава, преди следващата ни транзакция да бъде премахната от oplog. Времевата разлика между първия и последния запис в oplog се нарича прозорец за репликация. Този показател може да бъде създаден чрез извличане на първия и последния елемент от oplog и изчисляване на разликата в техните времеви марки.
В обвивката на MongoDB вече има налична функция, която изчислява прозореца за репликация вместо вас. Тази функция обаче е вградена в обвивката на командния ред, така че всяка външна връзка, която не използва обвивката на командния ред, няма да има тази вградена функция. Затова създадохме съветник, който ще наблюдава прозореца за репликация и ще ви предупреждава, ако надхвърлите предварително зададен праг.
Съветник за бази данни и колекции без разпределение на MongoDB
Базите данни и колекциите, които не са разделени, ще бъдат присвоени на първичен шард по подразбиране от рутера за шард MongoDB. Това означава, че базата данни или колекцията е ограничена до размера на този първичен фрагмент и ако се записва в големи обеми, може да използва цялото останало дисково пространство на шарда. След като това се случи, фрагментът очевидно вече няма да функционира. Ето защо е важно да наблюдавате всички съществуващи бази данни и колекции и да сканирате конфигурационната база данни, за да потвърдите, че те са активирани за разделяне.
За да предотвратим това да се случи, създадохме неразчленена база данни и съветник за събиране. Този съветник ще сканира всяка база данни и колекция и ще ви предупреди, ако не е била разчленена.
ClusterControl подобри поддръжката на MongoDB
Направихме голяма стъпка, като добавихме всички подобрения към ClusterControl за MongoDB replicaSets и разчленени клъстери. Това значително подобрява използваемостта на MongoDB и позволява на DBA, sysops и devops да поддържат своите клъстери още по-добре!
