Обновляемые подписки (транзакции)

Установка исходных уровней производительности и настройка репликации при необходимости

Перед настройкой репликации рекомендуется ознакомиться с факторами, влияющими на производительность репликации:

серверное и сетевое аппаратное обеспечение;
структура базы данных;
конфигурация распространителя;
структура и параметры публикации;
структура фильтра и его использование;
Параметры подписки
Параметры моментального снимка
Параметры агента
Обслуживание

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

Задержка: время, затрачиваемое на распространение изменения данных между узлами в топологии репликации.
Пропускная способность: величина активности репликации (измеряемая в командах, доставленных за период времени), поддерживаемой системой.
Параллелизм: число процессов репликации, которые могут выполняться системой одновременно.
Длительность синхронизации: время, затрачиваемое на выполнение заданной синхронизации.
Потребление ресурсов: оборудование и сетевые ресурсы, используемые для обработки репликации.

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

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

Методы устранения неполадок

Вопросы

На каком этапе синхронизации происходит сбой репликации?
В каком агенте возникает ошибка?
Когда в последний раз репликация завершилась успешно? Изменилось ли что-нибудь с того момента?

Действия для выполнения

С помощью монитора репликации определите, на каком этапе репликации происходит ошибка (в каком агенте).
- Если ошибки возникают в разделе От издателя к распространителю, проблема связана с агентом чтения журнала.
- Если ошибки возникают в разделе От распространителя к подписчику, проблема связана с агентом распространения.
Чтобы получить подробные сведения об ошибке, просмотрите журнал заданий соответствующего агента в мониторе активности заданий. Если сведений в журнале заданий недостаточно, можно для агента.
Попробуйте определить решение проблемы.

Исходная база данных

Прежде чем новый подписчик репликации транзакций сможет получить добавочные изменения от издателя, на подписчике должны находиться таблицы со схемой и данными, совпадающими со схемой и данными в таблицах на издателе. Исходный набор данных обычно является моментальным снимком, созданным агентом моментальных снимков, который распространяется и применяется агентом распространителя. Исходный набор данных может также предоставляться через резервную копию или другим способом, например службами SQL Server Integration Services.

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

Предварительные требования

Это руководство для пользователей, которые умеют выполнять основные операции с базами данных и которые имеют ограниченный опыт репликации. Перед тем как приступить к работе с этим учебником, необходимо освоить Учебник. Подготовка SQL Server к репликации.

Для работы с этим учебником требуется SQL Server, среда SQL Server Management Studio (SSMS) и база данных AdventureWorks.

На сервере-издателе (источник) установите следующее:
- Любой выпуск SQL Server, кроме SQL Server Express или SQL Server Compact. Эти выпуски не могут быть издателями репликации.
- Образец базы данных AdventureWorks2012 . В целях повышения безопасности образцы баз данных по умолчанию не устанавливаются.
На сервере-подписчике (целевом) установите любой выпуск SQL Server, кроме SQL Server Compact. SQL Server Compact не может быть подписчиком при репликации транзакций.
Установите SQL Server Management Studio.
Установите выпуск SQL Server 2017 Developer Edition.
Скачайте пример базы данных AdventureWorks. См. дополнительные сведения о восстановлении базы данных в среде SSMS.

Примечание

Репликация не поддерживается в экземплярах SQL Server, которые отличаются друг от друга больше, чем на две версии. См. дополнительные сведения о поддерживаемых версиях SQL Server в топологии репликации.
В среде SQL Server Management Studio необходимо подключиться к издателю и подписчику с помощью имени входа, которое является членом предопределенной роли сервера sysadmin. Дополнительные сведения о роли см. в статье Роли уровня сервера.

Предполагаемое время выполнения заданий этого учебника: 60 минут

Репликация AD через 56к

Реплицировать данные каждые 15 минут удобно и приятно, но только если все контроллеры домена связаны между собой высокоскоростным соединением. А что если два контроллера находятся в другом районе или деревне, где они могут быть подключены к общей сети только по DialUp? В этом случае, трафик репликации может отнять слишком много ресурсов, и полосы пропускания не хватит на решение других задач.

