Работните потоци за архивиране и възстановяване са изключително важни за всеки производствен клъстер MongoDB. Освен действителната функционалност за архивиране и възстановяване, трябва да вземете предвид и други нефункционални функции, като наличността на архиви, сигурност, време за възстановяване, детайлност на възстановяването и т.н. На високо ниво имате три опции за архивиране на вашия сървър MongoDB:
- Mongodump / Mongorestore
- MongoDB Cloud Manager
- Снимки на диска
Всяка от горните три техники има своите плюсове и минуси. Прочетете по-долу, за да разберете по-подробно.
1. Mongodump / Mongorestore
Mongodump е инструментът за архивиране на „начални стъпки“ за повечето разработчици на MongoDB. Вероятно това е начинът, по който повечето разработчици започват да архивират своята база данни MongoDB. Инструментът Mongodump е наистина лесен за използване и изхвърля всички данни в базата данни в двоичен формат (BSON), който можете да съхранявате на място по ваш избор.
Плюсове:
- Лесен за използване.
- Гъвкавост в мястото, където се съхранява резервното копие - след като дъмпът приключи, можете да го преместите на произволно място по ваш избор – NFS споделяния, AWS S3 и т.н.
Против:
- Пълно архивиране, всеки път – Това е пълно архивиране, а не разлика от предишното ви архивиране. Така че, тъй като базата ви данни става голяма, може да отнеме часове, за да завършите архивирането и е тромаво за съхранение.
- Не е момент във времето – Архивът, създаден от mongodump, не е моментна снимка по подразбиране. Така че, ако данните ви се променят по време на архивирането, можете да се окажете с mongodump, който е непоследователен от гледна точка на приложението. Можете да поправите това, като използвате опцията „–oplog“, която прави моментна снимка в края на процеса на mongodump. Тази опция обаче не е налична за самостоятелни бази данни
2. MongoDB Cloud мениджър
Cloud Manager е облачна услуга, предоставена от екипа на MongoDB, за да ви помогне да архивирате вашия MongoDB клъстер.
Плюсове:
- Лесен за използване – Инсталирайте агента MongoDB Cloud Manager, за да управлявате архивирането/възстановяването на вашия клъстер. Това е малко по-сложно от използването на mongodump, но не много.
- Непрекъснато архивиране – Cloud Manager непрекъснато прави заявки и архивира вашия oplog. Така че това ви позволява да възстановите до всеки момент от време, вместо до конкретни моменти, когато е направено архивирането, което минимизира излагането ви на загуба на данни.
Против:
- Контрол на данните – Архивните данни се съхраняват в центъра за данни на MongoDB извън вашия контрол. В някои части на света (напр. Европа) и в зависимост от вашите нужди от сигурност това може да бъде голям проблем.
- Допълнителни разходи – Вие плащате според размера на данните и размера на промените в oplog. Ако имате голяма база данни или голям брой записвания, тази цена може да се увеличи.
- Бавно възстановяване – За да възстановите вашите данни от MongoDB Cloud Manager, данните трябва да бъдат физически изтеглени от центъра за данни на Cloud Manager. Това може да отнеме много време, ако имате голяма база данни, например ако данните ви са 1TB, изтеглянето и използването на данните може да отнеме няколко часа.
3. Моментни снимки на диск
Моментните снимки могат да бъдат на ниво облак (напр. моментни снимки на AWS EBS диск) или на ниво ОС (LVM моментни снимки). LVM моментните снимки, макар и удобни, не са лесно преносими извън машината. Следователно до края на тази дискусия ще се съсредоточим върху моментни снимки на облачни дискове като моментни снимки на AWS EBS.
Плюсове:
- Прост и лесен за използване – Сравнително тривиално за задействане на моментна снимка на EBS диск.
- Преносимост – Можете да преместите вашите моментни снимки в други центрове за данни, ако имате нужда от по-висока наличност за вашите резервни копия.
- Различни моментни снимки – Моментните снимки са diff моментни снимки, така че те съхраняват само промените от предишната ви моментна снимка. Това намалява количеството хранилище, необходимо за вашето резервно копие.
- Няма копие на данни – Няма включено копие на данни за възстановяване на вашите данни. напр. Ако искате да възстановите моментна снимка от 1TB, можете просто да създадете нов том от моментната снимка и това не води до действително копие на данни. Това е * голяма работа * , когато работите с големи количества данни.
- Резервно управление – Резервните копия остават в същия център за данни като основните ви данни и са защитени от същите механизми за удостоверяване като основните ви сървъри за данни.
Против:
- Не е непрекъснато архивиране – Това е резервно копие в даден момент и може да бъде възстановено само до резервните точки.
- Физически машини – Физическите машини на място не могат да бъдат архивирани с помощта на тази техника.
В края на деня, ако данните ви са малки, и трите опции ще работят добре. Когато започнете да разполагате с по-големи количества данни, ще трябва да отделите време и да изберете опцията, която работи най-добре за вашия сценарий.
