Отстраняване на неизправности в MongoDB Sharded Cluster

В MongoDB големите набори от данни включват операции с висока пропускателна способност и това може да надхвърли капацитета на един сървър . Големите работни набори от данни налагат по-голямо напрежение върху входно/изходния капацитет на дисковите устройства и могат да доведат до проблем като грешки в страницата.

Има основно два начина за решаване на това...

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

Хоризонтално мащабиране чрез разделяне :Това включва разделяне на системния набор от данни върху множество сървъри, като по този начин се намалява общото натоварване за един сървър. Разширяването на капацитета на внедряването изисква само добавяне на повече сървъри за по-ниски общи разходи в сравнение с хардуера от висок клас за една машина. Това обаче идва с компромис, че ще има много сложност в инфраструктурата и поддръжката за внедряването. Сложността става по-сложна при отстраняване на неизправности в раздробения клъстер в случай на бедствие. В този блог предоставяме някои от възможностите за отстраняване на неизправности, които могат да помогнат:

Избор на ключове на фрагменти и наличност на клъстери

Екземпляр на Mongos става недостъпен

Член отсъства от набора реплики на фрагменти

Всички членове на набор от реплика отсъстват

Застоялите конфигурационни данни водят до откази на курсора

Конфигурационният сървър става недостъпен

Коригиране на грешка в низа на базата данни

Избягване на престой при преместване на конфигурационни сървъри

Избор на ключове на фрагменти и наличност на клъстер

Шардирането включва разделяне на данни на малки групи, наречени фрагменти, за да се намали общото натоварване за дадена пропускателна способност операция. Това групиране се постига чрез избор на оптимален ключ, който е основно най-важната част преди разделянето. Оптималният ключ трябва да гарантира:

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

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

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

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

Ами ако? Инстанция Mongos отсъства

Първо проверете дали се свързвате с правилния порт, тъй като може да сте променили несъзнателно. Например, при внедряване с платформата AWS, има вероятност от този проблем поради групите за сигурност, които може да не позволяват връзки на този порт. За незабавен тест опитайте да посочите пълния хост:порт, за да сте сигурни, че използвате интерфейс за обратна връзка. Хубавото е, че ако всеки сървър на приложения има свой собствен mongos екземпляр, сървърите на приложения може да продължат да имат достъп до базата данни. Освен това състоянията на mongos се променят с времето и могат да се рестартират, без непременно да губят данни. Когато екземплярът се свърже отново, той ще извлече копие на конфигурационната база данни и ще започне да маршрутизира заявки.

Уверете се, че портът, към който се опитвате да се свържете отново, също не е зает от друг процес.

Ами ако? Член отсъства от набора реплики на парчета

Започнете, като проверите състоянието на фрагмента, като изпълните командата sh.status(). Ако върнатият резултат няма clusterId, тогава фрагментът наистина е недостъпен. Винаги проучвайте прекъсванията и повредите в наличността и ако не успеете да го възстановите във възможно най-кратък срок, създайте нов член, който да го замени възможно най-скоро, за да избегнете повече загуба на данни.

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

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

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

Първоначалното синхронизиране ще позволи на MongoDB да...

Клонирайте всички налични бази данни с изключение на локална база данни. Уверете се, че целевият член има достатъчно дисково пространство в локалната база данни за временно съхраняване на oplog записите за времето, през което данните се копират.

Прилагане всички промени към набора от данни с помощта на oplog от източника. Процесът ще бъде завършен само ако състоянието на репликата премине от STARTUP2 към SECONDARY.

Ами ако? Всички членове на набор от реплики отсъстват

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

Ами ако? Застоялите конфигурационни данни водят до откази на курсора

Понякога на екземпляр на mongos може да отнеме много време, за да актуализира кеша на метаданните от конфигурационната база данни, което води до връщане на заявка предупреждението:

could not initialize cursor across all shards because : stale config detected

Тази грешка винаги ще се показва, докато екземплярите на mongos не обновят кеша си. Това не трябва да се разпространява обратно към приложението. За да коригирате това, трябва да принудите екземпляра да се опресни, като изпълните fluRouterConfig.

За прочистване на кеша за конкретно изпълнение на колекция

db.adminCommand({ flushRouterConfig: "<db.collection>" } )

За прочистване на кеша за изпълнение на конкретна база данни

db.adminCommand({ flushRouterConfig: "<db>" } )

За да изчистите кеша за всички бази данни и техните колекции, изпълнете:

db.adminCommand("flushRouterConfig") db.adminCommand( { flushRouterConfig: 1 } )

Ами ако? Конфигурационният сървър става недостъпен

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

Ако един център за данни се повреди, данните ще продължат да бъдат налични за четене, а не за никакви операции, ако сте използвали един център за данни .

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

Препоръчително е членовете да бъдат разпределени в поне три центъра за данни.

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

Коригиране на грешка в низа на базата данни

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

Избягване на престой при преместване на конфигурационни сървъри

Престой може да възникне в резултат на някои фактори като прекъсване на захранването или честоти на мрежата, което води до отказ на конфигурационен сървър към клъстера. Използвайте CNAME, за да идентифицирате този сървър за преименуване или преномериране по време на повторно свързване. Ако командата moveChunk commit не успее по време на процеса на миграция, MongoDB ще докладва грешката:

ERROR: moveChunk commit failed: version is at <n>|<nn> instead of <N>|<NN>" and "ERROR: TERMINATING"

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

Заключение

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

Ако приемем, че конфигурацията е направена правилно, някои неизбежни неуспехи, като прекъсвания на тока, също могат да настъпят. За да продължите да поддържате приложението си с минимално време на престой, помислете за използването на поне 3 центъра за данни. Ако единият не успее, другите ще бъдат на разположение да поддържат операции за четене, ако основният е сред засегнатите членове. Също така надстройте системата си до поне версия 3.4, тъй като поддържа повече функции.