Что такое репликация базы данных

Репликация баз данных MySQL. Введение

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

Что такое репликация, и зачем она нужна

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

Как MySQL реплицирует данные

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

В общем виде, репликация в MySQL состоит из трех шагов:

Виды репликации

Существует два принципиально разных подхода к репликации: покомандная и построчная. В случае покомандной репликации, в журнал мастера протоколируются запросы изменения данных (INSERT, UPDATE, DELETE), а слейвы в точности воспроизводят те же команды у себя. При построчной же репликации в журнале окажутся непосредственно изменения строк в таблицах, и эти же фактические изменения применятся затем на слейве.

Как нет серебряной пули, так и каждый из этих методов имеет свои преимущества и недостатки. Покомандная репликация проще в реализации и понимании, снижает нагрузку на мастер и на сеть. Но тем не менее, покомандная репликация может приводить к непредсказуемым эффектам, при использовании недетерминированных функций, таких как NOW(), RAND(), и т.д. Могут быть также проблемы, вызванные рассинхронизацией данных между мастером и слейвом. Построчная же репликация приводит к более прогнозируемым результатам, так как фиксируются и воспроизводятся фактические изменения данных. Тем не менее этот метод может значительно увеличивать нагрузку на мастер-сервер, которому приходится фиксировать каждое изменение в журнале, и на сеть, через которую эти изменения распространяются.

В MySQL поддерживаются оба способа репликации, а дефолтный (можно сказать, что и рекомендуемый) изменялся в зависимости от версии. В современных версиях, например MySQL 8, по умолчанию используется построчная репликация.

Второй принцип разделения подходов к репликации — количество мастер-серверов. Наличие одного мастер сервера подразумевает, что только он принимает изменения данных, и является неким эталоном, с которого уже распространяются изменения на множество слейвов. В случае же с мастер-мастер репликацией мы получаем как и некоторый профит, так и проблемы. Один из плюсов, например, то, что мы можем давать удаленным клиентам из тех же Сиднея и Хельсинки одинаково быструю возможность записывать свои изменения в базу. Из этого исходит и главный недостаток, если оба клиента одновременно изменили одни и те же данные, чьи изменения считать окончательными, чью транзакцию коммитить, а чью откатывать.

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

Пример построения простой репликации в MySQL

А сейчас настало время создать простую конфигурацию репликации в MySQL. Для этого мы будем использовать Docker и MySQL образы из dockerhub, а также базу данных world.

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

Для мастер контейнера указано подключение volume c дампом world.sql, для того, чтобы имитировать наличие некоторой начальной базы на нем. При создании контейнера, mysql загрузит и выполнит sql скрипты, размещенные в директории docker-entrypoint-initdb.d.

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

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

Далее, изменим конфигурационные файлы для мастер-сервера:

В файл my.cnf в секции [mysqld] необходимо добавить следующие параметры:

При включении/выключении двоичного журнала необходима перезагрузка сервера. В случае с Docker перезагружается контейнер.

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

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

Далее, с помощью mysqldump сделаем экспорт данных из базы. Конечно, в данном примере можно использовать тот же world.sql, но приблизимся к более реалистичному сценарию.

После этого, необходимо еще раз выполнить команду SHOW MASTER STATUS, и запомнить или записать значения File и Position. Это, так называемые координаты двоичного журнала. Именно от них мы далее укажем стартовать слейву. Начиная с MySQL 5.6 стало возможным использование глобальных идентификаторов транзакций GTID вместо координат в виде файл-позиция. Это упростило настройку репликации, а также повысило стабильность ее работы. Но рассмотрение этой темы выходит за рамки данной статьи, и с ней можно ознакомиться в документации.

Теперь можем снова разблокировать мастер:

Мастер настроен, и готов реплицироваться на другие сервера. Перейдем теперь к слейву. Первым делом, загрузим в него дамп, полученный с мастера.

А затем изменим конфиг слейва, добавив параметры:

После этого перезагрузим слейв:

И теперь нам нужно указать слейву, какой сервер будет являться для него мастером, и откуда начинать реплицировать данные. Вместо MASTER_LOG_FILE и MASTER_LOG_POS необходимо подставить значения, полученные из SHOW MASTER STATUS на мастере. Эти параметры вместе называются координатами двоичного журнала.

Запустим воспроизведение журнала ретрансляции, и проверим статус репликации:

Если все прошло успешно, ваш статус должен иметь аналогичный вид. Ключевые параметры здесь:

И проверить, появились ли они на слейве.

