Реплікація транзакцій

Реплікація знімків бази даних відправляє передплатникам повний набір даних (або його частина, якщо використана фільтрація стовпців і рядків) при кожній генерації знімка Цей тип реплікації забезпечує синхронізацію на певний момент часу Після генерування знімка і його поширення передплатникам у останніх починається поступове неузгодженість даних з видавцем Ця синхронізація відновлюється тільки після наступної реплікації Проміжок часу, який передплатник залишається рассогласовани з видавцем, називається затримкою Затримка в реплікації знімків бази даних досить велика

для виконання синхронізації бази даних з передплатниками використовує журнал транзакцій Вона більш масштабируема, ніж реплікація знімків бази даних, так як реплицируются тільки зміни Затримки цієї реплікації менше, ніж у реплікації знімків бази даних, оскільки зміни постійно застосовуються до передплатників

використовує три компоненти:

■ агент знімків бази даних генерує схему, дані і необхідні реплікації метаданих для відстеження процесу реплікації

■ агент розподілу поширює знімок і наступні команди

■ агент читання журналу читає журнал транзакцій бази даних видавця

Агент знімків

Агент знімків (Snapshot Agent) використовують всі три типи транзакцій Він генерує схему репліцируємих обєктів та повязаних з ними даних, а також необхідні метадані відстеження, які потім поміщає у вигляді текстових і двійкових файлів в задану папку знімків Після цього він записує дані відстеження в базу даних розповсюдження, яку згодом читає агент поширення для синхронізації передплатників з видавцем

Агент читання журналу

Агент читання журналу (Log Reader Agent) шукає транзакції, які повинні бути реплікуються передплатникам Ідентифікатори цих транзакцій він записує в таблицю бази даних поширення, що має назву msrepl_transactions При цьому всі транзакції розбиваються на окремі команди – по одній команді для кожної задіяної рядка

Розглянемо транзакцію, обновляющую 100 рядків на стороні видавця (це може бути інструкція видалення, оновлення або вставки) У журналі вона буде зареєстрована як єдина транзакція Після цього агент читає цю транзакцію і створює для неї запис у таблиці msrepl_transactions бази даних розповсюдження Потім він розбиває дану транзакцію на одиночні команди, які записує в таблицю msrepl_commands бази розповсюдження (про причини такої послідовності дій ви дізнаєтеся в наступному розділі) Якщо інструкція досить велика, вона може бути записана в кілька рядків бази даних розповсюдження Всі команди зберігаються в двійковому форматі, але їх можна прочитати за допомогою збереженої процедури sp_browsereplcmds, яку можна знайти в базі розповсюдження За замовчуванням команди, які реплікація транзакцій використовує для синхронізації передплатника з видавцем, оформляються у вигляді збережених процедур Крім того, у вас є можливість зберігати команди у вигляді окремих інструкцій SQL DML (INSERT, UPDATE і DELETE), що вкрай необхідно в гетерогенному середовищі реплікації

Одиночної називається інструкція, яка надає вплив на одну

■ На замітку рядок

Коли агент читання записав інформацію в бази даних поширення, він поміщає в журнал транзакцій маркери, що вказують на реєстрацію даних транзакцій для розповсюдження Зазначені цими маркерами фрагменти журналу транзакцій можуть бути перерозподілені, якщо ви зарезервіруете журнал при повній моделі відновлення або будете використовувати просту модель відновлення Зауважимо, що реплікація транзакцій працює з будь-якою моделлю відновлення

Агент поширення

Цей агент (Distribution Agent) поширює команди з бази даних розповсюдження серед передплатників Також він видаляє з цієї бази даних ті команди, які були поширені всім передплатникам і термін зберігання яких вийшов за межі величини, встановленої в базі

