Установка merge-репликации: пошаговое руководство

В этой статье рассматриваются некоторые важные темы организации репликации Microsoft SQL Server: топология репликации, типы и агенты репликации. Также обсуждается Merge репликация: как создать необходимые условия для этого типа репликации и как резервировать и восстановить базы данных при таком сценарии репликации. Во время иллюстрации этой концепции, предлагается пошаговое руководство по установке процесса Merge репликации.

Поскольку это только демонстрационный пример, автор использовал только один сервер для репликации данных между publisher и subscriber, а также для размещения базы данных distributor, все они постоянно находились на одной и той же машине.

Репликация - это процесс, посредством которого данные копируются между базами данных, находящимися на том же самом сервере или на других серверах, связанных через LAN, WAN или Internet. Репликация Microsoft SQL Server использует метафоры: publisher, distributor и subscriber.

Publisher - сервер или база данных, которая посылает данные на другой сервер или в другую базу данных.

Subscriber - сервер или база данных, которая получает данные от другого сервера или другой базы данных.

Distributor - сервер, который управляет потоком данных через систему репликации. Этот сервер содержит специализированную базу данных: Distribution database.

Publisher содержит публикацию/публикации. Публикация - это совокупность одной или более статей, которые посылаются серверу подписчику (subscriber) или базе данных. Статья (Article) - основной модуль репликации и это может быть таблица или подмножество таблицы. Подписка (subscriptions) - это группа данных, которые сервер или база данных получает.

Существует push и pull subscriptions. Push subscription - это подписка, когда сервер издатель будет периодически помещать транзакции на подписавшиеся сервера или базы данных. Pull subscription - это подписка, когда подписавшийся сервер будет периодически соединяться с тиражируемой информацией и перемещать её из Distribution database.

Distribution database - это системная база данных, которая хранится на дистрибуторе (distributor) и не содержит никаких пользовательских таблиц. Эта база данных используется для хранения снимков заданий и всех транзакций, ожидающих распределения подписчикам.

 

Топология репликации

Microsoft SQL Server поддерживает следующие топологии репликации:
- Центральный publisher
- Центральный subscriber
- Центральный publisher с отдаленным distributor
- Центральный distributor
- Издающий subscriber

Центральный publisher

Это одна из наиболее используемых топологий репликации. В этом сценарии, один сервер исполняет роли publisher и distributor, а другой сервер/серверы определяется, как подписчик/подписчики.

Центральный subscriber

Это обычная топология складирования данных. Несколько серверов или баз данных копируют свои данные на центральный сервер в одну или более базы данных.

Центральный publisher с отдаленным distributor

В этой топологии база Distribution постоянно находится на сервере, отличном от сервера, где располагается publisher. Эта топология используется для повышения эффективности, когда объём репликации увеличивается, а также, если сервер или сетевые ресурсы ограничены. Это уменьшает загрузку publisher, но увеличивает сетевой трафик. Эта топология требует отдельных инсталляций Microsoft SQL Server для publisher и для distributor.

Центральный distributor

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

Издающий subscriber

Это топология двойственной роли. В ней, два сервера издают те же самые данные. Сервер издатель посылает данные на subscriber, и затем subscriber издает данные на любе число подписчиков. Это полезно когда publisher должен послать данные подписчикам по медленной или дорогой линии связи.

 

Типы репликации

Microsoft SQL Server 7.0/2000 поддерживает следующие виды репликации:
- Snapshot
- Transactional
- Merge

Snapshot репликация является самой простой. При этом, все копируемые данные (точная копия) будут копироваться из базы данных publisher в базу(ы) данных subscriber/subscribers на периодической основе. Snapshot репликация является лучшим методом копирования данных, которые нечасто изменяется и когда размер копируемых данных не очень большой.

При Transactional репликации, SQL Server фиксирует (делает моментальные снимки) все изменения, которые были сделаны в статье, и сохраняет, как: INSERT, UPDATE и DELETE инструкции в базе Distribution. Эти изменения посылаются подписчикам от Distribution и применяются к расположенным в них данным.. Transactional репликации лучше использовать, когда копируемые данные часто изменяются или когда размер копируемых данных достаточно велик и нет необходимости поддержать автономные изменения реплицируемых данных относительно publisher и относительно subscriber.

