Репликация, отслеживание изменений, изменение данных и группы доступности AlwaysOn (SQL Server)

Статья
02/18/2014

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

В этом разделе:

Обзор репликации в группах доступности AlwaysOn
- Перенаправление издателя
- Изменения в агентах репликации для поддержки групп доступности AlwaysOn
- Хранимые процедуры поддержки AlwaysOn
- Система отслеживания измененных данных
- Отслеживание изменений
Предварительные условия, ограничения и предложения для использования репликации в сочетании с группами доступности AlwaysOn
Связанные задачи

Обзор репликации в группах доступности AlwaysOn

Перенаправление издателя

Если опубликованная база данных умеет работать в режиме Группы доступности AlwaysOn, то распространитель, который предоставляет агенту доступ к базе данных публикации, настраивается с помощью записей redirected_publishers. Эти записи перенаправляют первоначально настроенные пары «издатель-база данных», позволяя при соединении издателя с базой данных публикации указывать имя прослушивателя группы доступности. Соединения, установленные по именам прослушивателей группы доступности, будут разорваны при отработке отказа. Но после перезапуска агента репликации и отработки отказа соединение будет автоматически перенаправлено на новую базу данных-источник.

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

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

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

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

(в начало)

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

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

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

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

(в начало)

Изменения в агенте чтения журнала

В агент чтения журналов внесены следующие изменения.

Согласованность реплицированной базы данных

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

Если у издателя есть только две реплики доступности в состоянии AlwaysOn (одна первичная и одна вторичная) и происходит отработка отказа, то изначальная первичная реплика останется в отключенном состоянии, так как модуль чтения журналов не продвинется вперед до тех пор, пока все базы данных-получатели не будут вновь в сети или отказавшие вторичные реплики не будут удалены из группы доступности. Модуль чтения журналов, работающий теперь со вторичной базой данных, не будет продвигаться вперед, так как состояние AlwaysOn не может фиксировать изменения в базе данных-получателе. Чтобы позволить модулю чтения журналов продвинуться вперед и сохранить возможность аварийного восстановления, удалите изначальную первичную реплику из группы доступности с помощью инструкции ALTER AVAILABITY GROUP <имя_группы> REMOVE REPLICA. Затем добавьте новую вторичную реплику к группе доступности.
Флаг трассировки 1448

Флаг трассировки 1448 разрешает средству чтения журнала репликации перемещаться вперед даже в том случае, если асинхронные вторичные реплики не подтвердили получение изменения. Средство чтения журнала всегда ожидает синхронные вторичные реплики, даже если установлен флаг трассировки. Средство чтения журнала не будет превышать минимальное время ожидания для синхронных вторичных реплик. Флаг трассировки применяется к экземпляру SQL Server, а не только к группе доступности, базе данных доступности или экземпляру средства чтения журнала. Этот флаг трассировки вступает в силу немедленно, без перезагрузки. Он не может быть активирован раньше времени или при сбое асинхронной вторичной реплики.

(в начало)

Хранимые процедуры поддержки AlwaysOn

sp_redirect_publisher

Хранимая процедура sp_redirect_publisher служит для указания перенаправленного издателя для существующей пары «база данных-издатель». Если база данных издателя входит в группу доступности, то перенаправленный издатель — это имя прослушивателя группы доступности.
sp_get_redirected_publisher

Хранимая процедура sp_get_redirected_publisher используется агентами репликации для опроса распространителя и определения наличия для пары «издатель-база данных» заданного перенаправленного издателя. Эта хранимая процедура служит двум целям. Во-первых, она позволяет агенту определить, был ли перенаправлен исходный издатель. Во-вторых, она может также инициировать вызов хранимой процедуры проверки на распространителе (sp_validate_redirected_publisher), которая выполняет проверку пригодности целевого узла перенаправления для использования в качестве издателя указанной базы данных.

Для выполнения этой хранимой процедуры необходимо членство в роли сервера sysadmin, роли базы данных db_owner распространителя или в списке доступа к публикации для конкретной публикации, связанной с базой данных издателя.
sp_validate_redirected_publisher

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

В то время как для агентов полезно убедиться в том, что текущая база данных-источник может функционировать в качестве издателя репликации для базы данных издателя, для установки действительности всей топологии репликации в базе данных доступности AlwaysOn. Хранимая процедура sp_validate_replica_hosts_as_publishers предназначена для выполнения этой задачи.

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

