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

Перемещение базы данных SQL-Server с нулевым временем простоя

Можно ли переместить базу данных sql server 2005 на другой сервер, на котором запущен sql server 2008, без простоя? Система работает круглосуточно и без выходных, и ее необходимо переместить на другой сервер с другим хранилищем.

Мы попытались скопировать базу данных, но это не позволило синхронизировать всю базу данных в конце процесса.

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

Опция 1:

  • настройка доставки журнала для существующего сервера 2005 года и нового сервера 2008 года.
  • Планируйте переключение, тщательно переключая IP-адреса и / или имена хостов.
  • Убедитесь, что вы сделали последнюю резервную копию хвостового журнала перед окончательным переключением.

Вариант 2 (больше работы, меньше простоев):

  • Если ваша коробка 2008 года новая, то сначала установите 2005 на тот же sp, что и ваш prod box.
  • Настройте зеркальное отображение базы данных, асинхронное на первом этапе, чтобы избежать накладных расходов на производительность.
  • Настройте своих клиентов так, чтобы в строке подключения был указан резервный партнер.
  • Измените синхронизацию зеркального отображения базы данных и отработки отказа на новое поле
  • выполните «последовательные шаги обновления» для обновления на месте 2005-2008 гг. для настройки зеркального отображения базы данных

Конечно, чтобы понять это правильно, вам нужно будет протестировать и убедиться, что вы ничего не пропустили, когда делаете это по-настоящему :)

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

репликация транзакций - ваш друг ...

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

Очень запутанный способ сделать это ... (почти)

  1. P2V сервер в кластер VMware. Без простоев.
  2. Создайте второй сервер и создайте активный / пассивный кластер.
  3. Обновите пассивный узел до 2008 и переключитесь на него.
  4. Прибыль?

Очевидно, что здесь все требует тестирования, многие подробные шаги упущены.

ИЛИ - Заставьте руководство согласиться на простой и заранее сообщите об этом своим клиентам. Тогда потренируйтесь и испытайте апгрейд до смерти!

Объясните руководству технические трудности, связанные с попыткой сделать это «дешево». Это то, что вы ВСТРАИВАете в систему, когда впервые создаете архитектуру полной 27x7.

Даже самые большие системы запланировали простои. Это НЕПЛАНОВЫЙ простой, о котором вам нужно беспокоиться больше.

Боюсь, вы не добьетесь этого только с помощью SQL Server. Раньше я использовал продукт под названием Double Take, который позволял вам клонировать БД на другой сервер, а затем переключаться при отказе, когда это удобно.

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

Если сейчас это просто установка с одним экземпляром / некластеризацией, вы не сможете достичь 0% простоя без потери данных. Если БД в основном читается, и лучше потерять пару операций записи, а затем отключить БД, тогда у вас могут быть некоторые варианты.

Вы можете сделать полное резервное копирование БД COPY_ONLY, а затем после этого переместите файл bak в новое хранилище сервера. Восстановите базу данных до нового экземпляра SQL и заново запишите строки подключения, где это возможно (надеюсь, это всего лишь один файл inc где-нибудь), и перезапустите свои сайты. На сайте произойдет сбой, и активные сеансы будут перезапущены.

Тем не мение. вы потеряете все записи между моментом резервного копирования и восстановления.

Вы можете попытаться достичь этого с минимальным временем простоя (пара секунд до отработки отказа), используя решение db mirror. Вы можете взглянуть на эту статью MSDN для получения дополнительной информации: http://msdn.microsoft.com/en-us/library/bb677181.aspx

Том

Если вы используете решение .NET в качестве сервера приложений, который использует структуру 2.0, тогда предложение tvanzele должно работать нормально. Шаги ниже:

  • Убедитесь, что ваша основная база данных находится в режиме ПОЛНОГО восстановления и вы делаете резервные копии журналов.
  • Установите экземпляр SQL SQLEXPRESS или стандартной версии для работы в качестве следящего сервера.
  • Резервное копирование и восстановление ПОЛНОЙ резервной копии и резервной копии журналов на новом экземпляре (не на свидетеле)
  • Настройте зеркальное отображение базы данных для нового экземпляра SQL и используйте экземпляр SQLEXPRESS / Standard в качестве свидетеля.
  • измените строку подключения в приложении, чтобы распознать отказоустойчивый сервер, для справки см. connectionstrings.com
  • Передайте базу данных зеркалу, перезапустив старый экземпляр
  • Измените строку подключения для приложения, чтобы использовать только экземпляр аварийного переключения
  • Прервать зеркальное отображение

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

http://sqlserverpedia.com/blog/sql-server-2008/cutover-30-gb-databases-in-60-seconds-with-sql-server-20052008/

Я бы посоветовал вам сделать это с помощью Редгейт программное обеспечение. SQL Compare поможет вам воссоздать точно такую ​​же структуру во вновь созданной базе данных на другом сервере. А затем вы используете SQL Compare Data который создает для вас сценарии «копирования» и выполняет их (или сохраняет на будущее). Работает как шарм. Я использую его для копирования файлов между prod / dev db.

Это хорошо, потому что ты умел Sql Data Compare один раз. А затем, когда он переместил некоторые данные (и новые данные поступили в старую базу данных), вы могли перезапустить его снова, чтобы он синхронизировал различия только за пару секунд.

С помощью SQL Data Compare Pro вы можете сравнивать и синхронизировать действующие базы данных SQL Server с резервными копиями, сравнивать две резервные копии или работать с папками сценариев SQL в системе управления версиями. С помощью интерфейса командной строки вы можете автоматизировать задачи и сравнения графиков для облегчения составления контрольного журнала.

Redgate SQL Toolbelt твой друг навсегда (я никак не связан с Redgate): p

В качестве примечания. Поскольку данные довольно большие, я бы предложил использовать SQL Data Compare для использования в кусках (пара таблиц на копию). Затем, позже, при окончательной синхронизации, чтобы синхронизировать любые различия, которые произошли в течение периода копирования (даже если вам потребовалось 3 часа, потребуется всего лишь синхронизировать пару сотен строк или около того).

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

Я действительно оказался в простое. Я выбрал «обычный» способ резервного копирования / восстановления с журналами транзакций, включая последний хвост.
Я все еще думаю, что должен быть готовый способ сделать это без простоев.