Merge репликация является наиболее трудным типом репликации. Она предоставляет возможность автономных изменений реплицируемых данных и на publisher и на subscriber. При Merge репликации, SQL Server фиксирует все накопившиеся изменения не только в источнике данных, но и целевых базах данных, и урегулирует конфликты согласно правилам, которые Вы предварительно конфигурируете, или посредством определённого Вами resolver-ра. Merge репликацию лучше использовать, когда Вы хотите обеспечить поддержку автономных изменений реплицируемых данных относительно publisher и относительно subscriber.

 

Агенты репликации

Microsoft SQL Server 7.0/2000 поддерживает следующих агентов репликации:
- Snapshot Agent
- Log Reader Agent
- Distribution Agent
- Merge Agent

Snapshot Agent - это агент репликации, который создаёт файлы снимков, хранит снимки на distributor и производит запись информации о состоянии синхронизации в Distribution database. Snapshot Agent используется во всех типах репликации (Snapshot, Transactional и Merge) и может управляться из SQL Server Enterprise Manager.

Log Reader Agent - это агент репликации, который перемещает транзакции, отмеченные для репликации из transaction log, находящегося на publisher, в Distribution database. Этот агент репликации не используется в Snapshot репликации.

Distribution Agent - это агент репликации, который перемещает обрабатывающие снимки задания из Distribution database к подписчикам и перемещает все транзакции, ожидающие распределения на подписчиков. Distribution Agent используется в Snapshot и Transactional репликациях и может управляться с помощью SQL Server Enterprise Manager.

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

 

Проверка необходимых условий

Проверьте соблюдение следующих необходимых условий для установки Merge репликации:

1. Учетная запись Localsystem не имеет никакого доступа к ресурсам сети. Поэтому, если Вы хотите установить репликацию, Вы должны изменить учетную запись, от имени которой стартуют: сервисы MSSQLServer и SQLServerAgent, на учетную запись домена Windows NT/Windows 2000. Для этих операционных систем, Вы можете создавать учётную запись Windows NT/Windows 2000 и включить её локальную группу Administrators, в группы пользователей домена (Domain Users) и предоставить набор разрешение для "Log in as a service". Windows 9x не поддерживает сервисы Windows NT, поэтому Вы не сможете создать подобную учетную запись.
2. Только члены роли сервера sysadmin могут устанавливать и конфигурировать репликацию, так если Вы не имеете эти права, Вы не можете устанавливать репликацию.
3. Не забывайте запускать сервис SQLServerAgent (и, конечно, службу MSSQLServer).
4. Вы должны выделить адекватное дисковое пространство для Distribution database.
5. Вы должны выделить адекватное дисковое пространство для баз данных подписчиков и publisher. SQL Server 7.0/2000 использует столбец uniqueidentifier для идентификации каждой строки в течение Merge репликации, причём, если ваша таблица не имеет столбца uniqueidentifier со свойством ROWGUIDCOL, Microsoft SQL Server 7.0/2000 сам добавит этот столбец к таблице. Поэтому, Вы должны выделить дополнительное дисковое пространство, необходимое для хранения ваших данных.
6. Вы не можете копировать в одиночку таблицу с foreign key constraints; Вы должны включить в публикацию все связанные таблицы.
7. Вы должны обеспечить, что бы сервер, который реплицируется, был определен как удалённый сервер.

 

Пошаговый пример настройки merge-репликации

В этом примере, я буду использовать только один сервер, который будет участвовать в репликации данных, как publisher, subscriber и обслуживать базу данных distributor. Я буду использовать Merge репликацию с push подпиской. Чтобы устанавливать Merge репликацию, Вы можете использовать GUI интерфейс SQL Server Enterprise Manager. Кроме того, имея права администратора можно выполнять системные хранимые процедуры SQL Server. Но поскольку первый путь проще и более понятен, я буду использовать именно его.

 

Шаг 1

Прежде всего, Вы должны зарегистрировать новый удаленный сервер, который нужно реплицировать. Поскольку я использую в репликации только один сервер, я не должен этого делать.

На этом шаге, с помощью Enterprise Manager, Вы должны определить новый Remote server, открыв папку Security вашей базы данных. В этом примере, я буду реплицировать данные из базы данных pubs в базу данных pubs _copy.

Для этого, вторым шагом, выберете пункт меню Enterprise Manager "Tools", а в нём пункт "Replication" и далее "Configure Publishing, Subscribers, and Distribution...". Вы попадёте в окно - приглашение Publishing and Distribution Wizard. Щёлкнув кнопку "Next", вы попадёте в следующее окно, назначение которого в определении дистрибутора (distributor). В нашем случае мы оставляем предлагаемую по умолчанию установку, поскольку сервер только один.

