Медленная репликация слиянием по глобальной сети - только загрузка

В течение нескольких лет мы использовали репликацию слиянием SQL Server для синхронизации данных между нашими центрами обработки данных, но сейчас мы страдаем от большой проблемы с производительностью. Это может быть потому, что объем данных, которые мы синхронизируем, значительно увеличился в этом году. Наш издатель - постоянно действующий дата-центр в Великобритании. Наш подписчик - это мобильный дата-центр, который путешествует по всему миру и работает в течение нескольких недель, ок. 25 раз в год. Тем не менее, он также тратит столько же времени (если не больше), выключенный во время своих путешествий - это хорошо проходимый дата-центр!

У нас есть 5 баз данных, которые мы синхронизируем на этих серверах. Однако одна из наших баз данных имеет большое количество изменений данных между периодами простоя абонента, и наша проблема заключается в том, что требуются дни, чтобы наверстать упущенное при включении сервера - с остальными базами данных все в порядке. Загрузка с издателя на подписчика выполняется со скоростью около 1,5 строк в секунду (что раздражает, когда у нас сотни тысяч строк), но, как ни странно, загрузка от подписчика к издателю выполняется примерно в десять раз быстрее.

Вещи, которые я проверял / пробовал: • у всех таблиц есть некластеризованные первичные ключи в столбцах guid, для которых установлено свойство rowguid • изменение порога выравнивания генерации не помогает • установка профиля агента на большой объем не помогает • запуск трассировка у издателя и подписчика показывает, что все запросы выполняются очень быстро (обычно менее 20 м / с, но между некоторыми пакетами запросов существует промежуток в 200 м / с) • анализ по нашей ссылке в глобальной сети показывает, что у нас огромный • избыточный запас пропускной способности • анализ наших серверов показывает, что у нас огромные запасы оперативной памяти и ЦП

В некоторых местах, где находится абонент, действительно наблюдается высокая задержка, но это, похоже, не оказывает влияния - 300 м / с или 100 м / с, и мы по-прежнему получаем такую ​​же низкую производительность.

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

Любая помощь, которую вы можете предложить, будет с радостью принята!

1 ответ

Мы подошли к сути этого в конце.

Именно наше использование столбцов nvarchar(max) мешало репликации использовать пакеты. То, что раньше занимало 3 часа, теперь занимает 50 секунд, просто изменив тип данных.

Вот урок: "nvarchar(max) - убийца репликации"

Спасибо

Другие вопросы по тегам