Системите за бази данни носят отговорност да съхраняват и осигуряват постоянна наличност на съответните данни, когато е необходимо, по всяко време на работа. Повечето компании не успяват да продължат с бизнеса си след случаи на загуба на данни в резултат на повреда на базата данни, мост за сигурност, човешка грешка или катастрофална повреда, която може напълно да унищожи работните възли в производството. Поддържането на бази данни в един и същ център за данни излага човек на висок риск от загуба на всички данни в случай на тези безчинства.
Репликацията и архивирането са често използваните начини за осигуряване на висока наличност на данни. Изборът между двете зависи от това колко често се променят данните. Архивирането е най-добре за предпочитане там, където данните не се променят по-често и не се очаква да има толкова много архивни файлове. От друга страна, репликацията е предпочитана за често променящи се данни, освен някои други предимства, свързани като обслужване на данни на конкретно място чрез намаляване на латентността на заявките. Въпреки това, както репликацията, така и архивирането могат да се използват за максимална цялост и последователност на данните по време на възстановяване във всеки случай на повреда.
Архивирането на бази данни предоставя повече предимства, освен осигуряването на точка за възстановяване за осигуряване на основи за създаване на нови среди за разработка, отворен достъп и етапи, без да се ограничава производството. Екипът за разработка може бързо и лесно да тества новите интегрирани функции и да ускори тяхното развитие. Резервните копия могат да се използват и за контролната точка за грешки в кода, когато получените данни не са последователни.
Съображения за архивиране на MongoDB
Архивните копия се създават в определени точки, за да отразяват (действащи като моментна снимка на базата данни) какви данни хоства базата данни в дадения момент. Ако базата данни се провали в даден момент, можем да използваме последния архивен файл, за да върнем обратно DB до точка, преди да се провали. Въпреки това, човек трябва да вземе предвид някои фактори, преди да извърши възстановяване и те включват:
- Цел на точката за възстановяване
- Цел за време за възстановяване
- Изолация на база данни и моментни снимки
- Усложнения при разделяне
- Процес на възстановяване
- Фактори на производителност и налично място за съхранение
- Гъвкавост
- Сложност на внедряването
Цел на точката за възстановяване
Това се извършва, за да се определи колко данни сте готови да загубите по време на процеса на архивиране и възстановяване. Например, ако имаме потребителски данни и данни за поток от кликвания, на потребителските данни ще бъде даден приоритет пред анализа на потока кликвания, тъй като последният може да бъде регенериран чрез наблюдение на операциите във вашето приложение след възстановяване. Непрекъснатото архивиране трябва да се предпочита за критични данни като банкова информация, данни от производствената индустрия и информация за комуникационните системи и трябва да се извършва на близки интервали. Ако данните не се променят често, може да е по-евтино да загубите голяма част от тях, ако направите възстановена моментна снимка например 6 месеца или 1 година по-рано.
Цел за време за възстановяване
Това е за анализ и определяне колко бързо може да се извърши операцията по възстановяване. По време на възстановяване вашите приложения ще претърпят известно време на престой, което също е право пропорционално на количеството данни, които трябва да бъдат възстановени. Ако възстановявате голям набор от данни, това ще отнеме повече време.
Изолация на база данни и моментни снимки
Изолацията е мярка за това колко близо са резервните моментни снимки от основните сървъри на бази данни по отношение на логическа конфигурация и физически. Ако случайно са достатъчно близо, времето за възстановяване намалява за сметка на повишената вероятност да бъдат унищожени в същото време, когато базата данни е унищожена. Не е препоръчително да хоствате резервни копия и производствената среда в една и съща система, за да избегнете смущенията на сървърите от смекчаване и в резервните копия.
Усложнения с разделяне
За разпределена система на база данни чрез разделяне се представя известна сложност на архивирането и може да се наложи да се постави на пауза дейностите по запис в цялата система. Различните фрагменти ще завършат различни видове архивиране по различно време. Като се имат предвид логическите архиви и резервните копия на моментни снимки,
Логически архиви
- Частчетата са с различни размери, следователно ще завършват по различно време
- Дампата на базата на MongoDB ще игнорират --oplog, следователно няма да са последователни за всеки шард.
- Балансьорът може да е изключен, докато се предполага, че е включен, само защото някои фрагменти може би не са завършили процеса на възстановяване
Архивни копия на моментни снимки
- Работи добре за една реплика от версии 3.2 и по-нови. Следователно трябва да помислите за актуализиране на вашата версия на MongoDB.
Процес на възстановяване
Някои хора правят резервни копия, без да тестват дали ще работят в случай на възстановяване. Резервното копие по същество е да осигури възможност за възстановяване, в противен случай ще се окаже безполезно. Винаги трябва да се опитвате да стартирате резервните копия на различни тестови сървъри, за да видите дали работят.
Фактори на производителност и налично място за съхранение
Архивните копия също са склонни да приемат много размери като данните от самата база данни и трябва да бъдат компресирани достатъчно, за да не заемат много ненужно пространство, което може да намали общите ресурси за съхранение на системата. Те могат да бъдат архивирани в zip файлове, като по този начин се намаляват общите им размери. Освен това, както бе споменато по-горе, можете да архивирате архивите в различни центрове за данни от самата база данни.
Резервните копия могат да определят различни производителности на базата данни, тъй като някои могат да я влошат. В този случай непрекъснатото архивиране ще доведе до известна неуспех, следователно трябва да се преобразува в планирано архивиране, за да се избегне изчерпването на прозорците за поддръжка. В повечето случаи се разполагат вторични сървъри, за да поддържат архивиране. В този случай:
- Отделните възли не могат да се архивират последователно, защото MongoDB използва read-uncommitted без oplog при използване на командата mongodump и в този случай архивирането няма да бъде безопасно.
- Използвайте вторични възли за архивиране, тъй като самият процес отнема време в зависимост от количеството на включените данни и свързаните приложения ще имат известно време на престой. Ако използвате основния, който също трябва да актуализира Oplogs, тогава може да загубите някои данни по време на този престой.
- Процесът на възстановяване отнема много време, но присвоените ресурси за съхранение са малки.
Гъвкавост
Много пъти може да не искате някои от данните по време на архивиране, като например за целта на точката за възстановяване, може да искате възстановяването да бъде извършено и да филтрирате данните за кликванията на потребителя. За да направите това, имате нужда от стратегия за частично архивиране, която ще осигури гъвкавост за филтриране на данните, които няма да ви интересуват, следователно ще намали продължителността на възстановяване и ресурсите, които биха били пропилени. Инкременталното архивиране също може да бъде полезно, така че само части от данни, които са променени, ще бъдат архивирани от последната моментна снимка, вместо да се правят цели резервни копия за всяка моментна снимка.
Сложност на внедряването
Вашата стратегия за архивиране трябва да бъде лесна за настройка и поддръжка с времето. Можете също така да планирате архивирането си, така че да не се налага да ги правите ръчно, когато пожелаете.
Заключение
Системите за бази данни гарантират „живот след смъртта“, само ако има добре установена система за архивиране. Базата данни може да бъде унищожена от катастрофални фактори, човешка грешка или атаки за сигурност, които могат да доведат до загуба или повреда на данни. Преди да направите резервно копие, трябва да вземете предвид вида на данните по отношение на размера и важността. Винаги не е препоръчително да съхранявате резервните си копия в същия център за данни като вашата база данни, за да намалите вероятността резервните копия да бъдат унищожени едновременно. Архивите могат да променят производителността на базата данни, поради което трябва да внимавате за стратегията, която да използвате и кога да извършите архивирането. Не правете резервните си копия на основния възел, тъй като това може да доведе до прекъсване на системата по време на архивирането и следователно загуба на важни данни.