Процес реплікації транзакцій розбиває транзакції на одиночні команди, тому завжди можна підрахувати, скільки рядків було оновлено у передплатника в результаті поширення операцій агентом Якщо одиночна команда не мала впливу ні на один рядок або вплинула на кілька рядків (тобто більше однієї), то процес реплікації завершується і агент поширення повідомляється про наявність проблеми цілісності даних Цей процес верифікації забезпечує цілісний стан баз даних видавця і передплатника Іншими словами, передплатник буде завжди мати ті ж дані, що і видавець Агент поширення застосовує всі поодинокі команди (формують вихідну транзакцію) в контексті транзакції Якщо хоча б одна з них завершується невдачею, то всі одиночні команди, складові транзакцію, відкочуються Це гарантує те, що реплікація транзакцій завжди буде виконуватися на рівні цілісних транзакцій

Однорангова реплікація

Цей тип реплікації був введений у версії SQL Server 2005 і є однією з варіацій реплікації транзакцій Всі вузли, що беруть участь в топології одноранговой реплікації, одночасно є передплатниками та видавцями один одного Транзакція, виконана на одному вузлі, буде реплицирована на всі інші, крім самого видавця Ця модель, як правило, використовується в додатках, що використовують для масштабування безліч баз даних і серверів Клієнти можуть підключатися до будь-якої з безлічі баз даних і гарантовано працювати з однією і тією ж інформацією Якщо із загального банку буде виведено один із серверів (або база даних), його навантаження буде рівномірно розподілена між рештою серверами (або базами), які беруть участь в топології одноранговой реплікації Всі вузли одноранговой реплікації містять ідентичні копії даних

Однорангова реплікація вирішує задачу, в якій безліч розподілений-Новинка нь, х сеРвеРов повинно залишатися постійно оновленим

2005

Двостороння реплікація транзакцій

Двосторонню реплікацію транзакцій найкраще використовувати, коли існує можливість поділу обєктів, що беруть участь у вирішенні, для мінімізації конфліктів або коли одна зі сторін реплікації доступна для запису в будь-який момент часу У двосторонньої реплікації беруть участь тільки два вузли: один видавець і один передплатник

з безпосереднім оновленням

з безпосереднім оновленням аналогічна реплікації знімків бази даних з безпосереднім оновленням Проте в даному випадку тільки зміни, що відбулися на стороні видавця, реплицируются у передплатника У цьому процесі бере участь виключно агент розповсюдження Зміни, що відбуваються на стороні передплатника, реплицируются видавцеві за допомогою координатора розподілених транзакцій (DTC) Якщо ви вибрали цей варіант реплікації, то повинні забезпечити надійний звязок між видавцем і передплатником Якщо звязок обривається або видавець стає недоступним з інших причин, транзакції, виконані у передплатника, виждут близько 20 секунд, після чого буде виконано їх відкат

з чергою оновлень

з чергою оновлень аналогічна реплікації знімків бази даних з чергою оновлень Проте в даному випадку тільки зміни, що відбулися на стороні видавця, реплицируются у передплатника У цьому процесі бере участь виключно агент розповсюдження Всі зміни, що відбуваються на стороні передплатника, реплицируются у видавця за допомогою агента читання черги Цей тип реплікації найкраще себе проявляє при виконанні наступних умов

■ Кількість змін, виконуваних на стороні передплатника, становить малу частку всього безлічі змін

■ Кількість передплатників не перевищує десяти

Якщо хоча б одна з цих умов не задовольняється, дана модель реплікації не може бути названа оптимальною, оскільки в процесі роботи агента читання черзі будуть виникати часті взаимоблокировки

з безпосереднім оновленням і чергою відновлення

з безпосереднім оновленням виявляється корисною при виконанні наступних умов

■ Переважна маса транзакцій відбувається у видавця

■ Деякі транзакції породжуються у передплатника, і виникає потреба в їх реплікації видавцеві

■ Число передплатників невелика

■ Необхідно мати можливість переведення видавця в автономний режим

