Репликация SQL Server, распространитель - PullRequest
Новая
       4

Репликация SQL Server, распространитель

1 голос
/ 05 декабря 2009

Мне нужно реализовать решение для репликации SQL Server. Очень просто нужно сейчас. Мне просто нужно скопировать одну довольно простую таблицу с 200 удаленных сайтов или около того на один центральный сервер. Данные на самом деле не являются транзакционными. Мне просто нужно перенести его на центральный сервер один раз в день. Я не могу решить, должен ли я использовать push или pull, и я не уверен, должен ли распространитель жить на стороне сервера или на всех клиентах.

Сервер и все удаленные сайты живут в довольно приличном VPN. Сервер 2005 года, и в данный момент он не слишком сильно загружен. Несколько мест здесь и там собирают данные (от которых я хочу избавиться) и отправляем отчеты / экспорты разным поставщикам раз в день. Сайты представляют собой смесь 2000/2005 гг.

Ответы [ 3 ]

2 голосов
/ 05 декабря 2009

Я бы порекомендовал вам сначала сделать несколько тестов на масштабируемость. Репликация очень многословна с точки зрения заданий агента и соединений T-SQL для чтения и записи данных. 200 публикаций, о которых вы говорите, 200 агентов издателей, 200 агентов подписки, а также обслуживание дистрибьюторов. Большинство сайтов жалуются на проблемы обслуживания, связанные с наличием 1 издателя и 1 подписчика ... Скажем, вам удастся осуществить это и успешно обработать , что станет вашей историей обновления? И как вы собираетесь реализовать изменение схемы?

Самое большое развертывание репликации, о котором я слышал (несколько лет назад), было, по моему мнению, 450 издателей, и было внедрено армией консультантов Microsoft, потевших месяцами, чтобы изогнуть чудовище. Ваш проект 200 сайтов репликации является способом более амбициозным, чем вы думаете.

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

1 голос
/ 05 декабря 2009

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

0 голосов
/ 05 декабря 2009

Push-подписки - это то, что нужно, если вы хотите централизованно управлять распределением данных вашей прикладной платформы.

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

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

Что нужно учитывать:

  • Сколько данных должно быть перемещено через сеть? Размер в Кб и запись объем.
  • Рассмотрим физическое местонахождение ваши сайты
  • Какова пригодность вашего сеть? Семя, емкость и т. Д.
  • Вы можете рассмотреть возможность использования Выделенный дистрибьютор.
...