Чтобы этого избежать, можно и даже нужно разделить эти сервера на сайты. Все контроллеры, подключенные по высокоскоростной связи поместить в один сайт, а два удаленных в другой сайт. Внутри сайтов репликация может происходить по правилам, установленным по умолчанию, а вот между сайтами, можно настроить обмен так, чтобы не перегрузить полосу и оставить ее для передачи более важных данных. Такое разделение ты без проблем можешь настроить с помощью оснастки AD Sites and Services.

В качестве возможных вариантов сохранения трафика, в technet от MS предлагаются варианты:

репликации данных по ночам;
репликации в обеденные перерывы;
репликации с большими промежутками времени.

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

Издатель-дистрибутор-подписчик

Чаще всего репликацию связывают с базами данных и мы в основном будем говорить о базах данных на примере MS SQL Server. Причем не только с классическими базами, но и такими специализированными, как Active Directory. Но на этом мир не перевернулся, репликацию можно удачно использовать и для простых файлов, главное правильный подход.

Репликация в MS SQL Server строиться на трех понятиях – издатель, дистрибутор и подписчик. Чтобы понять, что это означает, достаточно обратиться к нашей реальной жизни, где издатель выдает какую-то информацию дистрибутору, а тот рассылает ее подписчикам. Точно также и в компьютерной жизни. Но обо всем по порядку.

Издатель — хранит источник базы данных, делая опубликованные данные из таблиц базы данных доступными для репликации, находит и отправляет изменения дистрибьютору.

Дистрибьютор – это сервер, который содержит распределенную базу данных и хранит метаданные, историю данных и транзакции. Роль дистрибьютора может быть разной и зависит от типа развернутой репликации.

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

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

Решение

Для решения этой проблемы воспользуйтесь одним из указанных ниже способов.

Метод 1. Использование команды

Чтобы устранить эту проблему, обновите неверное значение rowcount. Для этого выполните следующую команду.

Примечание.

Команда определяет правильные значения для строк, используемых страниц, зарезервированных страниц, конечных страниц и счетчиков страниц данных для каждой секции в таблице. Если эти значения верны, команда не возвращает данных. Если неточные значения найдены и исправлены, возвращает обновляемые строки и столбцы.
Метод 2. Использование инструкции

Чтобы устранить эту проблему, перестройте индексы, связанные с таблицей . Для этого используйте следующую инструкцию:

Типы репликации в SQL Server

Транзакционная репликация. Как говорит название, каждая транзакция или изменение данных в рамках транзакции на издателе будет посылаться подписчику почти в реальном времени с минимальной задержкой, зависящей от пропускной способности сети и ресурсов сервера. Транзакционная репликация использует агента читателя журнала для чтения изменения данных из журналов транзакций в базе данных издателя. Она также использует агента распределения для применения изменений на подписчике. Иногда может использоваться агент снимка для получения исходных данных снимка всех реплицированных статей. Публикация транзакционной репликации может подпадать под следующие категории:
- Стандартная транзакционная репликация — подписчик представляет собой базу данных только на чтение с точки зрения транзакционной репликации. Любые изменения, выполняемые кем угодно в базе данных подписчика не будут отслеживаться и обновляться в базе данных издателя. Стандартная транзакционная репликация часто называется просто транзакционной репликацией.
- Транзакционная репликация с обновляемыми подписками является расширением стандартной транзакционной репликации, которая отслеживает изменения данных, имеющих место на подписчике. Всякий раз, когда изменения происходят на обновляемой подписке, они будут сначала распространяться на издателя, а затем по другим подписчикам.
- Одноранговая репликация является расширением стандартной транзакционной репликации. Она распространяет транзакционно согласованные изменения почти в реальном времени по множеству экземпляров сервера.
- Двунаправленная репликация является расширением стандартной транзакционной репликации, которая позволяет двум серверам (ограничение только на 2 сервера — отсюда название «двунаправленная») обмениваться изменениями данных между собой с каждым из серверов, работающих как издатель (для пересылки изменений на другой сервер) или как подписчик (для получения изменений с другого сервера).
Репликация слиянием — поддерживает регистрацию изменений данных, происходящих как на издателе, так и на подписчике, и распространяет их на другой сервер. Репликация слиянием требует наличия столбца ROWGUID в таблицах статей, вовлеченных в репликацию слиянием. Она использует триггеры для захвата изменений данных на издателе и подписчике. Кроме того, доставляет изменения на серверы, когда оба и издатель, и подписчик, подключены к сети. Репликация слиянием использует агента слияния для репликации изменений данных на издателе и подписчике.
Репликация снимками — как говорит название, репликация снимками не опирается ни на журналы транзакций, ни на триггеры для регистрации изменений. Она берет снимок статей, участвующих в публикации и применяет его на подписчике с записями, имеющимися на время создания снимка. Репликация снимками использует агента снимка, чтобы взять снимок издателя, и использует агента распространения, чтобы применить эти записи на подписчике.