У цьому випадку краще використовувати безпосереднє оновлення з постановкою в чергу відмов При використанні такої схеми можна вручну перемикатися між негайним оновленням і використанням черги оновлень, викликаючи збережену процедуру sp_setreplfailovermode У разі перемикання в режим використання черзі використовується параметр queued, при зворотному перемиканні-immediate Режим негайного поновлення знову включається, коли видавець стає доступним в режимі реального часу

через Інтернет

Компанія Microsoft рекомендує при виконанні реплікацій через Інтернет використовувати віртуальну приватну мережу, захищаючи тим самим своє підключення Якщо цього не зробити, швидше за все, вам доведеться використовувати підписку за запитом з анонімними передплатниками і завантажувати знімок бази даних на сервер FTP У цьому випадку завжди існує ймовірність того, що хакери отримають доступ до знімка бази і, можливо, навіть порушать роботу сервера

Віртуальні приватні мережі (VPN) є важливою підмогою в бізнесі, в якому доводиться передавати дані на великі відстані Присутність Інтернету постійно росте навіть у найвіддаленіших регіонах, що збільшує віддачу від використання VPN Якщо вам цікаво дізнатися подробиці про внутрішню роботу віртуальних приватних мереж, відвідайте сайт

http://computerhowstuffworkscom/vpnhtm

Реплікація злиття

Реплікація злиття призначена в основному для клієнтів з мобільними пристроями і тих, кому часто доводиться виходити в автономний режим Зміни можуть виконуватися як на стороні видавця, так і на стороні передплатника Коли запускається агент злиття (Merge Agent), ці зміни синхронізуються, після чого передплатник і видавець стають володарями одного і того ж безлічі даних У реплікації злиття використовуються тригери у всіх таблицях, що беруть участь в реплікації Використання ідентифікаторів GUID в шпальтах дозволяє унікально ідентифікувати всі рядки в усіх репліцируємих таблицях Коли зміни зачіпають одну з репліцируємих таблиць, вони записуються також у таблицю метаданих, що містить список ідентифікаторів GUID, відповідних зміненим рядках репліцируємих таблиць Коли запускається агент злиття, він витягує всі ідентифікатори з таблиць метаданих, відповідні рядках, зміненим на стороні видавця і передплатника Якщо деяка рядок була модифікована тільки на одній зі сторін, вона витягується з таблиці, породила зміни, після чого за допомогою інструкцій DML виконуються відповідні вставки, оновлення або видалення на протилежній стороні реплікації Якщо ж деяка рядок була змінена на обох сторонах реплікації, то агент злиття трактує цю ситуацію як конфлікт і приймає рішення, грунтуючись на правилах, закладених при конфігуруванні агента За замовчуванням в будь-якому конфлікті перевага віддається видавцеві Щоб змінити методику вирішення конфліктів, ви можете вибрати відповідне правило при створенні публікації При цьому використовується майстер нової публікації (New Publication Wizard)

1 Клацніть правою кнопкою миші на публікації, яку хочете змінити, і виберіть у контекстному меню пункт Properties

2 Виберіть папку Art i з 1 е s

3 Клацніть на кнопці Article Properties, встановіть перемикач в положення Set properties of Highlighted Table article або Set Properties of All Table articles, після чого перейдіть на вкладку Resolver (рис 391)

Puc 391 Вибір типу вирішення конфліктів у реплікації злиття

Для перегляду метаданих стовпців таблиць, опублікованих реплікацією, виберіть sysdm_repl_schemas в динамічному поданні управління

За умовчанням вибраний пункт Use Default Resolver Він має на увазі безперечну перевагу видавця або підписувача, що має найвищий пріоритет Доступні також наступні варіанти

■ Microsoft SQL Server Additive Coflict Resolver Значення стовпця, визначеного в текстовому полі Enter information needed by resolver, підсумовуються для конфліктуючих рядків

