Изменения схемы SQL Server 2014 в многопользовательской среде 24/7

У нас установлен SQL Server 2014 Enterprise для запуска базы данных, которая должна быть доступна 24/7. Наша база данных достаточно велика (200 Гб +). Также у нас есть множество сервисов, которые ежеминутно попадают в нашу базу данных для чтения, обновления или вставки новых данных. Мы хотим предоставить нашим клиентам возможность «горячего» повторного развертывания и сделать наши ежедневные обновления (обновления .net и схемы) прозрачными для клиентов. Мы нашли решение, основанное на кластере с балансировщиком нагрузки, для обновления двоичных файлов нашего приложения, но у нас все еще есть некоторое недопонимание относительно процесса развертывания обновлений базы данных и каковы лучшие методы для решения этой проблемы.

Для изменений схемы отключите один сервер, примените изменения схемы, восстановите его, а затем примените те же изменения ко второму экземпляру. Можно ли это сделать с помощью инструментов SQL Server, и является ли это общим подходом? Как синхронизировать данные после резервного копирования сервера? Или я полностью думаю о неверном направлении и есть ли лучшие решения?

Наша общая схема изменений: добавить / удалить столбец, добавить / удалить хранимую процедуру

Ниже потребуется немного больше планирования и тестирования.

Сине-зеленая концепция:

Суть концепции Blue-Green состоит в том, чтобы разделить ваше производство на 2 среды, и они всегда одинаковы (синхронизация данных), где

1. Blue (Current) будет иметь текущую версию схемы / сборки или продукта и будет вашей "LIVE" средой.

2. В то же время Green будет вашей средой промежуточного тестирования / тестирования, в которой вы обновите схему / сборку или продукт до следующей версии, проведете полный регрессионный тест и получите одобрение ваших бизнес-пользователей. После того, как вы будете счастливы, в течение периода сокращения вы будете продвигать Green в качестве среды «LIVE» и понижать Blue до уровня подготовки / постановки или тестирования для следующего выпуска.

Таким образом, у вас будет намного меньше времени простоя, и риск сбоя развертывания в работающей системе (который находится в окне обслуживания, поскольку вы выполняете обновление) будет сведен к минимуму. Кроме того, следуя сине-зеленому подходу, вы будете колебаться между ЖИВОЙ и ПРЕДЫДУЩЕЙ версией, которая будет готовиться к следующей версии.

Опять же, это потребует больше оборудования / лицензирования, а также планирования и тестирования.

Большинство шагов можно автоматизировать с помощью DACPAC и PowerShell. Кроме того, если вы устанавливаете несколько экземпляров на одном сервере, убедитесь, что баланс памяти изменился при переключении между синим и зеленым. Среда LIVE получает больше памяти, чем среда Passive.

В моей нынешней среде мы внедрили модель Blue / Green для развертывания гибкого кода, которая позволяет нам продвигать код каждые 2 недели с достаточным количеством времени для тестирования и выхода из бизнеса. Кроме того, это откат на случай, если что-то пойдет не так. Мы автоматизировали большинство процессов развертывания, используя Dacpacs и PowerShell.

(Источник изображения)

Также обратитесь к статье Гранта Фричи о проблемах отката и восстановления; Проблемы и стратегии

Если ваша база данных не реплицируется, то добавление и удаление столбцов будет выполняться очень быстро. Потому что add column - это просто пустая позиция, которую создает SQL. Столбец Drop просто удалит ссылку.

В противном случае, если есть какое-то ограничение или индекс, будьте осторожны.

ADD/DELETEпроцедуры просто будут влиять на само выполнение. Рекомендация перед тем, как внести какие-либо изменения, выполнить перекомпиляцию.

sp_recompile 'myproc'