Асинхронная репликация

транзакционный поток («TX»);
сетевой поток («IProto»);
журнальный поток («WAL»);
репликационный поток («Relay»).

Общая схема

Транзакция создаётся в TX-потоке, пользователь начинает её коммит и его файбер засыпает.
Транзакция отправляется в WAL-поток для записи в журнал, записывается, в TX-поток уходит положительный ответ.
TX-поток будит файбер пользователя, пользователь видит успешный коммит.
Просыпается relay-поток, читает эту транзакцию из журнала и посылает её в сеть на реплику.
На реплике её принимает applier-файбер, коммитит её.
Транзакция отправляется в WAL-поток реплики, записывается в её журнал, в TX-поток уходит положительный ответ.
Applier-файбер посылает ответ со своим новым vclock, что всё нормально применилось.

Одноранговые топологии

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

Топология с двумя участвующими базами данных

На обоих приведенных выше рисунках показаны две участвующие базы данных и пользовательский трафик, направленный к базам данных через сервер приложений. Такую конфигурацию можно использовать для различных приложений — от веб-сайтов до приложений рабочих групп. Это позволяет получить следующие преимущества.

Улучшенная производительность операции чтения, так как чтение распределено на два сервера.
Более высокая доступность при необходимости обслуживания или в случае сбоя одного из узлов.

На обеих иллюстрациях операция чтения между участвующими базами данных сбалансирована, но обновления обрабатываются разными способами:

Слева операции обновления секционируются между двумя серверами. Если база данных содержит каталог продукции, можно, например, создать пользовательское приложение, направляющее обновления продуктов, начинающихся символами с «А» до «М», на узел A , а обновления продуктов с «Н» до «Я» — на узел B .
Справа все обновления направляются на узел В. С узла В обновления реплицируются на узел A. Если узел B находится в режиме «вне сети» (например, на обслуживании), сервер приложений может направлять все операции на узел A. Когда узел B переходит в режим «в сети», на него можно направлять обновления и сервер приложений может переместить все обновления обратно на узел B или сохранить их передачу на узел A.

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

Топологии с тремя или более участвующими базами данных

На предыдущем рисунке показаны три участвующие базы данных, предоставляющие данные для глобальной организации по поддержке программного обеспечения с офисами в Лос-Анджелесе, Лондоне и Тайбэе. Инженеры службы поддержки во всех офисах принимают звонки клиентов, вводят и обновляют сведения о каждом звонке. Часовые пояса трех офисов отличаются на восемь часов, поэтому рабочие часы не перекрываются. Когда закрывается офис в Тайбэе, открывается офис в Лондоне. Если звонок находится в стадии обработки во время закрытия одного офиса, он передается представителю в другой открытый офис.

В каждом офисе имеется база данных и сервер приложений, которые используются инженерами службы поддержки для ввода и обновления сведений о звонках клиентов. Топология секционируется по времени. Поэтому обновления происходят на узле, открытом для бизнеса в текущее время, а затем передаются в другие участвующие базы данных. Данная топология обеспечивает следующие преимущества:

Независимость без изоляции: в каждом офисе можно независимо добавлять, обновлять или удалять данные; при этом также можно использовать данные совместно, так как они реплицируются во все участвующие базы данных.
Более высокая доступность в случае сбоя или во время обслуживания одной или нескольких участвующих баз данных.

На предыдущем рисунке показано добавление узла в топологию с тремя узлами. В этом сценарии узел можно добавить по следующим причинам.
Так как другой офис открыт.
Чтобы обеспечить более высокую доступность в целях поддержки обслуживания или повышения отказоустойчивости при сбое диска или других серьезных неисправностях.