■ Microsoft SQL Server Averaging Coflict Resolver Значення стовпця, визначеного в текстовому полі Enter information needed by resolver, усереднюються для конфліктуючих рядків

■ Microsoft SQL Server DATETIME (Earlier Wins) Coflict Resolver Рядок із самою ранньою версією значення стовпця, визначеного в текстовому полі Enter information needed by resolver, виграє в конфлікті

■ Microsoft SQL Server DATETIME (Later Wins) Coflict Resolver Рядок з самої пізньої версією значення стовпця, визначеного в текстовому полі Enter information needed by resolver, виграє в конфлікті

■ Microsoft SQL Server Download Only Conflict Resolver У конфлікті виграють дані, завантажені передплатником

■ Microsoft SQL Server Maximum Coflict Resolver Рядок з найбільшим значенням стовпця, визначеного в текстовому полі Enter information needed by resolver, виграє в конфлікті

■ Microsoft SQL Server Merge Text Columns Conflict Resolver Дані в текстовому стовпчику, визначеному в текстовому полі Enter information needed by resolver, виграють у конфлікті

■ Microsoft SQL Server Maximum Coflict Resolver Рядок з найменшим значенням стовпця, визначеного в текстовому поле Enter information needed by resolver, виграє в конфлікті

■ Microsoft SQL Server Priority Conflict Resolver У конфлікті виграє рядок з найбільшим пріоритетом

■ Microsoft SQL Server Subscriber Always Wins Conflict Resolver У конфлікті завжди перемагає передплатник

■ Microsoft SQL Server Upload Only Conflict Resolver У конфлікті завжди перемагає рядок, завантажена від передплатника

■ Microsoft SQL Server Stored Procedure Conflict Resolver Вирішенням конфлікту управляє збережена процедура, визначена в текстовому полі Enter information needed by resolver

Ви маєте також два додаткових варіанти

■ Створити власну систему вирішення конфліктів на основі збережених процедур або компонентів СОМ

■ Використовувати розширену логіку, певну в просторі імен Microsoft SqlServer Replication BusinessLogicSupport обєктної моделі RMO

Ви можете також виконувати моніторинг на рівні стовпців У цьому випадку одночасна зміна одним вузлом адреси, а іншим номера телефону клієнта в одній і тій же рядку, дозволяє їм злити свої дані, НЕ переписавши зміни один одного Таким чином, у наведеному прикладі в базах даних і видавця, і передплатників буде як новий адресу, так і новий телефон Доступний також і варіант інтерактивного дозволу конфліктів Цей варіант доступний, коли у реплікації злиття з публікацією за запитом використовується Windows Synchronization Manager і публікація відкрита для інтерактивного вирішення конфліктів У цьому випадку при виявленні конфлікту запускається відповідний майстер, і користувач компютера передплатника має можливість як самостійно вирішити конфлікт, так і вибрати варіант, пропонований системою за замовчуванням

Реплікація злиття і передплатники SQL РЄ та SQL Mobile

SQL Server 2005 дозволяє користувачам мобільних систем SQL РЄ та SQL Mobile підписуватися на публікації реплікацій злиття Користувачі SQL Mobile можуть відкрити безліч підписок на різні публікації, в той час як користувачам SQL РЄ надається можливість підписатися тільки на одну публікацію кожної з баз даних SQL РЄ

Реплікація злиття через Інтернет

Новою в SQL Server 2005 є можливість виконання реплікацій злиття через захищені підключення Інтернету При цьому для синхронізації використовується протокол THHPS і процес, званий Web-синхронізацією У вас залишається можливість розміщувати підписки і на серверах FTP, проте цей варіант не вважається безпечним

Джерело: Нільсен, Пол Microsoft SQL Server 2005 Біблія користувача : Пер з англ – М: ООО ІД Вільямс , 2008 – 1232 с : Ил – Парал тит англ

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


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

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

Ваш отзыв

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

*

*