(в начало)

Система отслеживания измененных данных

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

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

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

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

В следующем примере создается задание отслеживания.
```
EXEC sys.sp_cdc_add_job @job_type = 'capture';
```
Система отслеживания измененных данных с репликацией

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

Очистка системы отслеживания измененных данных

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

EXEC sys.sp_cdc_add_job @job_type = 'cleanup';

Примечание
Рекомендуется создавать задания для всех возможных целей отработки отказа и отключить их, пока одна из реплик доступности на узле не станет новой первичной репликой. Задания CDC, запущенные в старой базе данных-источнике, также должны быть отключены, когда локальная база данных становится базой данных-получателем. Для включения и отключения заданий пользуйтесь параметром @enabled метода sp_update_job (Transact-SQL). Дополнительные сведения о создании заданий CDC см. в разделе sys.sp_cdc_add_job (Transact-SQL).

Рекомендуется создавать задания для всех возможных целей отработки отказа и отключить их, пока одна из реплик доступности на узле не станет новой первичной репликой. Задания CDC, запущенные в старой базе данных-источнике, также должны быть отключены, когда локальная база данных становится базой данных-получателем. Для включения и отключения заданий пользуйтесь параметром @enabled метода sp_update_job (Transact-SQL). Дополнительные сведения о создании заданий CDC см. в разделе sys.sp_cdc_add_job (Transact-SQL).

Добавление ролей CDC для первичной реплики базы данных AlwaysOn

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

Клиентские приложения, использующие информацию об изменениях CDC и режим Always On

Клиентским приложениям, которые вызывают функции с табличными значениями или обращаются к связанным серверам, для доступа к данным таблицы изменений также необходима возможность обнаружения соответствующего CDC-хоста после отработки отказа. Имя прослушивателя группы доступности — это предусмотренный в Группы доступности AlwaysOn механизм для прозрачного разрешения перенаправления соединения на другой узел. Как только имя прослушивателя группы доступности связано с группой доступности, оно становится доступным для строк подключения TCP. Через имя прослушивателя группы доступности поддерживаются два разных сценария соединений.

Один гарантирует, чтобы запросы на соединение всегда направлялись на активную первичную реплику.
Второй — чтобы запросы на соединение направлялись на вторичную реплику только для чтения.

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

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

Воспользуйтесь следующим запросом, чтобы определить, было ли имя прослушивателя группы доступности определено для размещения CDC-базы данных группой доступности. Запрос возвращает имя прослушивателя группы доступности, если оно уже создано.

SELECT dns_name 
FROM sys.availability_group_listeners AS l
INNER JOIN sys.availability_databases_cluster AS d
    ON l.group_id = d.group_id
WHERE d.database_name = N'MyCDCDB';

Перенаправление нагрузки по запросам на вторичные реплики для чтения

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

Во время настройки группы доступности атрибут ALLOW_CONNECTIONS, связанный с SECONDARY_ROLE, используется для указания типа поддерживаемого вторичного доступа. При настройке с параметром ALL все соединения с получателем будут разрешены, но только соединения с доступом только для чтения будут завершаться успешно. При настройке с параметром READ_ONLY необходимо указать цель только для чтения при соединении с базой данных-получателем, чтобы соединение завершилось успешно. Дополнительные сведения см. в разделе Настройка доступа только для чтения в реплике доступности (SQL Server).

Чтобы определить, требуется ли намерение только для чтения для подключения к вторичной реплике, доступной для чтения, воспользуйтесь следующим запросом.
```
SELECT g.name AS AG, replica_server_name, secondary_role_allow_connections_desc
FROM sys.availability_replicas AS r
JOIN sys.availability_groups AS g
    ON r.group_id = g.group_id
WHERE g.name = N'MY_AG_NAME;
```
Для поиска вторичной реплики можно использовать имя прослушивателя группы доступности или явное имя узла. Если используется имя прослушивателя группы доступности, то доступ будет перенаправлен любой подходящей вторичной реплике.

При использовании параметра sp_addlinkedserver для создания связанного сервера и доступа к получателю в параметре @datasrc указывается имя прослушивателя группы доступности или явное имя сервера, а в параметре @provstr — намерение только для чтения.
```
EXEC sp_addlinkedserver 
@server = N'linked_svr', 
@srvproduct=N'SqlServer',
@provider=N'SQLNCLI11', 
@datasrc=N'AG_Listener_Name', 
@provstr=N'ApplicationIntent=ReadOnly', 
@catalog=N'MY_DB_NAME';
```
Клиентский доступ к информации об изменениях CDC и доменным именам входа

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

