Репликация SQL Server использует парадигму публикатора, распространителя и подписчика для обеспечения возможности репликации логических данных между различными экземплярами SQL Server и иногда с гетерогенным источником данных или получателем данных. Репликация использует базы данных распространения, размещенные у распространителя, для централизованного управления и контроля конфигурации и функционирования репликации данных. Хотя фактические данные, подлежащие репликации, находятся в пользовательских базах данных, репликация SQL Server использует объекты и артефакты вне пользовательских баз данных, таких как база данных основных данных, база данных msdb, базы данных распространения и даже файловые системы.

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

Многие корпоративные заказчики попросили объединить использование репликации SQL Server и Always On, чтобы они могли размещать базы данных распространения репликации в Always On AG для обеспечения высокой доступности для своих баз данных распространения с ожиданием, что после этого и когда случится сбой AG, репликация SQL Server будет продолжать работать бесперебойно и правильно. Хотя базы данных публикации и подписки репликации могут быть настроены для использования групп доступности, эта поддержка отсутствовала для баз данных распространения репликации.

Команда разработчиков SQL Server с радостью объявляет о новом улучшении, касающемся конфигурации базы данных распространения репликации в группе доступности. Это усовершенствование функции будет доступно с SQL Server 2017 CU6 и будет перенесено на SQL Server 2016 в следующем CU для SP2.

Улучшение может помочь решить следующие сценарии клиентов:

1. Высокая доступность для репликационной базы данных распространения. База данных распространения является основой топологии репликации. Потеря базы данных распространения означает, что вся топология перестает получать изменения. Сервер распространения может быть защищен экземпляром FCI SQL Server, но это обеспечивает только локальную HA, но не сайт DR. Для достижения сайта DR, текущее рекомендуемое решение заключается в использовании географически распределенных экземпляров отказоустойчивого кластера с репликацией уровня хранилища с использованием:

• либо аппаратной репликаций SAN, которая является чрезмерно дорогой для клиентов
• либо репликаций SAN на основе ПО Windows 2016 S2D. Хотя это обеспечивает недорогое решение, эта функция отсутствует в более ранних версиях Windows и, следовательно, не работает для версий SQL Server, таких как SQL Server 2012 и SQL Server 2014.

2. Минимизация времени обновления / переноса. Поскольку репликация SQL Server сильно зависит от имен серверов, обновление / миграция экземпляров SQL Server, на которых размещена репликационная  база данных распространения, требует повторного развертывания / повторной настройки всей топологии репликации. Это требует много времени и требует значительного времени простоя. Это поможет свести к минимуму простои и сложность обновления SQL-серверов в топологии репликации.
3. Стандартизация одного решения HADR на предприятии. Большинство клиентов уровня Tier-1 стандартизируют группы доступности SQL Server в качестве решения для своих требований HADR, за исключением репликационной  базы данных распространения, для которой единственными параметрами были SQL Server FCI. Новая функция улучшает этот сценарий.

Документацию вокруг возможностей функции и деталей конфигурации (вместе с примерами скриптов) можно найти здесь.

Поддерживаемые сценарии

• Настройка базы данных распространения, которая будет включена в группу доступности.
• Настройка репликации, включая публикации и подписки до и после восстановления в группе доступности.
• Задания репликации, выполняемые до и после восстановления.
• Удаление репликации на стороне распространителя и публикатора, когда база данных распространителя находится в группе доступности.
• Добавление или удаление узлов для существующей группы доступности базы данных распространителя.
• Распространитель может иметь несколько баз данных распространения. Каждая база данных распространения может входить в собственную группу доступности или не принадлежать ни одной такой группе. Несколько баз данных распространения могут использовать одну группу доступности.
• Публикатор и распространитель должны размещаться на отдельных экземплярах SQL Server

Ограничения или исключения

В первом выпуске этой функции существуют следующие ограничения и исключения.

• Локальный распространитель не поддерживается. Например, публикатор и распространитель должны быть разными экземплярами SQL Server. Публикатор, использующий себя в качестве распространителя (локальный дистрибьютор a.k.a.), не может поддерживать базы данных распространения в AG.
• Не поддерживаются следующие сценарии репликации:
• Репликация слияния
• Транзакционная репликация с немедленным или поочередным обновлением подписчика
• Одноранговая репликация
• Двунаправленная транзакционная репликация.
• Все экземпляры SQL Server, на которых размещаются реплики базы данных распространения, должны использовать ту же версию SQL Server, то есть SQL Server 2017 CU 6 или более поздней версии, и
• В базе данных распределения AG должен быть настроен прослушиватель.
• Вторичные реплики в базе данных распространения AG могут быть синхронными или асинхронными. Рекомендуется использовать синхронный режим. С асинхронными вторичными репликами есть риск потери данных и возможны проблемы несовместимости.
• Все вторичные реплики в базе данных распространения AG должны быть доступны для чтения. Это связано с тем, что есть несколько этапов настройки, которые должны выполняться во вторичных репликах.
• Все узлы в базе данных распространения AG должны использовать одну и ту же учетную запись домена для запуска агента SQL Server, и эта учетная запись домена должна иметь одинаковую привилегию для каждого узла.
• Если какой-либо из агентов репликации выполняется с использованием учетной записи-посредника, такая учетная запись-посредник должна существовать на каждом узле в группе доступности базы данных распространителя и иметь  одинаковую привилегию для каждого узла.
• Если вам необходимо внести изменения в распространитель или изменить свойства базы данных рассылки, это необходимо сделать во всех репликах, участвующих в базе данных распространения AG.
• Настройка распространителя на публикатора должна выполняться со сценариями. Нельзя использовать мастер репликации .Поддерживаются мастера репликации и страницы свойств для других целей.
• Монитор репликации и другой пользовательский интерфейс репликации, который соединяется с использованием имени прослушивателя AG, не поддерживаются в SQL Server 2017 CU 6. Для администрирования агентов репликации, связанных с базой данных распространения в AG, используйте свойство работы и историю заданий. Эта возможность будет доступна в последующих выпусках SSMS.
• Конфигурирование AG для баз данных распространения может выполняться только через скрипты.
• Настройка баз данных распространения в AG должна быть новой конфигурацией репликации. Переключение существующей базы данных распространения в AG не поддерживается. Кроме того, после того, как база данных распространения будет извлечена из AG, она больше не может функционировать как действительная база данных распространения и должна быть удалена.

ОБНОВЛЕНИЕ 05/10

Начиная с SQL Server Management Studio 17.7, монитор репликации поддерживает регистрацию прослушивателя для сценариев, в которых база данных публикатора и / или база данных распространителя является частью группы доступности. Теперь вы можете отслеживать среды репликации, где база данных публикатора и / или база данных распространения являются частью Always On.

No Comments