MS SQL Server: настройка репликации

Репликация транзакций проста в настройке и доступна во всех версиях SQL Server. Данный тип репликации используется для двух целей:

• Репликация данных между несколькими серверами для read доступа (например, для разгрузки серверов OLTP типа);


• Как решение для избыточности данных отдельных объектов.

Хотя у SQL Server есть много решений для балансировки нагрузки select запросов и средств обеспечения отказоустойчивости, транзакционная репликация это самый простой и быстрый способ, так как вы можете реплицировать отдельные объекты. Так же этот вид репликации полностью доступен в Standard лицензии SQL Server ( в отличии от групп доступности Always On, которые полноценно доступны только в Enterprise).

Преимущество репликации перед Always ON и зеркалированием баз данных в том, что с помощью репликации вы можете скопировать отдельные объекты (отдельные таблицы/представления), а не базу данных целиком.

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

SQL Server: основы технологии репликации

В любом типе репликации SQL Server есть 3 типа серверов:

• Publisher (издатель) – основной экземпляр-источник, который публикует статьи;
• Distributor (распространитель) – экземпляр который распространяет статьи на сервера-подписчики. Этот тип экземпляра не хранит у себя данные издателя на постоянной основе, а распространяет их подписчикам;
• Subscriber (подписчик) – экземпляр который получает распространяемые статьи.

Роли могу пересекаться между собой. Например, один экземпляр может быть и издателем, и подписчиком (но не самого себя).

Работа репликации транзакций осуществляется через внутренние агенты SQL Server’а:

• Агент чтения журналов;
• Агент моментальных снимков;
• Агент распространения.

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

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

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

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

Не много комментариев к данному видео: 

1. Для того чтобы с сервера  Distributor увидеть сервер на который вы собираетесь "отправлять" базу в hosts пропишите имя сервера с его IP 

2. Также на сервер который выступает в роли Subscriber должна быть учетная запись которую вы впишиет на "последнем" шаге и под ней реплика будет "подключаться" к серверу "подписчика"

3. Обратите внимания на правила фаервол это также очень важно.

Второе видео по репликации, очень похоже, с тем отличием  что тут не затронуты правила фаервола и не рассмотрен вопрос как нужно настроить сервер  Subscriber чтобы все заработало. Но для понимания его тоже стоит взглянуть