Обратите внимание, что в обеих трех- и четырехузловых топологиях все базы данных публикуют свои данные и подписываются на данные из остальных баз данных. Этим обеспечивается максимальная доступность при проведении обслуживания или в случае сбоя на одном или нескольких узлах

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

Настройка обновляемой подписки из подписчика

Подключитесь к подписчику в среде Microsoft SQL Server Management Studio и раскройте узел сервера.
Раскройте папку Репликация .
Щелкните правой кнопкой мыши папку Локальные подписки , затем щелкните Создать подписку.
На странице Публикациямастера создания подписки выберите Найти издатель SQL Server из раскрывающегося списка Издатель.
Соединитесь с издателем в диалоговом окне Соединение с сервером .
Выберите публикацию транзакций, настроенную для обновляемых подписок на странице Публикация.
На страницах мастера укажите параметры подписки, например, место, где должен выполняться агент распространения.
На странице Обновляемые подписки в мастере создания подписок должен быть отмечен параметр Реплицировать.
Выберите параметр Зафиксировать на стороне издателя в раскрывающемся списке.
- Для немедленного обновления подписок выберите Одновременно фиксировать изменения. Если выбран этот параметр, а для публикации разрешено обновление подписок посредством очередей (по умолчанию для публикаций, созданных с помощью мастера создания публикаций), то свойство подписки update_mode будет иметь значение failover. Этот режим позволяет, при необходимости позднее перейти к обновлению посредством очередей.
- Для обновления подписок посредством очередей выберите Ставить изменения в очередь и фиксировать при первой возможности. Если выбран этот параметр, для публикации разрешено немедленное обновление подписок (по умолчанию для публикаций, созданных с помощью мастера создания публикаций), и на подписчике работает SQL Server 2005 или более поздняя версия, то свойство подписки update_mode примет значение queued failover. Этот режим позволяет, при необходимости, включить немедленное обновление позднее.
Дополнительные сведения см. в статье Переключение между режимами обновления для обновляемой подписки на публикацию транзакций.
Страница Имя входа для обновляемых подписок отображается для подписок, применяющих немедленное обновление, либо имеющих параметр update_mode в значении queued failover. На странице Имя входа для обновляемых подписок укажите связанный сервер, через который устанавливаются соединения с издателем для обновления подписок. Соединения используются триггерами, которые запускаются на подписчике и распространяют изменения на издатель. Выберите один из следующих вариантов.
- Создать связанный сервер, который соединяется с использованием проверки подлинности SQL Server:. Выберите этот параметр, если вы не определили удаленный сервер или связанный сервер между подписчиком и издателем. Репликация создает связанный сервер. Указанная учетная запись уже должна существовать на издателе.
- Использовать уже указанный связанный или удаленный сервер Выберите этот параметр, если вы определили удаленный сервер или связанный сервер между подписчиком и издателем с помощью процедуры sp_addserver (Transact-SQL),sp_addlinkedserver (Transact-SQL), SQL Server Management Studio или другого метода.
Дополнительные сведения о разрешениях, требуемых для учетной записи связанного сервера, см. в статье Подписки, обновляемые посредством очередей из введите здесь описание ссылки
Завершите работу мастера.

Еще о репликации Active Directory (AD)

Если хочешь узнать больше о репликации в Acive Directory, и нет проблем с английским, то рекомендую скачать следующий документ: www.certmag.com/bookshelf/C0617953.pdf. Это 92 страницы полезного и халявного чтива. Если и этого мало, то бегом на technet от Microsoft. Там информация изложена не так удобно и последовательно, но очень много хороших рекомендаций.

По Active Directory и репликации в частности могу посоветовать сайт only4gurus.com и конкретно ссылочка — http://www.only4gurus.com/v3/sitemap_active_directory.shtml. По репликации здесь можно найти хорошие презентации, рисунки которой были взяты за основу к данной статье. Я лишь перевел эти рисунки на мой родной русский и немного подкорректировал, чтобы они были нагляднее.

Настройка издателя для репликации транзакций

