Блог

Главная - Вопросы по программированию - Зеркальное отображение SQL Server 2008 R2 для развертывания?

Зеркальное отображение SQL Server 2008 R2 для развертывания?

#sql #database-design #sql-server-2008-r2

#sql #проектирование базы данных #sql-server-2008-r2

Вопрос:

Мне интересно, возможно ли это и какой уровень знаний мне понадобится для этого. У меня есть 3 базы данных, все они построены на платформе SQL Server 2k8R2. 2 находятся на одном сервере, а 1 — на другом сервере, подключенном к той же сети. Один предназначен для разработки (вы знаете потрясающий, который вы можете сломать, укусить, пнуть, когда никто не смотрит и т.д.) Другой — это этап и, наконец, производство. Мне интересно, мог бы я настроить какой-нибудь тип зеркального отображения, который позволил бы мне сохранять программные изменения во всех трех из них. Например, если бы я должен был разработать новую таблицу и выполнить SPROC в моей базе данных разработчиков. Протестируйте и убедитесь, что все было хорошо и работает, есть ли способ, когда я фиксирую свои изменения, чтобы эта таблица вместе с ее ключами, индексами, FK и SPROC, которые я создал, автоматически генерировались в двух других базах данных без необходимости перезаписывать и запускать их. Простите мое невежество, я знаю, что могу запрограммировать изменения и просто загрузить каждое из них и запустить скрипт для генерации всех созданных мной объектов, но я хочу иметь возможность делать это в режиме реального времени «на лету». Является ли это чем-то безболезненным процессом, который можно легко выполнить? Я не хочу копировать данные внутри таблицы (таблиц), только программные фрагменты кода. Любая помощь приветствуется.

Большое спасибо, Джон

Ответ №1:

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

[Также обратите внимание: для зеркального отображения базы данных требуется SQL Server 2008 Enterprise Edition]

Вместо этого используйте надстройку проекта базы данных Visual Studio 2008 GDE (или теперь встроенную в VS 2010). В качестве альтернативы можно использовать инструменты синхронизации Redgate. Оба варианта могут быть включены в ваши автоматизированные процессы сборки.

Visual Studio 2010: работа с проектами баз данных

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

Обновление: в настоящее время я использую проекты базы данных VS2010 в рабочем процессе, аналогичном следующему:

  1. Получить последний исходный код
  2. Разверните текущую схему базы данных в моем локальном экземпляре SQL Server (включает предварительное заполнение статических справочных данных (и также может загружать реальные системные операционные данные)
  3. Вносите любые изменения схемы непосредственно в локальную базу данных (и любые связанные изменения кода локально).
  4. Сборка и тестирование локально.
  5. Используйте инструмент сравнения схемы проекта базы данных, чтобы сравнить локальную базу данных с моделью в проекте DB, синхронизировать для генерации ожидающих изменений схемы по сценарию.
  6. Проверьте все.
  7. развертывание одним щелчком мыши для тестирования системы и т.д. (Я остановился на некоторых деталях)

Комментарии:

1. Честно говоря, я не слишком обеспокоен производственной базой данных. Я полностью понимаю, о чем вы говорите. Меня больше интересует синхронизация стадии и производства. Итак, если я создаю и тестирую что-то в своей локальной базе данных, и это работает, я хотел бы иметь возможность автоматически запускать это в действие на сцене. Я думаю, что stage всегда должен на 100% имитировать производство с идеей, что если это работает на stage, перенос изменений в prod должен быть простым. Я смотрю на это совершенно неправильно?

2. «Я думаю, что stage всегда должен на 100% имитировать производство с идеей, что если это работает на stage, перенос изменений в prod должен быть простым» — это правильно. Я использую проекты баз данных VS2010 именно для этого.

3. @user724525, я бы настоятельно рекомендовал рассмотреть предложение @Mitch Wheat об использовании Red Gate tools в качестве альтернативы. Использую их для аналогичного рабочего процесса, описанного выше управление версиями, с 2006 года, проблем не возникало. Они создают резервную копию схемы до, что неплохо на случай, если вы допустили ошибку и захотите выполнить откат. Если RedGate слишком дорогой, посмотрите на [devart’s] ( devart.com/dbforge/sql/schemacompare ) предложения. Аналогично RedGate, но дешевле. Рассмотрите возможность автоматизации инструментов RedGate, чтобы сделать описанный выше рабочий процесс более простым (= меньше человеческих ошибок).

Ответ №2:

Вам следует рассмотреть более традиционные средства разработки, сборки и развертывания, такие как Visual Studio Database Edition, Red Gate tools, DBGhost, Team City и т.д. Это инструменты, разработанные для этой работы.

Зеркальное отображение вряд ли будет жизнеспособным вариантом по целому ряду причин. Этап зеркалирования до рабочей среды не имеет для меня особого смысла, потому что смысл этих сред как раз в том, что вы можете развертывать их независимо и что они не зависят друг от друга. Вы даже не упомянули тестовую среду (возможно, тестирование — это то, для чего вы используете stage?). В тестовой среде обычно также требуется возможность повторного развертывания, отката и исправления изменений и данных. Я подозреваю, что зеркальное отображение скорее помешает, чем поможет тестированию.