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

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

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

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

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


snapshot sql-server replication synchronization
person Philippe Grondier    schedule 24.09.2008    source источник

Ответы (2)


arrow_upward
1
arrow_downward

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

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

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

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

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

person mrdenny    schedule 06.01.2009

arrow_upward
1
arrow_downward

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

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

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

person user21884    schedule 24.09.2008