В следующем окне, Вы можете настроить запуск сервиса SQLServerAgent автоматически, при включении или перезагрузке компьютера, отметив галочкой пункт: "Yes, configure the SQL Server Agent service to start automatically".

После нажатия кнопки "Next", появится следующее окно (Specify snapshot folder), в котором Вы должны определить папку для снимков, используя полностью квалифицированный сетевой путь. При этом, сервер может запросить у Вас подтверждения осознанности этой операции.

Далее, нажав в очередной раз кнопку "Next", Вы можете приступить к настройке публикации и параметров дистрибутора, или выбрать эти параметры по умолчанию (окно: Customize the Configuration). Для параметров по умолчанию нужно выбрать ответ: "No, use the following default settings".

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

После нажатия кнопки "Finish", появится окно статистики исполнения шагов применения Ваших настроек и закончится этот процесс должен выводом на экран окна успешности определения Вашего сервера, как дистрибутора. вашей базы данных. Microsoft SQL Server создаал Distribution database, определил публикацию и установил distributor-а. После нажатия кнопки "OK", появится сообщение о том, что в дерево объектов Вашего сервера (в Enterprise Manager) был добавлен монитор репликации. После этого можно нажать кнопку "Close".

Шаг 2

Теперь мы готовы начать создание публикаций и статей.

Для этого, выбираем в горизонтальном меню Enterprise Manager пункт "Tools", в нём пункт "Replication", а затем "Create and Manage Publications" Вы увидите диалоговое окно Manage publications, где нужно выбрать базу данных pubs, и щелкнуть кнопку "Create Publication". Вы попадёте в окно - приглашение "Create Publication wizard", после нажатия кнопки "Next" в котором, Вам будет предложено выбрать публикуемую базу данных.

Замечание автора перевода: если Вы в качестве дистрибутора выбрали SQL Server 7.0, а реплицировать собираетесь SQL Server 2000, у Вас появится не это окно, а окно, предлагающее выбрать другой сервер для дистрибутора, т.к. такой вариант репликации не поддерживается.. Далее процесс настройки дистрибутора будет схож с описанным выше.

Выберите базу данных pubs, и после нажатия кнопки "Next", выбираете Merge publication, опять же нажав после этого кнопку "Next" в окне "Select Publication Type". В следующем окне (Select Subscribers Types), выделите всё из имеющихся там типы подписчиков, от которых ожидается оформление подписки на эту публикацию (publication) и опять щёлкните кнопкой "Next". В окне "Specify Articles" поставьте галочку в чекбоксе "Publish All", что приведёт к изданию всех таблиц базы данных pubs и щёлкните кнопкой "Next".

В окне "Article Issues", лучше согласится с предлагаемым по умолчанию вариантом добавления столбца uniqueidentifier во всех таблицах базы данных "pubs", а не второй вариант, устанавливающий опцию NOT FOR REPLICATION на столбец IDENTITY содержащих его таблиц. Для этого достаточно, не внося изменений, сразу нажать кнопку "Next". В следующем окне присвойте имя "pubs_article" для вновь созданной публикации и нажмите "Next". В следующем окне "Customize the Properties of the Publication", Вы можете определить фильтры для данных, но в этом примере, мы не будем использовать никаких фильтров. Для нас сгодится вариант "No, create the publication as specified", после выбора которого можно нажать "Next" и "Finish" в следующем окне, чтобы завершить процедуру создания публикации. Вам на экран должно быть выведено сообщение о том, что публикация "pubs_article" была успешно создана, после чего можно нажать "Close".

Шаг 3

Теперь Вы можете создавать подписку. Щелкните кнопку "Push New Subscription" в окне "Create and Manage Publications", которое появилось на экране после завершения создания публикации. Будет запущен "Push Subscription Wizard", в следующем окне которого (Coose Subscribers) нужно щёлкнуть по "SQL Server Group" выделить всех подписчиков в имеющихся у меня группах CHIGRIK и CHIGRIK\SQL2000, после чего - "Next".

