4 что представляет собой репликация файла
Обновлено: 03.07.2024
Чаще всего репликацию связывают с базами данных и мы в основном будем говорить о базах данных на примере MS SQL Server. Причем не только с классическими базами, но и такими специализированными, как Active Directory. Но на этом мир не перевернулся, репликацию можно удачно использовать и для простых файлов, главное правильный подход.
Репликация в MS SQL Server строиться на трех понятиях – издатель, дистрибутор и подписчик. Чтобы понять, что это означает, достаточно обратиться к нашей реальной жизни, где издатель выдает какую-то информацию дистрибутору, а тот рассылает ее подписчикам. Точно также и в компьютерной жизни. Но обо всем по порядку.
Издатель - хранит источник базы данных, делая опубликованные данные из таблиц базы данных доступными для репликации, находит и отправляет изменения дистрибьютору.
Дистрибьютор – это сервер, который содержит распределенную базу данных и хранит метаданные, историю данных и транзакции. Роль дистрибьютора может быть разной и зависит от типа развернутой репликации.
Дистрибьютор и издатель могут быть на одном компьютере. Чаще всего нет смысла выделять для каждого отдельный сервер, но для большой базы данных, и наиболее активных сайтов, можно располагать дистрибьютора на собственном сервере для оптимизации производительности.
Подписчик – владеет копией данных, и получает изменения произведенные издателем. В зависимости от настроек репликации, подписчик может иметь права изменять данные и реплицировать их обратно издателю для репликации другим подписчикам. Это называется обновляющий подписчик.
Фильтруй базар
Возможно, для публикации вам нужен поднабор таблицы как отдельной статьи. Это называется фильтрацией данных. Фильтрация данных позволяет избавиться от конфликтов репликации, когда несколько сайтов имеют право обновлять данные. Ты можешь фильтровать таблицы вертикально, горизонтально или смешанно для создания отфильтрованной порции данных.
Вертикальный фильтр содержит поднабор колонок таблицы. Только реплицированные колонки отображаются подписчику. Для примера, можно использовать вертикальный фильтр для публикации всех колонок кроме «Заработная плата» в таблице «Работники».
Горизонтальный фильтр содержит поднабор строк таблицы. Подписчик получает только этот поднабор строк. Если ненужно реплицировать информацию о левых доходах, то ее можно отфильтровать запросом.
Возможно подписание на публикацию с помощью Push или Pop метода. Метод Push обычно используется в приложениях, которые должны отправлять изменения подписчику как можно быстрее после изменения. Этот метод более предпочтителен для публикаций требующих высокую защищенность и где высокая загрузка процессора у дистрибьютора не влияет на производительность.
Метод Pop более подходит в публикациях с меньшей защищенностью и может поддерживать большое количество подписчиков, например подписчики Internet.
Типы репликации
Существует три основных типа репликации: снимок, журнальный и смешение. Тип репликации назначается каждой публикации. Таким образом, возможно использование нескольких типов репликации в одной базе данных.
Репликация снимка распределяет данные напрямую как отображение на определенный момент, без мониторинга изменений. Это самый простой тип, при котором происходит банальное копирование снимка всех или отфильтрованных данных. Можете уронить свой взгляд на этот тип в следующих случаях:
- данные изменяются существенно, но редко;
- подписчику требуются данные только для чтения;
- возможна большая задержка, потому что данные обычно только периодически обновляются;
- подписчику требуется автономность.
При репликации транзакций от источника к приемнику поступают только изменения. Агент мониторит изменения в журнале транзакций на изменение реплицированных данных и переносит необходимые записи дистрибьютору. Агент дистрибьютора отправляет изменения подписчику. Прежде чем этот тип начнет работать, подписчику отправляется полный снимок реплицированных таблиц, а затем подписчик получает только изменения.
Репликация транзакций может использоваться там, где необходимо, чтобы подписчик получал изменения с минимальной задержкой.
Смешение - этот тип позволяет сайтам автономно изменять реплицированные данные. Позже, изменения с сайтов сливаются в одно целое. Этот тип не гарантирует целостности транзакций, но он гарантирует, что все сайты сливаются в один результирующий набор.
Репликация MS SQL Server
Очень удачно сделана возможность репликации в MS SQL Server. Настройка проста, как три копейки, потому что ее легко сделать с помощью двух мастеров, но есть подводные камни, о которых мастер не может рассказать, а мануалы просто умалчивают. Итак, давайте бегло пробежимся по процессу настройки репликации и сделаем упор на подводные булыжники, о которых все молчат как рыбы.
Для начала необходимо создать издателя и дистрибутора. Для этого на одном из серверов выбираем меню Tools | Replication | Create and Manage Publication. Я бы порекомендовал использовать для издателя машину помощнее. Первое, что у нас попросит мастер – выбрать базу данных. Выбираем, жмем Create Publication, и на следующем этапе сервер предложит создать дистрибутора. По умолчанию дистрибутором предлагается сделать ту же машину.
Мастер запрашивает создание дистрибутора репликации
Тут появляется первый подводный камень – если дистрибутор будет установлен на удаленно от издателя (на другой машине), то SQL Server Agent не может работать от имени системного аккаунта. Почему? Агент должен иметь возможность авторизоваться на машине дистрибутора и передать изменения, а для этого используется учетная запись, под которой работает агент. Под Local Account авторизоваться нигде не удастся, поэтому изменения никуда не пойдут.
Настройка учетной записи MS SQL Server Agent
После этого вам предложат сконфигурировать самого агента вручную или автоматически. Если выбрать ручной режим, то количество шагов мастера резко возрастает, но они просты и с минимальными знаниями английского ты разберешься в них. Если выбрать автомат, то остается только указать мастеру требуемый тип репликации – снимок (Snapshot publication), транзакции (Transaction publication) или смешение (Merge publication) и указать необходимые таблицы. Да, в репликации участвует не вся база, а указанные таблицы. Системные таблицы реплицировать незачем.
Выбор типа репликации
После создания издателя необходимо создать подписчика и настройку можно считать завершенной. Во время создания подписчика ты сможешь настроить план выполнения, указать дни, время или промежутки, через которые нужно выполнять репликацию.
Если ты настроил репликацию, и решил перенести базу данных на другой сервер, то можешь забыть про перенос через резервное копирование и восстановление. Дело в том, что в резервную копию не попадает информацию о репликации :(. Тут приходиться отключать базу Detach, копировать файлы на другой компьютер и подключать их заново Attach.
Золотой ключик
Следующая проблема, с которой ты можешь столкнуться – репликация ключевых полей. Если у тебя они имеют тип Guid, то никаких проблем тут не будет, но если Identity, то тебя ждут серьезные проблемы. Дело в том, что автоматически увеличиваемые поля не могут корректно реплицироваться с настройками по умолчанию, особенно при смешении, когда подписчик может изменять данные и должен уметь возвращать их издателю.
Допустим, что на двух компьютерах были созданы две разные записи с одинаковыми идентификаторами, что делать серверу? Какую из записей выбирать? По идее, в результирующую таблицу должно попасть обе записи, но изменять ID нельзя, особенно, если таблица связанная, а две записи с одинаковым ключом невозможны.
Проблема решается достаточно просто, нужно только выполнить следующие шаги:
- 1. Создаем копию базы данных издателя на компьютере подписчика.
- 2. Открываем окно редактирования таблицы или с помощью SQL запроса устанавливаем на издателе для ключа начальное значение 1, а для подписчика 1 000 000.
Все просто и красиво. Теперь, при добавлении записи на издателе новые записи будут нумероваться 1, 2, 3, 4. а на подписчике 1000001, 1000002, 1000003. Таким образом, записи пересекутся не скоро и конфликты могут никогда не появиться, особенно, если записи добавляются в таблицу не слишком интенсивно. Если же записи добавляются интенсивно, то откажись от автоувеличения и используй GUID поля в качестве ключа.
Запрос на копирование схемы
Но и это еще не все. При создании подписчика, тебе предложат перенести всю схему с издателя. Это удобно, если структура таблиц разная и их необходимо синхронизировать, но в нашем случае неприемлемо. Если ты поведешься на это предложение и ответишь Yes, то схема издателя будет скопирована подписчику и у обоих начальное значение ключа станет единицей, и все твои старания пойдут прахом, т.е. затрутся. Чтобы этого не произошло, жми No и наслаждайся, главное, чтобы на подписчике структура таблиц была такой же, как и у издателя.
Ручной запуск репликации
Репликация Active Directory (AD)
Active Directory, которая активно используется серверами Windows – это тоже база данных. Она может быть распределенной, когда в работе участвуют несколько серверов, и при этом, пользователь должен иметь возможность войти на любой из них с одним и тем же паролем. Как это сделать? Зарегистрироваться на каждом сервере в отдельности? Глупо и бессмысленно. И тут на помощь приходит репликация. Достаточно зарегистрироваться на одном сервере и прописать необходимые права доступа и вся информация будет реплицирована куда надо.
Репликация в AD происходит автоматически и чаще всего не требует особого вмешательства, но требует хорошего понимания основной идеи. Если бы с Active Directory было бы все так просто, то я не рассматривал бы эту технологию отдельно. Для начала нужно понимать, что для аутентификации используется протокол Kerberos и ответственность за подлинность берет на себя контроллер домена. Когда ты заходишь на сервер, то имя и пароль направляются серверу, который проверяет эти данные и в случае удачи выдает белый билет. Нет, билет конечно не белый, но на его основе пользователь получает те или иные права. Если есть желание и нет знаний, то советую поближе познакомиться с Active Directory и Kerberos, а наша задача – репликация.
Если до Windows 2000 в сети мог быть только один контроллер домена, который хранил все самое важное и управлял репликацией (тогда не было и Kerberos), то в нынешних версиях может быть несколько контроллеров. При этом все они будут равноправными. Это усложняет задачу по управлению процессом репликацию и разрешению возможных конфликтов, но окна нашли простое решение. Контроллеры домена наблюдают друг за другом, определяя, какой из них в данный момент будет дистрибутором, т.е. одарит других изменениями.
Настраивать вручную соединения между контроллерами доменов в сети нет необходимости, хотя и есть такая возможность. Сервера сами через определенные промежутки времени отслеживают доступные контроллеры и хранят в памяти всю необходимую информацию.
Конфликты в Active Directory
Благодаря тому, что репликация выполняется с задержкой, сервер реплицирует обновления пачками. Все изменения в Active Directory накапливаются и в определенный момент рассылаются всем контроллерам домена. Это хорошо, но за счет задержки возможны и проблемы. Допустим, что в определенный промежуток времени, одновременно произошло изменение на двух контроллерах домена. Чьи изменения будут реплицированы? Давай попробуем разобраться.
Все объекты Active Directory имеют версию, которая при создании получает значение единицы. После каждого редактирования объекта версия увеличивается, поэтому если приходит просьба реплицировать запись с меньшим номером версии, чем текущая, то такие изменения откатываются.
А что если серверу придет одновременно два предложения на репликацию от разных контроллеров, и при этом версии объектов будут одинаковыми, но сами объекты разными? Такое может случиться, когда один и тот же объект с идентичной версией изменяется на разных контроллерах. Оба контроллера увеличат версию, и она будет снова одинаковой. В этом случае побеждает тот сервер и соответствующее изменение, которое было сделано последним.
Самый крайний случай – когда версии одинаковы и даже время изменения идентично. Конечно, вероятность этого слишком мала, но она есть, поэтому разработчики Active Directory в данном случае предпочли выбирать то изменение, которое пришло с сервера с большим глобальным идентификатором GUID. Конечно, это глупый выбор и может оказаться далеко не точным, но он хоть как-то решает конфликт.
Каждый контроллер, получив изменения, пытается втулить их другим контроллерам вашей сети. Тут тоже есть проблема - представим, что у нас три контроллера домена. Редактируем объект на первом и он, конечно же, должен уведомить остальных об изменения. Они забрали эти изменения, но в этот момент второй контроллер пытается эти же изменения впихнуть нам обратно или на третий домен, который уже забрал изменения. Что делать в этом случае? Все очень просто – у нас же есть версия изменений и по ней можно узнать, нужно забирать запись, или она уже реплицирована.
Эта проблема частично решается и тем, что репликация может пройти не дальше трех контроллеров. Если сервер получил изменения третьим, то дальше он уже никому его передавать не будет. Передача репликации по цепочки происходит, только если контроллер получил новую версию объекта первым или вторым.
Репликация AD через 56к
Реплицировать данные каждые 15 минут удобно и приятно, но только если все контроллеры домена связаны между собой высокоскоростным соединением. А что если два контроллера находятся в другом районе или деревне, где они могут быть подключены к общей сети только по DialUp? В этом случае, трафик репликации может отнять слишком много ресурсов, и полосы пропускания не хватит на решение других задач.
Чтобы этого избежать, можно и даже нужно разделить эти сервера на сайты. Все контроллеры, подключенные по высокоскоростной связи поместить в один сайт, а два удаленных в другой сайт. Внутри сайтов репликация может происходить по правилам, установленным по умолчанию, а вот между сайтами, можно настроить обмен так, чтобы не перегрузить полосу и оставить ее для передачи более важных данных. Такое разделение ты без проблем можешь настроить с помощью оснастки AD Sites and Services.
В качестве возможных вариантов сохранения трафика, в technet от MS предлагаются варианты:
- репликации данных по ночам;
- репликации в обеденные перерывы;
- репликации с большими промежутками времени.
Мне импонируют первые два варианта, особенно, если сайты находятся в одной временной зоне. Но если один расположен в Москве, а другой на Чукотке, то ты не то, что в обеденный перерыв не сможешь попасть, когда в Москве день, в Петропавловске уже полночь.
Еще о репликации Active Directory (AD)
Итого
Я надеюсь, что я смог тебя убедить, что репликация – это не просто синхронизация, а более продвинутый и интеллектуальный шаг вперед. При правильном подходе, этот шаг будет большим. Если ты хорошо разберешься с этой темой, то без проблем сможешь даже сделать ручную репликацию так, где ее нет изначально. Ведь не во всех базах данных реализована такая возможность.
За кадром данной статьи осталась очень интересная тема – репликация Exchange сервера. У нее очень много похожего на Active Directory и SQL Server, но есть и интересные нюансы.
Поделитесь с друзьями
Внимание. Если ты копируешь эту статью себе на сайт, то оставляй ссылку непосредственно на эту страницу. Спасибо за понимание
Delphi site: daily Delphi-news, documentation, articles, review, interview, computer humor.
Теперь рассмотрим некоторые файлы, участвующие в процессе репликации. О двоичном журнале и журнале ретрансляции вы уже знаете, но есть и другие файловые объекты. Конкретное место их хранения зависит в основном от конфигурационных параметров MySQL. В разных версиях СУБД умолчания различны. Чаще всего их можно найти в каталоге данных или в каталоге, где находится pid-файл сервера (в UNIX-системах это обычно каталог /var/run/mysqld/). Перечислим их.
Если запись в двоичный журнал включена, то сервер создает файл с таким же именем, как у двоичных журналов, но с расширением
.index. В нем регистрируются все файлы двоичных журналов, имеющиеся на диске. Это не индекс в том смысле, в каком мы говорим об индексах по таблицам; он просто состоит из текстовых строк, в каждой из которых указано имя одного файла двоичного журнала. Вероятно, у вас возникла мысль, что этот файл лишний и может быть удален (в конце концов, MySQL может просто найти все файлы на диске). Не делайте этого! MySQL игнорирует двоичные журналы, не указанные в индексном файле.
Этот файл играет ту же роль для журналов ретрансляции, что рассмотренный выше файл для двоичных журналов.
В этом файле хранится информация, необходимая подчиненному серверу для соединения с главным. Формат текстовый (по одному значению в строке) и изменяется в зависимости от версии MySQL. Не удаляйте его, иначе после перезапуска подчиненный сервер не будет знать, как подключиться к главному. Поскольку в этом файле может храниться пароль пользователя в открытом виде, будет разумно максимально ограничить права доступа к нему.
В этом файле на подчиненном сервере хранятся имя его текущего двоичного журнала и координаты репликации (то есть место в двоичном журнале главного сервера, до которого дошел подчиненный). Не удаляйте этот файл, иначе после перезапуска подчиненный сервер не будет знать, с какого места продолжить репликацию, и попытается воспроизвести уже выполненные команды.
Совокупность этих файлов представляет собой довольно прямолинейный способ сохранить состояние репликации и журналов. К сожалению, запись в них производится не синхронно, поэтому если произойдет сбой питания в момент, когда файлы не были сброшены на диск, то после перезапуска данные в них окажутся некорректными.
По умолчанию имя двоичного журнала образуется из имени хоста, к которому добавляется цифровой суффикс, но лучше задать базовое имя явно в файле my.cnf:
Следует также явно выбирать имена для журналов ретрансляции (которые тоже по умолчанию образуются из имени хоста) и соответствующих index-файлов. Вот как мы рекомендуем задавать все эти параметры в файле my.cnf:
log_bin_index = mysql-bin.index relay_log = mysql-relay-bin
Вообще-то index-файлы по умолчанию наследуют имена от соответствующих файлов журналов, но не будет никакого вреда, если задать их явно.
На index-файлы влияет также параметр expire_logs_days, определяющий, сколько времени MySQL должен сохранять уже закрытые двоичные журналы. Если в файле mysql-bin.index упоминаются файлы, отсутствующие на диске, то автоматическое удаление работать не будет; даже команда PURGE MASTER LOGS ничего не даст. В общем случае для решения этой проблемы нужно поручить управление двоичными журналами самому серверу MySQL, уж он-то не запутается.
Необходимо выработать стратегию удаления старых журналов - с помощью параметра expire_logs_days или иными средствами, - иначе рано или поздно MySQL заполнит двоичными журналами весь диск. При этом следует учитывать и принятую в организации политику резервного копирования. Дополнительную информацию о двоичном журнале см. в разделе «Формат двоичного журнала» на стр. 601.
Что такое репликация? Это средство организации работы одного или нескольких пользователей с одним и тем же документом, базой данных или другими-файлами на разных компьютерах независимо, без одновременного доступа к файлам, но когда требуется поддерживать некоторую общую версию изменяемых файлов, содержащую в себе все последние исправления, сделанные независимо. Более конкретно, репликация — это процесс создания копий файлов, между которыми может осуществляться обмен обновляемыми данными или объектами. Такие копии называются репликами, а такой обмен — синхронизацией .
Когда нужна репликация? Microsoft приводит два примера необходимости в такой организации работы.
- Вы — агент по продажам и совершаете поездки для посещения клиентов. Перед поездкой вам нужно просмотреть последние заказы и маркетинговые тенденции клиентов, которых вы собираетесь посетить. Эта информация хранится в базах данных о клиентах и заказах вашей компании. Вы загружаете данные о клиентах на свой переносной компьютер. Во время посещения клиента вы обновляете загруженную информацию о клиенте, например: номера телефонов, адреса E-mail и прочую персональную информацию о клиенте на вашем переносном компьютере, а также вносите туда информацию о новых заказах. Однако вам необходимо закончить работу с заказами как можно быстрее. В конце дня вы подключаетесь по Интернету к сети вашей компании через защищенное удаленное соединение и обновляете базы данных о клиентах и заказах. Конфликты данных автоматически разрешаются благодаря имеющимся бизнес-процедурам. После этого вы печатаете и отправляете клиенту по факсу отчет о принятии заказа или отправляете снимок отчета по E-mail, который клиент может просмотреть с помощью программы Просмотр снимков (Snapshot Viewer).
- Вы — разработчик программного обеспечения и хотите закончить работу с приложением вашей компании, отслеживающим статистику об обнаружении и исправлении ошибок в проекте, дома, где нет необходимого или защищенного доступа к корпоративной сети. Вы забираете данные только о ваших ошибках, помещая их на свой переносной компьютер, и отключаете его от корпоративной сети. Затем приходите домой и работаете с имеющимися данными, изменяя поля статуса ошибки и прочие поля с информацией об ошибке. На следующий день* вы подключаете свой переносной компьютер к корпоративной сети и легко син-* хронизируете свои изменения с приложением вашей компании, отслеживающим; статистику ошибок в проекте.
Существует несколько средств репликации баз данных, проектов Access и других файлов.
- Портфельная репликация— средство операционной системы Microsoft Windows. Оно позволяет осуществлять репликацию файлов многих типов, в том числе баз данных Access (файлов MDB), исключая проекты Access (файлы ADP).
- Репликация баз данных и проектов средствами Access — встроенные средства Microsoft Access. Они предназначены для репликации баз данных и проектов Access.
- Репликация с помощью Диспетчера репликации Microsoft— полнофункциональное средство управления репликами, планирования синхронизации и просмотра элементов набора реплик. Диспетчер репликации входит в комплект средств разработчика Microsoft Office 2002 Developer Edition. Описание Диспетчера репликации (Replication Manager) можно найти в документации этого комплекта.
- Репликация файлов на сервере Web — средство сервера Web фирмы Microsoft. Оно позволяет работать с файлами, сохраненными на узле Web, в автономном режиме — без подключения к серверу.
- Программная репликация с помощью интерфейсов DАО и JRO. Создание и управление репликами баз данных Access может осуществляться программно — в процедурах на VBA. Разработчики приложений Access могут обеспечить автоматическую синхронизацию реплик и прочие действия, связанные с репликацией, используя специальные свойства и методы объектов из библиотек VBA: Объекты репликации и Jet (JRO) для репликации баз данных Access 2000 и выше и Объекты доступа к данным (DАО) для репликации баз данных более ранних версий — Access 95 и 97.
Репликация включает следующие действия:
- выбор средства репликации;
- создание реплик;
- синхронизация реплик;
- управление репликами.
Способ выполнения перечисленных действий зависит от выбранного средства репликации. Мы рассмотрим основные вопросы, касающиеся использования перечисленных средств репликации, но не будем касаться темы программирования. Дополнительную информацию о репликации можно найти в справочной системе Access 2002.
В этой статье мы рассмотрим, как настроить самый распространений тип репликации в SQL Server – транзакционную репликацию. Этот тип репликации SQL Server используется для копирования данных в режиме реального времени, то есть данные на подписчиках появляются практически сразу (с учетом времени которое тратится на копирование данных по сети).
Репликация транзакций проста в настройке и доступна во всех версиях SQL Server. Данный тип репликации используется для двух целей:
- Репликация данных между несколькими серверами для read доступа (например, для разгрузки серверов OLTP типа);
- Как решение для избыточности данных отдельных объектов.
Хотя у SQL Server есть много решений для балансировки нагрузки select запросов и средств обеспечения отказоустойчивости, транзакционная репликация это самый простой и быстрый способ, так как вы можете реплицировать отдельные объекты. Так же этот вид репликации полностью доступен в Standard лицензии SQL Server ( в отличии от групп доступности Always On, которые полноценно доступны только в Enterprise).
Преимущество репликации перед Always ON и зеркалированием баз данных в том, что с помощью репликации вы можете скопировать отдельные объекты (отдельные таблицы/представления), а не базу данных целиком.
Единственный минус транзакционной репликации —она не может работать в синхронном режиме – то есть, дожидаться завершения транзакции на подписчиках. Поэтому в случае форс-мажорного выключения любого участника репликации, данные могут быть потеряны или может произойти рассинхронизация между издателем и подписчиками.
SQL Server: основы технологии репликации
В любом типе репликации SQL Server есть 3 типа серверов:
- Publisher (издатель) – основной экземпляр-источник, который публикует статьи;
- Distributor (распространитель) – экземпляр который распространяет статьи на сервера-подписчики. Этот тип экземпляра не хранит у себя данные издателя на постоянной основе, а распространяет их подписчикам;
Роли могу пересекаться между собой. Например, один экземпляр может быть и издателем, и подписчиком (но не самого себя).
Работа репликации транзакций осуществляется через внутренние агенты SQL Server’а:
- Агент чтения журналов;
- Агент моментальных снимков;
- Агент распространения.
При появлении транзакций в объектах, участвующих в репликации, на издателе, агент чтения журналов копирует эти транзакции на экземпляр-распространитель, затем агент распространитель копирует данные на подписчиков. Агент моментальных снимков участвует только тогда, когда нужно скопировать новый моментальный снимок (обычно это происходит при инициализации и реинициализации репликации).
Транзакции доставляются на подписчиков в той последовательности, в которой они были отправлены на издателя. Если транзакций слишком много, образуется очередь.
Транзакционная репликация работает асинхронно, так же как и асинхронные режимы Always On и зеркалирования баз данных. То есть, данные, которые были записаны на издатель, будут отправлены на подписчики без гарантии доставки в случае сбоя во время передачи данных. Это нужно учитывать, если вы собираетесь использовать транзакционную репликацию для избыточности и высокой доступности данных в SQL Server.
Схема связи агентов между собой из официальной документации:
Рассмотрим, как настроить репликацию в SQL Server на следующем тестовом стенде:
- 2 виртуальные машины с Windows Server 2019 в одной сети;
- 2 установленных экземпляра SQL Server 2019.
- testnode1\node1 – издатель (Publisher);
- testnode2\node2 – подписчик (Subscriber);
- testnode2\node2 – распространитель (Distributor).
В этом примере мы будем реплицировать одну таблицу с testnode1\node1 на testnode\node2. В роли распространителя будет выступать testnode2\node2.
Настройка распространителя в SQL Server
Для начала нужно настроить экземпляр распространителя. В разделе Replication, в контекстном меню нажмите Configure Distribution…
Так как мы хотим использовать этот экземпляр в качестве распространителя, выбираем первый пункт (testnove2 will act as its own Distributor; SQL Server will create a distribution databasse and log).
Указываем директорию для моментальных снимков. Я оставлю стандартный путь.
Указываем директорию для базы данных Distribution. Если есть такая возможность, то лучше разместить файлы базы данных distribution на отдельном массиве дисков. Особенно это важно, если планируется большой объём реплицируемых данных.
На этом шаге можно указать экземпляры, которые смогут использовать данный сервер как распространитель. Я сразу добавлю testnode1\node1. Это можно сделать и позже, после начальной конфигурации.
Укажите пароль для связи с экземплярами, которые будут связываться с распространителем.
После этого можно жать Finish. На этом настройка распространителя завершена.
Если вы хотите изменить пароль распространителя или разрешить другим издателям использовать этот распространитель, то можно это сделать через Distributor Properties…
Настройка издателя репликации в SQL Server
Теперь переходим к настройкам издателя репликации. Запустите тот же мастер Configure Distributuin.
Выберите второй пункт, указываем сервер распространитель – testnode2\node2
После этого введите пароль, который вы указывали при настройке распространителя и нажмите Finish.
Теперь можно создать новую публикацию: Replication -> Local Publication -> New Publication.
Укажите базу данных, которая будет участвовать в репликации.
Выберите тип репликации. Доступны:
- Snapshot publication;
- Transactional publication (выберите этот тип репликации);
- Peer-to-Peer publication;
- Merge publication.
Выберите таблицы, которые нужно реплицировать. С помощью транзакционной репликации так же можно реплицировать пользовательские процедуры, функции и представления. Реплицируемые объекты называются Articles (Статьи).
На следующем шаге можете указать фильтр для публикации.
Чтобы мастер сразу создал моментальный снимок, выберите опцию “Create a snapshot immediately and keep the snapshot available to initialize subscriptions”.
Укажите аккаунты, из-под которых будут выполняться агенты. Нажмите Security Settings и выберите “Run under SQL Server Agent service account”.
В имени публикации я указываю названия сервера-подписчика. Так легче ориентироваться если публикаций на другие сервера будет много.
Настройка подписчика репликации в SQL
На testnode2\node2 в разделе Replication -> Local Subscriptions создайте новую подписку.
Выберите издателя, базу данных и публикацию в ней.
Выберите пункт “Run all agents at the Distributor”, чтобы агенты выполнялись на распространителе. В моём случае подписчик и распространитель совпадают, но обычно это разные сервера.
Если выбрать второй пункт (“Run each agent at its Subscriber”), то агенты будут выполняться на подписчике. Этот вариант предпочтителен, если распространитель у вас “формальный” и находится на одном сервере с издателем или подписчиком
Укажите базу данных, в которую будут реплицироваться данные из Subscription Database.
Снова укажите аккаунт, из-под которого будут выполняться агенты репликации.
Если вы хотите, чтобы данные реплицировались постоянно, выбирайте режим Agent Schedule -> Run continuously.
Включите опцию Initialize, чтобы инициализировать подписку после завершения работы мастера.
При включении параметра “Memory Optimized” таблицы на подписчике с этой публикации будут созданы как “In memory”. Если вы не планируете эти таблицы как таблицы для использования в оперативной памяти, то не отмечайте этот параметр.
На этом настройка подписки завершена. Теперь необходимо проверить работоспособность публикации и корректность выполнения репликации таблицы.
Мониторинг и управление репликацией в SQL Server
Практически всю настройку существующих публикаций можно провести через Replication Monitor.
Добавьте издателей через распространителя (Add Publisher -> Specify a Distributor and Add its Publishers).
После того, как вы соединитесь с распространителем, у вас появится список издателей, которые работают с этим распространителем.
Убедимся, что агент моментальных снимков отработал и доставил снимок на распространителя. В моём случае сначала была ошибки о том, что аккаунту из-под которого работают агенты, не хватает прав на базе TestDatabase1. Для решения этой проблемы я добавил сервисному аккаунту (из-под которого работает SQL Server) роль db_owner в базе TestDatabase1 на обоих экземплярах.
Так же убедимся, что распространитель доставил транзакции на подписчика.
В логах агентов ошибок нет, проверим что наша таблица действительно появилась в базе.
Для начала добавим новую запись в таблицу.
Проверяем, что эта запись реплицировалась на testnode2\node2.
На этом базовая настройка репликации транзакций в SQL Server закончена.
Для диагностики проблем с репликацией в основном используется Replication Monitor, но можно использовать и дополнительные инструменты диагностики SQL Server.
Читайте также: