Ако хоствате своя MongoDB клъстер в Amazon AWS US-East регион, последният месец беше доста интересен – две прекъсвания за четири седмици тестваха оперативната готовност на вашия облак разгръщания. Докато пиша тази публикация в блога, регионът на Сао Пауло също изпитва проблеми със свързаността. Изненадващ брой производствени бази данни не оцеляха след прекъсването на AWS. Имахме възможността да говорим с редица клиенти на MongoDB на AWS, за да разберем как прекъсването се отрази на внедряването им. Направих бърза анкета на засегнатите лица и ето четирите основни причини, поради които екипите са имали престой:
-
Изпълнение на самостоятелен екземпляр спрямо набор от реплики
Ако използвате производствен MongoDB сървър, наистина няма извинение да стартирате самостоятелен екземпляр спрямо набор от реплики. Създайте набор от реплики, за да можете да имате вторичен за преодоляване на отказ в случай на първична грешка.
-
Не се разпространяват реплики в зони за наличност
Уверете се, че разпространявате своите реплики в различни зони за наличност в даден регион. По този начин, ако един AZ изпадне, както се случи два пъти този месец, останалите ви сървъри ще поемат контрола и ще имате функциониращ клъстер. Ако вашият регион има само две AZ, поставете своя арбитър в друг регион. Това обаче няма да ви помогне, ако целият регион падне. Ако искате да преживеете целия провал в региона на AWS, ще трябва да разпределите своя набор от реплика в различни региони.
-
Не разпространявате вашите предни части или сървъри на приложения в зони за наличност
Уверете се, че разпределяте своите интерфейси в различни зони за наличност. Няма смисъл да поддържате базата си данни и да работи, ако вашият преден край не работи. Ако имате проблеми с разходите, можете да поддържате актуален преден край „спрян“ във всяка AZ, който можете да включите в случай на нужда. Друг вариант е да имате по-малък размер предни части.
-
Свържете се с набора реплики спрямо единичен сървър във вашия низ за връзка
Уверете се, че се свързвате с набора реплика вместо с един сървър. Синтаксисът е различен за различните драйвери, но проверете документацията на вашия драйвер, за да се уверите, че използвате правилния синтаксис, за да се свържете с набора реплика вместо с един сървър. По този начин, ако има отказ, драйверът на MongoDB ще направи правилното нещо и ще се свърже с новия първичен.
В ScaleGrid ние автоматизираме всички оперативни аспекти на вашето внедряване, за да можете да се съсредоточите върху приложението си и да не се притеснявате за операциите. Когато създадете набор от реплики на MongoDB с ScaleGrid, ние автоматично разпределяме репликите между зоните за наличност. Благодарение на това разпространение всички наши клиенти можеха безопасно да се ориентират в проблема с престоя на AWS. Ако се интересувате от по-подробно четене за оперативните аспекти на MongoDB, можете да прочетете моята по-ранна подробна публикация в блога – 10 въпроса, които да зададете и да отговорите, когато хоствате MongoDB на AWS