Отлично! Внесенная запись видна и на слейве. Поздравляю, теперь вы создали свою первую репликацию MySQL!

Заключение

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

Источник

Основы репликации в MySQL

Небольшое введение

Настройка репликации

Настройки мастера

Обязательно укажем уникальный ID сервера, путь для бинарных логов и имя БД для репликации в секции [mysqld]:
= 1
log-bin = /var/lib/mysql/mysql-bin
replicate-do-db = testdb
Убедитесь, что у вас достаточно места на диске для бинарных логов.

Добавим пользователя replication, под правами которого будет производится репликация. Будет достаточно привилегии «replication slave «:
mysql@master> GRANT replication slave ON «testdb».* TO «replication»@»192.168.1.102» IDENTIFIED BY «password»;

Перезагрузим MySQL, чтобы изменения в конфиге вступили в силу:
root@master# service mysqld restart

Если все прошло успешно, команда «show master status » должна показать примерно следующее:
mysql@master> SHOW MASTER STATUS\G
File: mysql-bin.000003
Position: 98
Binlog_Do_DB:
Binlog_Ignore_DB:
Значение position должно увеличиваться по мере того, как вносятся изменения в БД на мастере.

Настройки реплики

Укажем ID сервера, имя БД для репликации и путь к relay-бинлогам в секции [mysqld] конфига, затем перезагрузим MySQL:
= 2
relay-log = /var/lib/mysql/mysql-relay-bin
relay-log-index = /var/lib/mysql/mysql-relay-bin.index
replicate-do-db = testdb

root@replica# service mysqld restart

Переносим данные

Здесь нам придется заблокировать БД для записи. Для этого можно либо остановить работу приложений, либо воспользоваться установкой флажка read_only на мастере (внимание: на пользователей с привилегией SUPER этот флаг не действует). Если у нас есть таблицы MyISAM, сделаем также «flush tables»:
mysql@master> FLUSH TABLES WITH READ LOCK;
mysql@master> SET GLOBAL read_only = ON;

Посмотрим состояние мастера командой «show master status» и запомним значения File и Position (после успешной блокировки мастера они не должны изменятся):
File: mysql-bin.000003
Position: 98

Делаем дамп БД, и после завершения операции снимаем блокировку мастера:
mysql@master> SET GLOBAL read_only = OFF;

Переносим дамп на реплику и восстанавливаем из него данные.
Наконец, запускаем репликацию командами «change master to» и «start slave» и посмотрим, все ли прошло хорошо:
mysql@replica> CHANGE MASTER TO MASTER_HOST = «192.168.1.101 «, MASTER_USER = «replication «, MASTER_PASSWORD = «password «, MASTER_LOG_FILE = «mysql-bin.000003 «, MASTER_LOG_POS = 98;
mysql@replica> start slave;
Значения MASTER_LOG_FILE и MASTER_LOG_POS мы берем с мастера.

Посмотрим, как идет репликация командой «show slave status «:
mysql@replica> SHOW SLAVE STATUS\G
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.1.101
Master_User: replication
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000003
Read_Master_Log_Pos: 98
Relay_Log_File: mysql-relay-bin.001152
Relay_Log_Pos: 235
Relay_Master_Log_File: mysql-bin.000003
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB: testdb,testdb
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 98
Relay_Log_Space: 235
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 5

Наиболее интересные сейчас значения я выделил. При успешном начале репликации их значения должны быть примерно такими, как в листинге (см. описание команды «show slave status » в документации). Значение Seconds_Behind_Master может быть любым целым числом.
Если репликация идет нормально, реплика будет следовать за мастером (номер лога в Master_Log_File и позиция Exec_Master_Log_Pos будут расти). Время отставания реплики от мастера (Seconds_Behind_Master), в идеале, должно быть равно нулю. Если оно не сокращается или растет, возможно, что нагрузка на реплику слишком высока — она просто не успевает повторять изменения, происходящие на мастере.
Если же значение Slave_IO_State пусто, а Seconds_Behind_Master равно NULL, репликация не началась. Смотрите лог MySQL для выяснения причины, устраняйте её и заново запускайте репликацию:
mysql@replica> start slave;

Добавляем реплики

Пусть у нас уже есть работающие мастер и реплика, и нам нужно добавить к ним еще одну. Сделать это даже проще, чем добавить первую реплику к мастеру. И гораздо приятнее то, что нет необходимости останавливать для этого мастер.
Для начала настроим MySQL на второй реплике и убедимся, что мы внесли нужные параметры в конфиг:
= 3
replicate-do-db = testdb

