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