Установка 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,
для кожного облікового запису і для системних параметрів і настройок конфігурації і так далі.
Примітка: Настійно рекомендую Вам зберігати поточні сценарії налаштування реплікації. Це
може бути корисно при відновленні реплікації в разі відмови сервера.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*