Перемещение баз данных в новые центры обработки данных

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

Некоторые подробности: размер рабочей БД составляет около 90 ГБ, а с помощью Robocopy ее копирование на один из новых серверов заняло около 9 часов. Текущая производственная база данных должна оставаться в сети и доступной на протяжении всего процесса миграции. Это простое восстановление, поэтому зеркальное отображение базы данных недоступно.

Является ли репликация транзакций лучшим способом для синхронизации баз данных?

Мой план:

1. (Готово) Перенесите текущую базу данных и войдите на новый сервер и присоедините его к новому экземпляру SQL Server.
2. Установите дистрибьютора на нашей машине базы данных разработки и опубликуйте его из производственной базы данных.
3. Создайте подписчика на новом компьютере базы данных, который будет принимать обновления, которые выталкиваются из распространителя, один раз каждую ночь.

У меня на уме две вещи. Для репликации транзакций требуется, чтобы у каждой опубликованной таблицы был первичный ключ, а во многих таблицах производственной базы данных не определены первичные ключи. Я не думаю, что это будет слишком большой проблемой, так как моя главная задача - просто синхронизировать базы данных. Мы протестируем различные приложения, которые используют базу данных на более поздних данных, но я хотел бы убедиться, что это не является серьезной проблемой. Во-вторых, нужно ли также перемещать любые связанные системные БД из исходного экземпляра, например master? Мы переходим к настройке Active Directory в новой среде, поэтому меня не волнуют пользователи и тому подобное, но я не уверен в необходимости системных БД.

И вообще, правильно ли я понимаю эти понятия?

Ваша текущая ситуация:

• 90 ГБ базы данных, которую вы хотите переместить в новый центр обработки данных.
• База данных находится в простом восстановлении.
• Вы думаете об использовании T-Rep для синхронизации данных.
• В базе данных есть много таблиц, которые не имеют первичного ключа - это требование для публикации любых таблиц.
• У вас уже есть резервная копия, скопированная в целевой дата-центр.

Я вижу много недостатков в вашем подходе:

• T-Rep не прост в настройке по сравнению с другими технологиями. Если есть какие-либо изменения схемы, тогда требуется новый снимок.
• Если вы собираетесь использовать T-REP, то вам нужно внести изменения в схему - добавьте первичный ключ в таблицы, которых нет.
• Внося какие-либо изменения в существующую базу данных, ваше приложение должно быть полностью протестировано, чтобы избежать непредвиденного поведения.
• Если ваша база данных имеет большое количество транзакций и в зависимости от пропускной способности сети между двумя центрами обработки данных, также будет задержка репликации.

Исходя из моего опыта, ниже моя рекомендация:

• Измените базу данных на полное восстановление. Это не главное влияние по сравнению с созданием ПК.
• Поставьте полную резервную копию исходной базы данных - сделайте резервную копию со сжатием и включите мгновенную инициализацию файла. Это поможет вам сократить время восстановления в дата-центре назначения.
• Восстановите базу данных на конечном сервере WITH NORECOVERY.
• Внедрите Logshipping и инициализируйте его из резервной копии.
• Отправляйте логи на корабле каждые 1 минуту.
• В течение дня отработки отказа возьмите последнюю резервную копию конечного журнала в источнике и восстановите ее в месте назначения, используя WITH RECOVERY. Это переведет базу данных назначения в онлайн.
• После того, как база данных получателя подключена к сети, вы должны синхронизировать пользователей .
• Вы должны изменить ваш web.config, чтобы он указывал на новый сервер.

Вам не нужно перемещать какие-либо системные базы данных. Убедитесь, что вы выполнили всю подготовительную работу перед тем, как вручную делать сценарии входа, заданий, пакетов ssis и т. Д. И создавать их на конечном сервере.

Обратитесь к этому ответу для шагов после восстановления и других передовых методов .

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

Текущая производственная база данных должна оставаться в сети и доступной на протяжении всего процесса миграции.

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

У меня не было возможности использовать это самому, и я думаю, что он все еще в предварительном просмотре, но возможен вариант синхронизации данных SQL на платформе Azure:

https://azure.microsoft.com/en-gb/documentation/articles/sql-database-get-started-sql-data-sync/

Он работает с локальными базами данных, а также с базами данных SQL Azure и кажется полезным инструментом для синхронизации баз данных.