(в начало)

Отслеживание изменений

Базы данных с включенной функцией отслеживания изменений могут быть частью группы доступности AlwaysOn. Требуется дополнительная настройка. Клиентские приложения по отслеживанию изменений, использующие функции с табличными значениями (возвращающие табличное значение функции) или связанные серверы, для доступа к данным таблицы изменений также требуют возможность обнаружения первичной реплики после отработки отказа. Если клиентское приложение подключается посредством имени прослушивателя группы доступности, запросы на соединение всегда направляются на текущую первичную реплику.

Примечание
Данные отслеживания изменений должны получаться из первичной реплики. Попытка доступа к информации об изменениях из вторичной реплики приведет к следующей ошибке. Сообщение 22117, уровень 16, состояние 1, строка 1 Для баз данных, которые являются членами вторичной реплики (то есть баз данных-получателей), отслеживание изменений не поддерживается. Запускайте запросы отслеживания изменений для баз данных в первичной реплике.

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

Сообщение 22117, уровень 16, состояние 1, строка 1

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

(в начало)

Условия, ограничения и вопросы использования репликации

В этом разделе описаны вопросы развертывания репликации при помощи Группы доступности AlwaysOn, в том числе предварительные условия, ограничения и рекомендации.

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

При использовании репликации транзакций и публикации базы данных в группе доступности издатель и распространитель должны иметь версию не ниже SQL Server 2012. Подписчик может использовать версию SQL Server более низкого уровня.
При использовании репликации слиянием и публикации базы данных в группе доступности:
- Принудительная подписка: издатель и распространитель должны иметь версию не ниже SQL Server 2012.
- Подписка по запросу: базы данных издателя, распространителя и подписчика должны иметь версию не ниже SQL Server 2012. Связано это с тем, что агент слияния на подписчике должен иметь сведения о том, как группа доступности может выполнить отработку отказа на вторичный узел.
Размещение базы данных распространителя в группе доступности не поддерживается.
Экземпляры издателя должны удовлетворять всем предварительным условиям, необходимым для участия в группе доступности AlwaysOn. Дополнительные сведения см. в разделе предварительными требованиями, и ограничениями и рекомендациями для групп доступности AlwaysOn (SQL Server).

Ограничения

Поддерживаемые сочетания репликации в Группы доступности AlwaysOn:

	Издатель	Распространитель3	Подписчик
Транзакционная	Да1	Нет	Да2
P2P	Нет	Нет	Нет
Объединить	Да	Нет	Да2
Моментальный снимок	Да	Нет	Да2

1 Не включает поддержку двунаправленной и возвратно-поступательной репликации транзакций.

2 Отработка отказа реплики базы данных выполняется вручную. Автоматический переход на другой ресурс не предоставляется.

3 База данных распространителя не поддерживается для использования с Группы доступности AlwaysOn или с зеркальным отображением базы данных.

(в начало)

Замечания

База данных распространителя не поддерживается в сочетании с Группы доступности AlwaysOn или с зеркальным отображением базы данных. Конфигурация репликации работает совместно с экземпляром SQL Server, на котором настроен распространитель. Именно по этой причине база данных распространителя не может участвовать в репликации или зеркальном отображении. Чтобы обеспечить высокий уровень доступности для распространителя, используйте отказоустойчивый кластер SQL Server. Дополнительные сведения см. в разделе Экземпляры отказоустойчивого кластера (режим AlwaysOn) (SQL Server).
Отработка отказа подписчика на базу данных-получателя — сравнительно сложная процедура, выполняемая вручную. Процедура, по существу, идентична методу, используемому для переключения на зеркальную базу данных подписчика. Чтобы подписчики могли участвовать в группе доступности, они должны использовать SQL Server 2012 или более позднюю версию.
Метаданные и объекты, которые существуют за пределами базы данных, не распространяются на вторичные реплики. Это касается имен входа, заданий, связанных серверов и так далее. Если после отработки отказа в базе данных-источнике нужны метаданные и объекты, их необходимо скопировать вручную. Дополнительные сведения см. в разделе Управление именами входа и заданиями для баз данных группы доступности (SQL Server).

(в начало)