ПКРПСиБД LAB9 Захаров А.Е. (Лабораторная работа 9)
Описание файла
Файл "ПКРПСиБД LAB9 Захаров А.Е." внутри архива находится в папке "Лабораторная работа 9". Документ из архива "Лабораторная работа 9", который расположен в категории "". Всё это находится в предмете "распределённые ис и базы данных" из 9 семестр (1 семестр магистратуры), которые можно найти в файловом архиве НИУ «МЭИ» . Не смотря на прямую связь этого архива с НИУ «МЭИ» , его также можно найти и в других разделах. Архив можно найти в разделе "лабораторные работы", в предмете "распределённые ис и базы данных" в общих файлах.
Онлайн просмотр документа "ПКРПСиБД LAB9 Захаров А.Е."
Текст из документа "ПКРПСиБД LAB9 Захаров А.Е."
Национальный Исследовательский Университет
МОСКОВСКИЙ ЭНЕРГЕТИЧЕСКИЙ ИНСТИТУТ
Институт автоматики и вычислительной техники
Кафедра прикладной математики
Лабораторная работа № 9
Настройка репликации
в Microsoft SQL Server 2008
Курс «Проектирование крупных распределенных программных систем и баз данных»
Выполнил
студент группы А-13-08
Захаров Антон
Преподаватель
к.т.н., доц. Куриленко Иван Евгеньевич
Цель работы
Научиться настраивать репликацию в Microsoft SQL Server 2008.
Теоретическое введение
Распределённые базы данных (РБД) — совокупность логически взаимосвязанных баз данных, распределённых в компьютерной сети.
Репликация представляет собой набор технологий копирования и распространения данных и объектов баз данных между базами данных, а также синхронизации баз данных для поддержания согласованности. Используя репликацию, можно распространять данные в различные расположения, а также удаленным или мобильным пользователям по локальным или глобальным сетям.
Типы репликации:
-
репликация транзакций (обычно используется в сценариях «сервер-сервер»);
-
репликация сценариями;
-
репликация моментальных снимков используется для обеспечения начального набора данных для репликации транзакций и репликации слиянием.
Статья (article) — это объекты, которые мы будем реплицировать, такие как таблицы, процедуры, функции и т. д.
Публикация (publication) — это набор статей, или проще говоря окончательный набор объектов для репликации.
Фильтры – набор условий для статьи.
Издатель (publisher) – хранит главную копию базы данных, на которой настроена публикация
Подписчик (subscriber) — база данных, которая получает реплицируемые данные.
Распространитель (distribution) – экземпляр MS SQL server настроенный для сбора транзакции с публикаций и их распространения на подписчики. Распространитель так же имеет базу данных для хранения реплицируемых транзакций.
Репликация моментальных снимков
При репликации моментальных снимков агент Snapshot периодически (по заданному расписанию) копирует все помеченные для репликации данные с сервера/издателя в папку моментальных снимков распространителя. Агент Distribution периодически копирует все данные из папки моментальных снимков на каждый сервер/подписчик и, используя эти данные, полностью обновляет на нем публикацию. Агент Snapshot выполняется на распространителе, а агент Distribution может выполняться как на распространителе, так и на каждом сервере/подписчике. Оба агента записывают информацию журналов событий и журнала ошибок в БД распространения.
Репликация моментальных снимков наиболее подходит для работы с не слишком интенсивно изменяемыми данными, для небольших публикаций, которые могут обновляться полностью без существенного увеличения нагрузки на сеть, а также для данных, которые не нужно постоянно поддерживать в актуальном состоянии (допустим, архивные данные об объемах продаж).
При репликации моментальных снимков подписчикам можно разрешить обновлять реплицированную информацию немедленно и/или в порядке очереди. Возможность обновления подписки полезна, когда подписчикам требуется изредка изменять последнюю. Если же подписку изменяют часто, лучше использовать репликацию сведением. Кроме того, в случае с обновляемыми подписками все обновления являются частью транзакции. Это означает, что обновление либо целиком подтверждается, либо откатывается, если происходит конфликт. При репликации сведением конфликты разрешаются построчно.
Репликация транзакций
При репликации транзакций агент Snapshot создает исходный моментальный снимок данных, помеченных для репликации, и копирует его с сервера/издателя в папку моментальных снимков распространителя. Агент Distribution направляет полученный снимок каждому подписчику. Агент Log Reader следит за изменениями данных, участвующих в репликации, и фиксирует каждое изменение журнала транзакций в БД распространения на сервере/распространителе. Агент Distribution отправляет каждое изменение всем подписчикам в первоначальном порядке выполнения этих изменений. Если хранимая процедура используется для обновления большого количества записей, можно реплицировать эту процедуру, а не каждую обновленную строку. Все три этих агента репликации заносят информацию о событиях и ошибках в БД распространения.
Агент Distribution может работать постоянно, чтобы минимизировать задержку в обновлении данных между издателем и подписчиками, или может выполняться по заданному расписанию. Подписчики при наличии сетевого соединения с издателем могут получать изменения почти в реальном времени. После того как все подписчики получат реплицированные транзакции, агент Distribution Clean Up удаляет эти транзакции из БД распространения. Если по окончании заданного периода хранения подписчик не получил реплицируемые транзакции, те удаляются из БД распространения и подписка дезактивируется. Это позволяет предотвратить чрезмерное увеличение размера БД распространения. Дезактивированная подписка может быть повторно активирована, и тогда подписчику с целью обновления его данных передается новый моментальный снимок.
Репликация сведением
При репликации сведением агент Snapshot передает начальный моментальный снимок данных, участвующих в репликации, от издателя в папку моментальных копий распространителя. Агент Merge направляет полученный снимок каждому подписчику. Также он анализирует и объединяет изменения реплицируемых данных, выполняемые издателем и подписчиками. Если при объединении изменений происходит конфликт на издателе, агент Merge разрешает его, используя указанный администратором способ.
Чтобы различать записи отдельных копий реплицируемой таблицы и выявлять конфликты между записями, агент Merge использует специальный уникальный столбец реплицируемых таблиц. Если такого столбца нет, агент Snapshot добавляет его при создании публикации. Кроме того, при создании публикации агент Snapshot создает на издателе триггеры.
Они ведут мониторинг реплицированных записей и заносят информацию об изменениях в системные таблицы сведения. Агент Merge также создает идентичные триггеры на каждом сервере/подписчике, когда передает ему начальный моментальный снимок.
Агент Snapshot может работать постоянно или может выполняться по заданному расписанию. Если по окончании заданного периода хранения подписчик не получил реплицируемые транзакции, подписка дезактивируется. Дезактивированная подписка может быть повторно активирована, и тогда подписчику с целью обновления его данных передается новый моментальный снимок.
Настройка репликации каждого из трёх типов осуществлялось на виртуальных ОС Windows 8 с использованием VMware Workstation и SQL Server 2008.
Настройка публикации
Настройка репликации начинается с настройки публикации. В нашем случае публиковаться будут две таблицы (users и posts) базы данных.
1. Открываем SQL Server Management Studio на компьютере сервера (публикатора, PC1).
2. Создаём в ней базу данных DATABASE1.
3. Добавим в БД пару таблиц user и posts, используя инструменты Management Studio или следующий SQL скрипт:
USE [DATABASE1]
GO
IF EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[dbo].[users]') AND type in (N'U'))
DROP TABLE [dbo].[users]
GO
IF EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[dbo].[posts]') AND type in (N'U'))
DROP TABLE [dbo].[posts]
GO
USE [DATABASE1]
GO
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
SET ANSI_PADDING ON
GO
CREATE TABLE [dbo].[users](
[id] [int] NOT NULL,
[login] [varchar](50) NOT NULL,
[email] [varchar](50) NOT NULL
) ON [PRIMARY]
GO
CREATE TABLE [dbo].[posts](
[id] [int] NOT NULL,
[title] [varchar](255) NOT NULL,
[text] [text] NOT NULL,
[date] [timestamp] NOT NULL
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
GO
SET ANSI_PADDING OFF
GO
4. Переходим к настройке новой публикации: Replication >> Local publications >> New Publication…
5. Выбираем тип репликации, например, настроим репликацию моментальных снимков (Snapshot Publication). Другие варианты настраиваются аналогично.
6. Укажем статьи, т. е. объекты, которые мы будем реплицировать, такие как таблицы, процедуры, функции и т. д. В нашем случае будем реплицировать обе созданные таблицы.
7. На следующем шаге Microsoft SQL Server предлагает настроить фильтры, т. е. определить набор условий для статьи. Добавим простейший фильтр для таблицы posts: отфильтруем записи этой таблицы по id, пусть нас будут интересовать только новости с id из интервала [0;100]. Для этого нажмём на кнопку «Add» и в поле «Filter statement» введём следующий код фильтра:
SELECT FROM [dbo].[posts]
WHERE [id] BETWEEN 0 AND 100
8. Следующий шаг предлагает определить, когда необходимо запускать работу агента Snapshot. Кликнув по кнопке «Change…», можно определить любую периодичность. В данном случае настроен следующий график запуска агента моментальных снимков: каждый день, каждый час, начиная с 24 декабря 2012 года.
9. Требуется задать параметры безопасности для публикации. В данном случае использовался не рекомендуемый вариант запуска с настройками аккаунта SQL Server.
10. Потребуем немедленного создания публикации и генерации соответствующего файла скриптов.
11. На последнем шаге зададим название для новой публикации «SnapshotPub1» и убедимся в успешном завершении создания публикации.
Дополнительно может потребоваться разрешить удалённое подключение в SQL Server Configuration Manager.
Настройка подписки
Большинство шагов настройки подписки на публикацию похожи на настройку самой публикации, но всё же рассмотрим этот процесс подробнее.
1. Переходим к настройке новой подписки на виртуальной машине PC2:
Replication >> Local subscriptions >> New Subscription…
2. Выбираем созданную ранее публикацию для базы данных DATABASE1 виртуальной машины PC1. Укажем PC2 в качестве подписчика.
3. На следующем шаге требуется задать параметры безопасности для подключения к публикатору (см. шаг 9 настройки публикации).
4. На странице «Расписание синхронизации» в раскрывающемся списке выберем вариант «Run continuously» для непрерывной синхронизации.
5. Далее укажем, что подписку следует запустить немедленно, кликнув соответствующий чекбокс на странице «Инициализация подписки».
6. См. шаг 10 настройки публикации.
В заключении отмечу одну из частых проблем, возникающей при настройки репликации транзакций: таблица не может быть реплицирована, если она не содержит столбца с первичным ключом (PK, primary key), который требуется для репликации транзакций.
Москва, 2012