Теперь остановим репликацию на первой реплике:
stop slave;

Реплика продолжит работать нормально, однако данные на ней уже не будут актуальными. Посмотрим статус и запомним позицию мастера, до которой реплика дошла перед остановкой репликации:
SHOW SLAVE STATUS\G

Нам нужные будет значения Master_Log_File и Exec_Master_Log_Pos:
Master_Log_File: mysql-bin.000004
Exec_Master_Log_Pos: 155

Создадим дамп БД и продолжим репликацию на первой реплике:
START SLAVE;

Восстановим данные из дампа на второй реплике. Затем включим репликацию:
CHANGE MASTER TO MASTER_HOST = «192.168.1.101 «, MASTER_USER = «replication «, MASTER_PASSWORD = «password «, MASTER_LOG_FILE = «mysql-bin.000004 «, MASTER_LOG_POS = 155;
START SLAVE;

Значения MASTER_LOG_FILE и MASTER_LOG_POS — это соответственно значения Master_Log_File и Exec_Master_Log_Pos из результата команды «show slave status » на первой реплике.
Репликация должна начаться с той позиции, на которой была остановлена первая реплика (и соответственно, создан дамп). Таким образом, у нас будет две реплики с идентичными данными.

Объединяем реплики

Иногда возникает такая ситуация: на мастере существует две БД, одна из которых реплицируется на одной реплике, а вторая — на другой. Как настроить репликацию двух БД на обеих репликах, не делая их дампы на мастере и не выключая его из работы? Достаточно просто, с использованием команды «start slave until «.
Итак, у нас имеется master с базами данных testdb1 и testdb2, которые реплицируются соответственно на репликах Настроим репликацию обеих БД на replica-1 без остановки мастера.
Остановим репликацию на replica-2 командой и запомним позицию мастера:
STOP SLAVE;
SHOW SLAVE STATUS\G
Master_Log_File: mysql-bin.000015
Exec_Master_Log_Pos: 231

Создадим дамп БД testdb2 и возобновим репликацию (на этом манипуляции с replica-2 закончились). Дамп восстановим

Ситуация на replica-1 такая: БД testdb1 находится на одной позиции мастера и продолжает реплицироваться, БД testdb2 восстановлена из дампа с другой позиции. Синхронизируем их.

Остановим репликацию и запомним позицию мастера:
STOP SLAVE;
SHOW SLAVE STATUS\G
Master_Log_File: mysql-bin.000016
Exec_Master_Log_Pos: 501

Убедимся, что в конфиге на секции [mysqld] указано имя второй БД:
replicate-do-db = testdb2

Перезагрузим MySQL, чтобы изменения в конфиге вступили в силу. Кстати, можно было просто перезагрузить MySQL, не останавливая репликацию — из лога мы бы узнали, на какой позиции мастера репликация остановилась.

Теперь проведем репликацию с позиции, на которой была приостановлена позиции, на которой мы только что приостановили репликацию:
CHANGE MASTER TO MASTER_HOST = «192.168.1.101 «, MASTER_USER = «replication «, MASTER_PASSWORD = «password «, MASTER_LOG_FILE = «mysql-bin.000015 «, MASTER_LOG_POS = 231;
start slave until MASTER_LOG_FILE = «mysql-bin.000016 «, MASTER_LOG_POS = 501;

