MS-SQL Server 2005:Инициализация подписки на слияние с альтернативным расположением моментального снимка

Question

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

1. создайте копию исходной базы данных, заморозьте ее, отправьте файлы самолетом подписчику и запустите репликацию без моментального снимка:это то, что было традиционно сделано со старыми версиями SQL, но для меня это звучит немного сумбурно:Мне пришлось бы перевести данные моего издателя в режим только для чтения и остановить все репликации до тех пор, пока операция не будет завершена.
2. создайте моментальный снимок данных, отправьте файлы моментальных снимков за границу, установите их на подписчике и укажите новое местоположение моментального снимка в качестве альтернативного местоположения в свойствах репликации.Это звучит справедливо для меня (нет необходимости приостанавливать текущие репликации, данные не замораживаются), но по этому пункту справка Microsoft этого не делает ...Справка.

Я уверен, что некоторые из вас уже сталкивались с подобной ситуацией.Каков был ваш выбор?

Редактировать:конечно, можно было бы сказать "Почему бы вам просто не попробовать свои идеи", но это займет часы (несколько экземпляров sql-серверов, виртуальных машин и все такое прочее ...), и я подумал, что парню, который это сделал, понадобится всего 2 минуты, чтобы объяснить свою идею.И я был бы самым счастливым человеком , если бы кто - то согласился потратить 2 минуты своего времени , чтобы избавить меня от часов напряженной работы ...

Answer 1

Мне пришлось сделать нечто подобное при репликации данных из Лос-Анджелеса, Калифорния, в Китай.Загрузка snap обычными методами заняла бы 44 дня.

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

Затем я запустил distrib.exe из командной строки на сервере в Китае.Это загрузило данные в таблицу в Китае.Как только snap был загружен, я выключил дистрибьютора на сервере в Китае и запустил обычного дистрибьютора на сервере в Калифорнии.

Этот метод занял всего около 28 часов вместо более чем месяца.

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

Answer 2

Мы только что прошли через нечто подобное, и это некрасиво.Несмотря на то, что все задействованные серверы были локальными, это все равно заняло много времени.

Просто чтобы усложнить задачу, по крайней мере, с SQL 2000, моментальный снимок завершится неудачно, если сжатый cab превысит 4 гигабайта.

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