В этом разделе вы создадите публикацию транзакций с помощью SQL Server Management Studio для публикации отфильтрованного подмножества таблицы Product в образце базы данных. Также в список доступа к публикации (PAL) добавляется имя входа SQL Server, используемое агентом распространителя.

Создание публикации и определение статей

Подключитесь к издателю в среде SQL Server Management Studio, а затем раскройте узел сервера.
Щелкните правой кнопкой мыши элемент Агент SQL Server и выберите пункт Запустить. Прежде чем приступить к созданию публикации, необходимо запустить агент SQL Server. Если при выполнении этого действия агент не запускается автоматически, его нужно запустить вручную с помощью диспетчера конфигурации SQL Server.
Разверните папку Репликация, щелкните правой кнопкой мыши папку Локальные публикации и выберите пункт Создать публикацию. После этого запустится мастер создания публикации:
На странице База данных публикации выберите и нажмите кнопку Далее.
На странице Тип публикации выберите Публикация транзакций и нажмите кнопку Далее:
На странице Статьи разверните узел Таблицы и установите флажок Продукт. Затем разверните элемент Product и снимите флажки рядом с ListPrice и StandardCost. Выберите Далее.
На странице Фильтрация строк таблицы нажмите кнопку Добавить.
В диалоговом окне Добавление фильтра выберите столбец SafetyStockLevel. Щелкните стрелку вправо, чтобы добавить столбец в предложение WHERE инструкции фильтра запроса. После этого вручную введите следующий модификатор предложения WHERE:
Нажмите кнопку ОК, а затем кнопку Далее.
Установите флажок Создать моментальный снимок немедленно и обеспечить доступ к нему для инициализации подписок и нажмите кнопку Далее:
На странице Безопасность агентов снимите флажок Использовать настройки безопасности агента моментальных снимков.

Выберите Настройки безопасности для агента моментальных снимков. Введите Publisher_Machine_Name>\repl_snapshot в поле «Учетная запись процесса», введите < пароль для этой учетной записи и нажмите кнопку «ОК».
Повторите предыдущий шаг, чтобы задать <Publisher_Machine_Name>\repl_logreader в качестве учетной записи процесса для агента чтения журнала. Нажмите кнопку ОК.
На странице Завершение работы мастера введите AdvWorksProductTrans в поле Имя публикации и нажмите кнопку Готово:
После создания публикации нажмите кнопку Закрыть, чтобы закрыть мастер.

Если при попытке создать публикацию обнаруживается, что агент SQL Server не запущен, может возникнуть следующая ошибка. Она указывает на то, что публикация создана успешно, но при этом агент моментальных снимков запустить не удалось. В этом случае необходимо запустить агент SQL Server, а затем вручную запустить агент моментальных снимков. Инструкции приведены в следующем разделе.

Просмотр состояния создания моментального снимка

Подключитесь к издателю в среде SQL Server Management Studio, а затем разверните узел сервера и папку Репликация.
В папке Локальные публикации щелкните правой кнопкой мыши публикацию AdvWorksProductTrans и выберите пункт Просмотр состояния агента моментальных снимков:
Отобразятся сведения о текущем состоянии задания агента моментальных снимков для публикации. Перед тем как перейти к следующему разделу, убедитесь, что задание моментального снимка выполнено успешно.

Если агент SQL Server не был запущен при создании публикации, в сведениях о состоянии агента моментальных снимков для публикации будет указано, что он никогда не запускался. В таком случае выберите Запустить, чтобы запустить агент моментальных снимков:

Если отображается сообщение об ошибке, ознакомьтесь с разделом .

Добавление имени входа агента распространения в список доступа к публикации

Подключитесь к издателю в среде SQL Server Management Studio, а затем разверните узел сервера и папку Репликация.
В папке Локальные публикации щелкните правой кнопкой мыши публикацию AdvWorksProductTrans и выберите пункт Свойства. Откроется диалоговое окно Свойства публикации.

a. Выберите страницу Список доступа к публикации и нажмите кнопку Добавить.
b. В диалоговом окне «Добавление доступа к публикации » выберите <Publisher_Machine_Name>\repl_distribution и нажмите кнопку «ОК».

Дополнительные сведения см. статье Основные понятия программирования репликации.