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

Question

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

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

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

РЕДАКТИРОВАТЬ: конечно, можно сказать «Почему бы вам просто не попробовать свои идеи», но это займет несколько часов (несколько экземпляров sql-серверов, виртуальных машин и всего такого ...) и я думал, что парню, который сделал это, понадобится всего 2 минуты, чтобы объяснить свою идею. И я был бы самым счастливым человеком, если бы кто-то согласился потерять 2 минуты своего времени, чтобы сэкономить мне часы тяжелой работы ...

Answer 1

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

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

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

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

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

Answer 2

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

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

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