Назад | Перейти на главную страницу

Перенос баз данных с SQL 2005 на 2008 - быстрое переключение с зеркалированием или репликацией

У нас работает несколько баз данных SQL 2005, которые я бы хотел перенести на SQL 2008. Экземпляр 2008 года запущен и работает. Каков рекомендуемый способ быстрого переключения с одного сервера на другой.

Мне нравится, когда приложение использует 2005 год, в то время как транзакции также переносятся на 2008 год, что позволяет мне настраивать вещи заранее. Затем группа разработчиков приложения может изменить свое подключение к экземпляру 2008 года и начать тестирование и обновление. Когда все будет хорошо, мы можем сломать любой механизм, выполняющий передачу и использование 2008 года.

Я немного знаком с зеркалированием и репликацией транзакций. Похоже, что зеркальное отображение будет работать, но мне нужно будет в нужный момент отказаться от зеркальной базы данных. В этом случае БД 2005 года станет непригодным для использования, и мы не сможем выполнить возврат, поскольку системные таблицы будут в формате 2008 года.

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

Спасибо

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

Репликация позволит вам читать от подписчика, но репликация не реплицирует все.

Также весьма необычно говорить о том, что команда разработчиков "изменяет и обновляет" копию. пока обновляется. Команда разработчиков должна протестировать и обновить тест база данных, не кандидат на производственное обновление ... Что произойдет с изменениями, несовместимыми с потоком входящих обновлений?

Типичный сценарий обновления выглядит следующим образом:

  • разработка приложения протестируйте, что приложение нормально работает со старой схемой в новой базе данных. Если выявлены проблемы, приложение исправлено (в базе данных не изменяется схема).
  • если требуются изменения схемы, они записываются как сценарии обновления, которые будут реализованы при развертывании новой версии.
  • команда разработчиков подписывает процедуру обновления (все модификации приложения и все модификации схемы)
  • Команда QA берет копию производственной БД и проверяет возможность обновления приложения, применяя все изменения схемы изменений двоичных файлов после обновления, как рекомендовано командой разработчиков.
  • Команда QA подписывает процедуру обновления
  • Операционная группа готовит обновление. Использование зеркалирования - отличный способ, но по причинам минимизации простой во время обновления, а не для проверки приложения, как вы предлагаете
  • Выполните обновление:
    • Снимите приложение
    • Отказаться от базы данных (или прервать зеркальное отображение, если вы хотите иметь безопасный / быстрый путь возврата)
    • Применить сценарии изменения схемы к новой базе данных
    • Применение бинарных патчей к приложению
    • запустить приложение на новой базе данных
    • запустить несколько минимальных проверочных тестов
    • разрешить доступ к приложению

Сделайте холодное резервное копирование баз данных и восстановите их в экземпляре 2008 года, как обычно, чтобы группа разработчиков приложений проверила, будут ли у них проблемы совместимости. Как только это будет принято, используйте зеркальное отображение или доставку журналов, чтобы синхронизировать базы данных. Во время запланированного простоя остановите LS / зеркальное отображение, переведите старые базы данных в автономный режим и восстановите базы данных 2008, а также попросите команду разработчиков изменить строку подключения или использовать псевдоним DNS для переключения на новый сервер.