Репликация закончится, как только реплика дойдет до указанной позиции в секции until, после чего обе наши БД будут соответствовать одной и той же позиции мастера (на которой мы остановили репликацию Убедимся в этом:
SHOW SLAVE STATUS\G
START SLAVE;
Master_Log_File: mysql-bin.000016
Exec_Master_Log_Pos: 501

Добавим в конфиг на секции [mysqld] имена обеих БД:
replicate-do-db = testdb1
replicate-do-db = testdb2

Важно: каждая БД должна быть указана на отдельной строке.
Перезагрузим MySQL и продолжим репликацию:
CHANGE MASTER TO MASTER_HOST = «192.168.1.101 «, MASTER_USER = «replication «, MASTER_PASSWORD = «password «, MASTER_LOG_FILE = «mysql-bin.000016 «, MASTER_LOG_POS = 501;
После того, как replica-1 догонит мастер, содержание их БД будет идентично. Объединить БД на replica-2 можно или подобным образом, или сделав полный дамп

Рокировка мастера и реплики

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

Включим ведение бинарных логов (дополнительно к relay-бинлогам) в конфиге в секции [mysqld]:
log-bin = /var/lib/mysql/mysql-bin

И добавим пользователя для ведения репликации:
mysql@master> GRANT replication slave ON ’testdb’.* TO ’replication’@’192.168.1.101′ IDENTIFIED BY «password «;

Пассивный мастер ведет репликацию как и обычная реплика, но кроме этого создает бинарные логии — то есть, мы можем начать репликацию с него. Убедимся в этом командой «show master status «:
mysql@replica> SHOW MASTER STATUS\G
File: mysql-bin.000001
Position: 61
Binlog_Do_DB:
Binlog_Ignore_DB:

Теперь, чтобы перевести пассивный мастер в активный режим, необходимо остановить репликацию на нем и включить репликацию на бывшем активном мастере. Чтобы в момент переключения данные не были утеряны, активный мастер необходимо заблокировать на запись.
mysql@master> FLUSH TABLES WITH READ LOCK
mysql@master> SET GLOBAL read_only = ON;
mysql@replica> STOP SLAVE;
mysql@replica> SHOW MASTER STATUS;
File: mysql-bin.000001
Position: 61
mysql@master> CHANGE MASTER TO MASTER_HOST = «192.168.1.102 «, MASTER_USER = «replication «, MASTER_PASSWORD = «password «, MASTER_LOG_FILE = «mysql-bin.000001 «, MASTER_LOG_POS = 61;
mysql@master> start slave;
Все, так мы поменяли активный мастер. Можно снять с бывшего мастера блокировку.

Заключение

Источник

Репликация базы данных

Применяется к: Configuration Manager (текущая ветвь)

Репликация базы данных Configuration Manager SQL Server для передачи данных. Он использует этот метод для объединения изменений в базе данных сайтов с данными из базы данных на других сайтах в иерархии.

Обратите внимание на следующие пункты репликации баз данных:

Все сайты имеют одинаковые сведения.

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

После завершения установки сайта автоматически запускается репликация базы данных.

При добавлении нового сайта в иерархию диспетчер конфигурации создает общую базу данных на новом сайте. Родительский сайт создает снимок соответствующих данных в своей базе данных. Затем снимок передается на новый сайт с помощью репликации наоснове файлов. Затем на новом сайте SQL Server программа массовой копии (BCP) для загрузки информации в локализованную копию базы данных Configuration Manager. После загрузки снимка каждый сайт проводит репликацию базы данных с другим сайтом.

Чтобы реплицировать данные между сайтами, Configuration Manager использует собственную службу репликации баз данных. Служба репликации баз данных SQL Server отслеживание изменений для отслеживания изменений в локальной базе данных сайтов. Затем он реплицирует изменения на другие сайты с помощью SQL Server Service Broker (SSB). По умолчанию этот процесс использует TCP-порт 4022.

Группы репликации

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

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

Settings

Можно изменить следующие параметры репликации баз данных:

Ссылки на репликацию баз данных: управление при переходе определенного трафика по сети.

Распределенные представления. Когда центральный сайт администрирования (CAS) запрашивает выбранные данные сайта, он может получить доступ к данным непосредственно из базы данных на начальном сайте ребенка.

Расписание. Укажите, когда используется ссылка репликации и когда реплицируется различные типы данных сайта.

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

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

Типы данных

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

Глобальные данные

Глобальные данные — это созданные администратором объекты, которые реплицируется на все сайты по всей иерархии. Вторичные сайты получают только подмножество глобальных данных, как глобальные прокси-данные. Вы создаете глобальные данные в CAS и на основных сайтах. Этот тип включает в себя следующие данные:

Данные сайта

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

Все данные сайта реплицируется в CAS. CAS занимается администрированием и отчетами для всей иерархии сайтов.

Ссылки на репликацию баз данных

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

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

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

Запланировать передачу выбранных данных сайта с основного сайта ребенка в CAS.

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

Укажите, когда нужно поднимать оповещения о сбойной ссылке репликации.

Укажите, как часто Диспетчер конфигурации суммирует данные о трафике репликации, использующем ссылку репликации. Эти данные используются в отчетах.

Чтобы настроить ссылку репликации баз данных в консоли Configuration Manager, перейдите в рабочее пространство Monitoring. Выберите узел репликации баз данных и отредактировать свойства для ссылки. Этот узел также находится в рабочей области Администрирование, в узле Конфигурация иерархии. Изменить ссылку репликации с родительского сайта или детского сайта ссылки репликации.

Вы можете изменить ссылки репликации баз данных из узла репликации баз данных в любом рабочем пространстве. Однако при использовании узла репликации баз данных в рабочей области Мониторинга можно также просмотреть состояние репликации баз данных. Он также предоставляет доступ к Replication Link Analyzer инструменту. С помощью этого средства можно исследовать проблемы с репликацией баз данных.

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

Распределенные представления

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

Распределенные представления предоставляют следующие преимущества:

Уменьшение нагрузки ЦП для обработки изменений базы данных в CAS и основных сайтах

Уменьшение объема данных, которые передается по сети в CAS

Улучшение производительности SQL Server базы данных CAS

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

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

Сайт запрашивает распределенные данные представления в следующих сценариях примера:

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

При просмотре данных на консоли Configuration Manager или в отчетах распределенные представления практически не видны. При запросе данных, включенных для распределенных представлений, сервер базы данных сайтов CAS напрямую имеет доступ к базе данных основного сайта ребенка для получения информации.

Например, вы используете консоль Configuration Manager, подключенную к CAS. Сведения о инвентаризации оборудования запрашивают на двух основных сайтах: ABC и XYZ. Вы включили инвентаризацию оборудования только для распределенных представлений на сайте ABC. Cas извлекает сведения о запасах для клиентов XYZ из собственной базы данных. Cas извлекает сведения о запасах для клиентов ABC непосредственно из базы данных на сайте ABC. Эти сведения появляются в консоли Configuration Manager или в отчете без определения источника.

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

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

Необходимые условия и ограничения для распределенных представлений

Используйте только распределенные представления на ссылках репликации между CAS и основным сайтом.

Cas должен использовать SQL Server Enterprise выпуск. У основного сайта нет этого требования.

Cas может иметь только один экземпляр поставщика SMS. Установите этот экземпляр на сервере базы данных сайта. Эта конфигурация поддерживает проверку подлинности Kerberos. Для SQL Server cas необходимо, чтобы Kerberos SQL Server на сайте начальной школы для детей. На первичном сайте ребенка нет ограничений для поставщика SMS.

В CAS можно установить только одну точку служб отчетности. Установка SQL Server Reporting Services на сервере базы данных сайта. Эта конфигурация поддерживает проверку подлинности Kerberos. Для SQL Server cas необходимо, чтобы Kerberos SQL Server на сайте начальной школы для детей.

База данных сайта не может быть в экземпляре кластера SQL Server always on failover.

Учетная запись компьютера сервера базы данных CAS требует разрешений на чтение в основной базе данных сайта.

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

Расписание передачи данных сайта

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

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

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

Сводка трафика

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

По умолчанию сводка происходит каждые 15 минут. Чтобы изменить частоту сводки для сетевого трафика, в свойствах ссылки репликации базы данных измените интервал сводки. Частота обобщения влияет на сведения, которые просматриваются в отчетах о репликации баз данных. Вы можете выбрать интервал от 5 до 60 минут. При увеличении частоты обобщения увеличивается нагрузка на обработку SQL Server на каждом сайте по ссылке репликации.

Пороги репликации баз данных

Пороги репликации баз данных определяют, когда Диспетчер конфигурации сообщает о состоянии ссылки репликации баз данных как деградировавших или неудавшихся. По умолчанию она задает ссылку как деградировавую, если одна группа репликации не выполнит репликацию в течение 12 последовательных попыток. Он задает ссылку как сбой, когда любая группа репликации не удается реплицировать в 24 последовательных попыток.

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

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

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

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

Сеть, связываемая между сайтами, имеет низкую доступную пропускную способность

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

Чтобы понять, как часто происходит репликация этой группы, рассмотрите интервал синхронизации репликации для каждой группы репликации. Чтобы просмотреть интервал синхронизации для групп репликации, перейдите в рабочее пространство Monitoring в консоли Configuration Manager. В узле репликации баз данных выберите вкладку Детализация репликации ссылки репликации.

Дополнительные сведения о том, как отслеживать репликацию баз данных, включая просмотр состояния репликации, см. в обзоре Репликация баз данных Monitor.

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

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

Можно изменить следующие элементы управления репликацией для каждой базы данных сайта:

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

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

Чтобы изменить параметры элементов управления репликацией для базы данных сайта в консоли Configuration Manager, на узле репликации баз данных, измените свойства базы данных сайта. Этот узел отображается в узле Конфигурация иерархии в рабочей области Администрирование, а также в рабочей области Мониторинга. Чтобы изменить свойства базы данных сайта, выберите ссылку репликации между сайтами, а затем откройте свойства родительской базы данных или свойства детской базы данных.

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

Источник