могучая репликация

ФЛЕНОВ МИХАИЛ

Спецвыпуск: Хакер, номер #068, стр. 068-036-3

После этого нам предложат сконфигурировать самого агента вручную или автоматически. Если выбрать ручной режим, то количество шагов мастера резко возрастает, но они просты, и с минимальными знаниями английского ты в них разберешься. Если выбрать автомат, то остается только указать мастеру требуемый тип репликации – снимок (Snapshot publication), транзакции (Transaction publication) или смешение (Merge publication) - и указать необходимые таблицы. Да, в репликации участвует не вся база, а указанные таблицы. Системные таблицы реплицировать незачем.

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

Если ты настроил репликацию и решил перенести базу данных на другой сервер, то можешь забыть про перенос через резервное копирование и восстановление. Дело в том, что в резервную копию не попадает информация о репликации :(. Тут приходится отключать базу Detach, копировать файлы на другой компьютер и подключать их заново Attach.

[золотой ключик.]

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

Допустим, что на двух компьютерах были созданы две разные записи с одинаковыми идентификаторами. Что делать серверу? Какую из записей выбирать? По идее, в результирующую таблицу должно попасть обе записи, но изменять ID нельзя, особенно если таблица связанная, а две записи с одинаковым ключом невозможны.

Проблема решается достаточно просто, нужно только выполнить следующие шаги:

1 Создаем копию базы данных издателя на компьютере подписчика.

2 Открываем окно редактирования таблицы или с помощью SQL запроса устанавливаем на издателе для ключа начальное значение 1, а для подписчика 1 000000.

Все просто и красиво. Теперь при добавлении записи на издателе новые записи будут нумероваться 1, 2, 3, 4..., а на подписчике 1000001, 1000002, 1000003... Таким образом, записи пересекутся не скоро и конфликты могут никогда не появиться, особенно если записи добавляются в таблицу не слишком интенсивно. Если же они добавляются интенсивно, то откажемся от автоувеличения и используем GUID поля в качестве ключа.

Но и это еще не все. При создании подписчика нам предложат перенести всю схему с издателя. Это удобно, если структура таблиц разная и их необходимо синхронизировать, но в нашем случае неприемлемо. Если ты поведешься на это предложение и ответишь Yes, то схема издателя будет скопирована подписчику и у обоих начальное значение ключа станет единицей, и все наши старания пойдут прахом, т.е. затрутся. Чтобы этого не произошло, жми No и наслаждайся. Главное, чтобы на подписчике структура таблиц была такой же, как и у издателя.