У нас есть пара баз данных SQL Server 2005, которые мы скоро переместим на новый производственный сервер. Эти базы данных не очень большие, но достаточно большие, чтобы сделать это с минимальным временем простоя.
Три базы данных, которые будут перемещены в первую очередь, поскольку они наиболее критичны, имеют размер 5, 9 и 25 ГБ (только данные без журналов).
Теперь есть несколько возможностей, но поскольку я не полноценный DBA, я подумал, что, возможно, у кого-то здесь есть лучшие идеи/предложения. Вот что мы придумали;
* Create a full backup, move the file and restore the backup.
Это возможно, но поскольку базы данных довольно большие, это будет означать довольно серьезный (пару часов) простой системы, поскольку базы данных необходимо будет перенести.
Можно ли создать и восстановить резервную копию сегодня, а затем выполнить дифференциальное восстановление, когда мы фактически переедем? Проблема, которую я обнаружил на данный момент с дифференциальным восстановлением, заключается в том, что они всегда добавляются к ПОЛНОЙ резервной копии, что оставит файлы того же размера и не сократит время простоя из-за перемещения файлов с сервера на сервер.
Чтобы сделать это "более" сложным, новая база данных будет настроена на зеркалирование, где старая среда не зеркалируется. Это значит, что мне придется восстановить дифференциальную резервную копию на основном сервере (я не думаю, что это должно вызвать проблемы, но я подумал, что спрошу.)
Если есть другой, более простой или лучший способ сделать это с минимальным временем простоя, я, конечно, тоже был бы рад его услышать.
Пользователь StackOverflow ответил просто: «Вы можете использовать зеркалирование, чтобы сделать это». Не вдаваясь в подробности, я вижу это так: я могу создать зеркало по новому принципу, а затем заставить зеркало взять на себя управление со старого производственного сервера. Затем я отключаю зеркалирование и снова включаю его на новом сервере-зеркале.
Будет ли это работать таким образом?
решение1
Я проделывал этот тип миграции несколько раз, и лучшим способом (для меня) является:
полная резервная копия (с используемой базой данных)
Резервное копирование журналов транзакций каждые n минут (n зависит от времени копирования полной резервной копии)
скопируйте полную резервную копию на новый сервер, а затем восстановите базу данных без восстановления (
RESTORE....NORECOVERY)копировать и восстанавливать (всегда без восстановления) журналы транзакций
Когда новая база данных почти будет готова к работе, остановите приложения, использующие старую базу данных, сделайте резервную копию последних журналов транзакций, скопируйте ее на новый сервер и восстановите с помощью функции восстановления.
теперь у вас есть база данных на новом сервере с очень небольшим временем простоя.
решение2
Что касается резервного копирования и перемещения баз данных, я регулярно делаю резервную копию базы данных размером 30 ГБ менее чем за полчаса. Если вы делаете резервную копию на внешнем USB-накопителе, подключенном к текущему серверу, и переносите их через USB-накопитель на новый сервер и восстанавливаете их, я не думаю, что это займет больше часа, плюс-минус несколько минут.
решение3
Я попытаюсь высказать свое мнение.
Возможно, я не прав, пусть другие скажут, если это не обычный способ. Можете ли вы настроить транзакционную репликацию на НОВЫЙ сервер и опубликовать и подписать базы данных, так что обе базы данных будут работать постоянно с задержкой менее нескольких секунд.
После этого вы закрываете соединение со старой базой данных от клиентов и ждете несколько секунд.
Отключите репликацию и начните использовать новую базу данных