Является ли использование управления зависимостями разумной стратегией для резервного копирования базы данных?
Поэтому, хотя я в принципе согласен с часто цитируемой статьей "Получите вашу базу данных под контролем версий", похоже, что никто не решает проблему больших баз данных. Я говорю не только о схеме, но и о данных.
Кроме того, хотя я и большой сторонник DVCS, таких как git и Mercurial, они терпят неудачу при обработке больших файлов (не только двоичных).
Меня просто поразило, что это проблема управления конфигурацией, а не проблема контроля версий. Таким образом, я мог бы рассматривать дамп SQL как артефакт сборки, сохранять резервную копию как ревизию артефакта и связывать ее через манифест в проекте, я мог бы делать то же самое для каждой отдельной среды (подготовка, разработка, производство, так далее.). Единственный недостаток, который я обнаружил, заключается в том, что хранилища артефактов сборки (такие как Artifactory и Nexus), по-видимому, не обрабатывают исправления артефактов эффективным способом хранения (например, дифференциальное резервное копирование).
Мой вопрос разбит на две части:
А) Является ли это - создание полной резервной копии базы данных - разумной стратегией, достаточно надежной для продуктивной среды? То есть, действительно ли это (или что-то близкое) сделано в реальном мире?
Б) Какова наилучшая практика для управления (и использования!) Резервных копий базы данных таким образом, чтобы конкретная резервная копия могла прослеживаться до заданной версии производительного приложения?
1 ответ
Изменения схемы базы данных являются проблемой развертывания. Каждая версия проекта должна иметь код, который обновляет базу данных с предыдущей версии. Ваш промежуточный сервер должен быть зарезервирован, и вы можете попробовать изменения там.