Вы сохраняете экспорт mysql в своем инструменте управления версиями для возврата в случае ошибки?

Мы запускаем внутренний веб-сервер с внутренним программным обеспечением для запуска производственной линии.

При добавлении новых функций продукта происходит одно или оба из следующих событий:

  1. Для поддержки этих изменений могут потребоваться изменения в собственном серверном программном обеспечении - это существенные изменения в функциональности, являющиеся кодовым диском.
  2. изменения в базе данных MySQL для новых записей для номеров деталей, это для небольших изменений, конфигураций, изменений уже существующих значений и параметров - такие изменения не требуют изменения кода. В идеале мы хотели бы, чтобы наши изменения были здесь, а не в пункте 1.

Пункт 1 является версией, управляемой в Subversion, поэтому предыдущие версии можно отнести к откату в случае проблем, возникших в последней версии.

Но как насчет изменений в базе данных MySQL?

У нас есть качественные процессы для обеспечения безошибочности таких изменений, но всегда есть вероятность, что ошибки могут пройти, например. ошибка ввода данных или ошибки с кодом, который использует MySQL, повреждающий базу данных и т. д.

У нас есть автоматическое резервное копирование каждые 6 часов, но что, если мы хотим использовать дополнительные контрольные точки вручную между этими интервалами, мы могли бы использовать одну и ту же систему резервного копирования, но я задавался вопросом, использовали ли здесь другие методы для хранения предыдущих состояний баз данных, например. экспорт базы данных в виде простого текстового SQL-дампа - по крайней мере с помощью этого метода можно было бы увидеть diffs, например. in Beyond Сравнить для устранения проблем.

Мысли?

1 голос | спросил therobyouknow 1 FebruaryEurope/MoscowbTue, 01 Feb 2011 17:11:42 +0300000000pmTue, 01 Feb 2011 17:11:42 +030011 2011, 17:11:42

3 ответа


2

У каждого из наших филиалов есть личная папка, внутри которой мы храним файлы исправлений для любых изменений SQL, как скрипта SQL, так и сценария возврата, в случае, если проблема должна быть отменена.

После выпуска патчи для всех ветвей разработки, которые являются частью выпуска, проверяются вместе, чтобы гарантировать отсутствие конфликтов.

ответил G3D 1 FebruaryEurope/MoscowbTue, 01 Feb 2011 18:00:30 +0300000000pmTue, 01 Feb 2011 18:00:30 +030011 2011, 18:00:30
1

Мы создали нашу собственную систему отслеживания истории /версии для данных в базе данных, аналогичную ответам здесь:

https://stackoverflow.com/questions/323065 /как к версии контроля-а-записи-в-базе данных

ответил blueberryfields 1 FebruaryEurope/MoscowbTue, 01 Feb 2011 19:53:57 +0300000000pmTue, 01 Feb 2011 19:53:57 +030011 2011, 19:53:57
0

Для конкретного проекта (приложения LAMP), над которым я сейчас работаю, у меня есть 2 репозитория Subversion. У меня есть репозиторий Project, который содержит исходный код и другой «поддерживающий» SVN-репозиторий. Репозиторий поддержки SVN содержит файлы, которые помогают мне в реализации приложения, но не используются приложением. Я держу диаграммы схемы базы данных, документы, перечисляющие мои глобальные переменные, и время от времени резервное копирование базы данных в репозиторий SVN поддержки. Таким образом, я могу перезаписать последнюю резервную копию, но все равно получить ее обратно, если нужно. Это также заставляет вещи менее clutered - мне просто нужно иметь один файл, который продолжает меняться для резервных копий БД.

ответил trip0d199 1 FebruaryEurope/MoscowbTue, 01 Feb 2011 17:22:35 +0300000000pmTue, 01 Feb 2011 17:22:35 +030011 2011, 17:22:35

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132