Далее, выберите в окне "Coose Destination Database) базу данных "pubs_copy", в качестве подписываемой базы данных, и щелкните кнопку Next. В следующем окне "Set Merge Agent Shedule",определите, как часто Distribution Agent будет обновлять подписку (в моём примере, каждый день, каждые 30 минут между 9:00:00 и 18:00:00) и нажмите "Next". Задайте "Start the Merge Agent to initialize the subscription immediately" в следующем окне "Initialize Subscription" и "Next". Теперь Вы можете установить приоритет подписки, который определяет победителя при разрешении противоречивых изменений данных. В нашем примере, мы выберем "Use the Publisher as a proxy for the Subscriber when resolving conflicts" и нажмём таки "Next".

Для запуска SQLServerAgent, щелкните "Next" в следующем окне "Start Required Services", что необходимо для последующих операций. После этого, Вы попадёте в окно завершения работы мастера "Push Subscription Wizard", где также можно подтвердить завершение подписки с параметрами, которые Вы определили в предыдущих шагах, нажатием кнопки "Finish". Появится окно отчёта об исполнении вашей конфигурации, по завершении которых можно нажать кнопку "Close". Далее, можно закрыть окно "Create and Manage Publications…", щёлкнув по "Close".

Шаг 4

Последний шаг, который рекомендуется сделать при установке Merge репликации, предполагает создание сценария конфигурации Ваших текущих параметров репликации. Это может быть полезно при восстановлении этих параметров в случае отказа сервера. Для этого нужно выбрать в пункте "Tools", пункт из выпадающего меню "Replication", а в его окошке пункт "Generate SQL Script...".

 

Стратегии резервирования и восстановления

Резервное копирование и восстановление отличаются для каждого из типов репликации. Здесь, я хочу описать стратегии резервирования и восстановления для Merge репликации. Поскольку Merge репликации более сложная, чем Snapshot или Transactional репликации, и обычно используется, когда Вы хотите обновить данные относительно и publisher и подписчиков, Вам придётся потратить большее времени и внимания на планирование стратегий резервирования и восстановления. Есть четыре главных стратегии поддержки и восстановления Merge репликации:

- Резервирование publisher, master и model. баз данных.
- Резервирование publisher, distributor, master и model баз данных.
- Резервирование publisher, subscriber, master и model баз данных.
- Резервирование publisher, distributor, subscriber, master и model баз данных.

Резервирование publisher, master и model. баз данных - это самая простая стратегия. Эта стратегия имеет как преимущества, так и недостатки. Преимуществом является то, что задействуется наименьшее количество ресурсов памяти и не требуется координации резервной копии с резервными копиями других серверов. Главный недостаток этой стратегии - это то, что придётся заново устанавливать репликацию в случае отказа distributor или publisher. В этой стратегии, Вы должны резервировать базу данных publication после её изменений, после добавления новой публикации, или всякий раз, когда сделаны изменения в копируемой схеме объектов (например, добавлен или удалён столбец).

Резервирование publisher, distributor, master и model баз данных. - эта стратегия используется реже, чем предыдущая, потому что в большинстве случаев, нет необходимости восстановить Distribution database, при восстановлении из резервной копии базы данных publication. Это обусловлено тем, что Distribution database не хранит никаких данных, используемых при отслеживании изменений, и не подразумевает временное хранение данных. Главный недостаток этой стратегии - это то, что Вы должны резервировать базы данных publisher и distributor практически одновременно. Это может отвлекать значительные вычислительные ресурсы и память, даже больше, чем первая стратегия.

Резервирование publisher, subscriber, master и model баз данных. используются, когда некоторые изменения могут быть сделаны на subscriber, и Вам нужно, что бы эти изменения были синхронизированы с базой данных publication.

Резервирование publisher, distributor, subscriber, master и model баз данных - это наиболее сложная стратегия. Главное преимущество этой стратегии в том, что в случае отказа publisher, distributor или subscriber, Вы можете быстро восстановить базу данных без того, чтобы переустанавливать репликацию с самого начала. Недостаток этой стратегии в том, что Вы должны резервировать базы данных publisher и distributor максимально одновременно. Эта стратегия также требует наиболее значительного отвлечения вычислительных ресурсов и памяти.

Для каждой из стратегий Вы должны резервировать базы данных msdb и master на publisher, distributor и subscriber. База данных msdb используется SQL Server Agent для планирования сообщений и заданий, а база данных master - главная системная база данных, содержащая записи для каждого subscriber, для каждой учетной записи и для системных параметров и настроек конфигурации и так далее.

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