Просто вопрос по репликации

Привет

Есть задумка - поставить еще один сервер на нотбук и включить его в репликацию. НО! Этот Нотбук - по понятным причинам периодически будет не доступен. Подскажите - как себя будет вести репликация? Не отвалится ли она? Будет ли она выполняться между другими участниками репликации? Или если один подписчик - отвалился (/недоступен), то и вся репликация накроется?

==========
Спасибо.

Замучаешься переиничивать этого подписчика.
Остальным будет достаточно фиолетово.

Замучаешься переиничивать этого подписчика.

А можно поподробнее? Что нужно будет делать? Если есть ссылка на статью - буду признателен. Спасибо.

===============================
КУ

		автор писал:
		как себя будет вести репликация? Не отвалится ли она?

Не отвалится. Ей до лампочки.

		автор писал:
		Будет ли она выполняться между другими участниками репликации?

Зависит от того что у Вас на NB:

Подписчик: Будет. Подписчики друг про друга не знают

Издатель: Данные на дистрибутор передадутся при соединении с ним (+ агент и пр.)

Дистрибутор: Понятно, что он буджет доступен только в момент работы NB в сети.

Вряд ли у Вас дистрибутор на NB. Но если так, обратите внимание на его настройки.

Однажды столкнулся с такой ситуацией (страшилка - for Glory :) ).
Представьте звезду: Около 200 SQL2k (1 - L0, 17 - L1 и > 100 уровня L2)

L2 -- L1 -- L2 | L2 -- L1 -- L0 -- L1 -- L2 | | L2 L1 -- L2

Каждый Ln - и издатель, и дистрибутор, и подписчик
Потоки данных бегают между всеми уровнями.
Была настройка дистрибуторов по умолчанию (сами дураки, но кто же знал).
При длительном падении канала L0 - L1 данные c его уровней L2 копились в distib но не уходили на L0, диск переполнился (ставьте ограничения объема на distrib, длительность хранения транзакций и периодичность обновлений)? тачка встала. После включения канала пошла цепная реакция. Правда мы были на готове и быстро все привели в порядок.

2 Gator

У меня щас простая звезда: Один издатель (он же дистрибьютер) и несколько подписчиков. Репликация мерже (push). Вот хочу еще Нотбук сделать подписчиком. Но он будет примерно раз в день в сеть втыкаться. Я так понимаю, что это возможно.

===============================
Q^per (рус. Купер)

Все будет нормально. Это вполне штатное решение.

2 GreenSunrise

Ясно. Спасибо.
Вот еще есть вопрос. Может поможешь?
Интересует - как агент Мерже узнает, какие записи были изменены с момента последней репликации, чтобы передать на дистрибьютера? И ещё - как узнать - когда было последняя удачная синхронизация с конкретным подписчиком. (sp_help_jobhistory - выдает только дату последней репликации)

Т.е. к примеру - если нужно на клиенте показывать - какие записи были изменены с момента последней синхронизации с издателем. Это возможно?

Спасибо.
===============================
Q^per (рус. Купер)

как агент Мерже узнает, какие записи были изменены с момента последней репликации, чтобы передать на дистрибьютера?
BOL->Contents->Replication->Types of Replication->Merge Replication->How Merge Replication Works

Там достаточно просто расписано, какие триггера и хранимые процедуры создаются при настройке репликации, что такое "поколение" и многое другое.

как узнать - когда было последняя удачная синхронизация с конкретным подписчиком.
Запускать sp_help_jobhistory с правильными параметрами, например, указывая @run_status = 1 для удачно завершившегося сеанса синхронизации.

если нужно на клиенте показывать - какие записи были изменены с момента последней синхронизации с издателем
Читай пункт первый, обращая внимание на системные таблицы MSmerge_genhistory и MSmerge_replinfo.

Также поинтересуйтесь информацией, касающейся разрешения возникающих конфликтов:
BOL->Contents->Replication->Types of Replication->Merge Replication->Merge Replication Conflict Detection and Resolution.
Там написано, что считается конфликтом, какого рода конфликты бывают при репликации, каким образом их можно разрешать, какие таблицы используются для этого и др.

2 GreenSunrise

Ясно. Прочитал.

The generation column in these tables acts as a logical clock indicating when a row was last updated at a given site. Actual datetime values are not used for marking when changes occur, or deciding conflicts, and there is no dependence on synchronized clocks between sites.

Вот выяснил, что конкретное значение времени последнего изменения записи -не хранится, а хранится целое число. Понятно для чего. А можно ли по этому числу (в столбце generation ) - узнать дату и время?

===============================
Q^per (рус. Купер)

2 GreenSunrise

Ясно. Прочитал.

The generation column in these tables acts as a logical clock indicating when a row was last updated at a given site. Actual datetime values are not used for marking when changes occur, or deciding conflicts, and there is no dependence on synchronized clocks between sites.

Вот выяснил, что конкретное значение времени последнего изменения записи -
не хранится, а хранится целое число. Понятно для чего. А можно ли по этому
числу (в столбце generation ) - узнать дату и время?

===============================
Q^per (рус. Купер)