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

Обновление данных на локальном сайте может вестись двояко: либо FAST REFRESH, либо COMPLETE REFRESH. В первом случае ИМХО ощутимый объем трафика занимают результаты опроса мастер-сайта на поиск изменившихся данных по логам. Во втором случае все цинично: TRUNCATE TABLE на локальном сайте и выполнение запроса мат. представления. Поэтому при больших интервалах между обновлениями может сложиться ситуация, когда FAST будет отрабатывать медленнее, даже при возможности его проведения.

У меня складывается примерно такое мнение: для большого потока данных лучше хорошая связь на небольшой период времени, необходимый для обмена информацией между мастер и локальными сайтами, чем постоянная, но так себе. А при недельном отсутствиии ничего рухнуть не должно, но может накопиться слишком много изменений, и тогда может быть будет выгоднее принудительно сделать COMPLETE REFRESH, нежели FAST, по вышеизложенным соображениям .