Обмен серверами баз данных

Question

Здравствуйте, я по-прежнему новичок в развертывании базы данных.

Как правило, как изменения в производственной базе данных развернуты для выпуска?

Мой клиент хочет создать новую установку. У нас есть 3 среды: DEV, INT, PROD. Он хочет сделать INT как ПРОИЗВОДСТВО, когда QA сертифицирована. Это будет хорошо с серверами приложений, но поскольку состояние базы данных очень важно, это проблема для базы данных, потому что мы не можем сделать базу данных INT производственной, если мы не синхронизируем производственные данные с интеграцией. Но наша база данных имеет более 300 ГБ, поэтому потребуется много времени для синхронизации данных и, следовательно, огромного времени простоя, что нецелесообразно.

Можете ли вы, ребята, посоветуйте мне в этом сценарии.

Answer 1

Самый подходящий способ, которым я знаю, чтобы выполнить такую ​​синхронизацию до развертывания, заключается в автономной интеграции с использованием копий исходных данных. Сначала это может показаться тяжелым процессом, но оно имеет преимущества хранения исходных данных (проблемы могут всегда возникать во время синхронизации) и предоставление вам возможности провести все необходимые проверки с данными перед полным развертыванием.

Answer 2

Вот несколько советов для развертывания в производственной базе данных:

1. Всегда есть текущие резервные копии базы данных. На всякий случай что-то пойдет не так.
2. Убедитесь, что вы используете какой-то источник управления для своих скриптов. Как код. Проверка скриптов, хранимых процедур и т. Д.
3. Всегда есть сценарии отката для любых данные обновления. Например, есть сценарий, который обновляет 100 записей? Напишите сценарий, который временно копирует данные в другом месте и может восстановить любые сделанные вами изменения. Это легко проверить в DEV и INT. Дает вам немного спокойствия при внесении изменений в данные.
4. Всегда иметь резервную копию для любого схемы изменений. Если вы добавляете поле в таблицу, посмотрите, можно ли скопировать таблицу в временную таблицу и внести свои изменения. Не всегда возможно, если таблица действительно большая, но опять же, она позволяет быстро откат в случае ошибки.
5. Практика, практика, практика. Практика восстановления резервных копий старых производственных данных. Практика запуска ваших скриптов в DEV и INT. Будьте готовы к повторному развертыванию всех хранимых процедур в любой момент.

Еще одна тема, которая может быть жесткой, касающейся вас, имеет производственные данные в INT. Я бы регулярно восстанавливал резервные копии производственных баз данных в INT и DEV. Это хорошо стоит для QA, поскольку он предоставляет им как качество производственных данных, так и количество.

Я бы посоветовал не превращать базу данных INT в производство. Разработчики и QA всегда будут помещать мусорные данные для тестирования, и вы не хотите делать это вживую.