Что такое изолированная группа доступности?

Статья
2025-04-01

Область применения: SQL Server 2022 (16.x)

Содержащаяся группа доступности — это группа доступности AlwaysOn, которая поддерживает:

управление объектами метаданных (пользователями, именами входа, разрешениями, заданиями агента SQL и т. д.) на уровне группы доступности в дополнение к уровню экземпляра.
специализированные изолированные системные базы данных в группе доступности AG.

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

Обзор

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

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

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

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

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

Различия

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

Автономные системные базы данных

Каждая группа доступности включает собственные master и msdb системные базы данных, названные по имени этой группы доступности. Например, в ограниченной группе доступности MyContainedAG есть базы данных с именем MyContainedAG_master и MyContainedAG_msdb. Эти системные базы данных автоматически заполняются новыми репликами, а обновления реплицируются в эти базы данных точно так же, как и в любую другую базу данных в группе доступности. Это означает, что при добавлении объекта, например имени входа или задания агента при подключении к автономной группе доступности, при отработке отказа автономной группы доступности на другой экземпляр, подключении к автономной группе доступности вы по-прежнему видите задания агента и сможете пройти проверку подлинности с помощью имени входа, созданного в автономной группе доступности.

Внимание

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

Системные базы данных в новой созданной изолированной группе доступности не копируются из экземпляра, в котором выполняется команда CREATE AVAILABILITY GROUP. Изначально они являются пустыми шаблонами без каких-либо данных. Сразу после создания учетные записи администратора на экземпляре, создающем содержащую группу доступности, копируются в эту группу доступности master. Таким образом администратор может войти в контейнерную группу доступности и настроить остальную конфигурацию.

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

Заметка

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

Восстановление автономной системной базы данных

Вы можете восстановить содержащуюся системную базу данных с помощью одного из двух разных способов.

Восстановление автономной базы данных с помощью вторичной реплики:
1. Восстановите содержащиеся master и msdb базы данных на экземпляр сервера, на котором размещается вторичная реплика, используя RESTORE WITH NORECOVERY для каждой операции восстановления. Для получения дополнительной информации см. Подготовьте вторичную базу данных для группы доступности Always On.
2. Присоедините каждую содержимую базу данных к группе доступности. Дополнительные сведения см. в разделе Присоединение вторичной базы данных к группе доступности Always On.
Восстановление автономной базы данных путем удаления автономной группы доступности:
1. Удалите содержащуюся AG.
2. Восстановите содержащие master и msdb базы данных в каждом из узлов, участвующих в изолированной группе доступности.
3. Повторно создайте содержащийся AG (группа доступности) с использованием исходных узлов и имен, применяя синтаксис WITH (CONTAINED, REUSE_SYSTEM_DATABASES).

Задания изолированной группы доступности

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

Подключение (изолированная среда)

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

"Persist Security Info=False;
User ID=MyUser;Password=*****;
Initial Catalog=MyContainedDatabase;
Server=MyServer;"

Где MyContainedDatabase находится база данных в автономной группе доступности, с которой вы хотите взаимодействовать.

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

Например, если ваша группа доступности MyContainedAG размещена на сервере SERVER\MSSQLSERVER, и вместо того чтобы подключаться к прослушивателю MyContainedAG_Listener, вы подключаетесь к экземпляру SERVER\MSSQLSERVER, то вы находитесь в среде экземпляра, а не в среде MyContainedAG. Это означает, что вы подчиняетесь содержимому (пользователям, разрешениям, заданиям и т. д.), находящемуся в системных базах данных этого экземпляра. Чтобы получить доступ к содержимому, содержащемуся в системных базах данных, входящих в состав содержащей группы доступности, подключитесь к прослушивателю содержащей группы доступности (MyContainedAG_Listener, например). При подключении к экземпляру через прослушиватель автономной группы доступности при взаимодействии masterвы фактически перенаправляетесь в содержащуюся master базу данных (например, MyContainedAG_master).

Маршрутизация только для чтения и изолированные группы доступности

Если вы настраиваете маршрутизацию только для чтения для перенаправления подключений с намерением чтения на вторичную реплику (см. раздел "Настройка маршрутизации только для чтения для группы доступности Always On") и вы хотите подключиться, используя логин, созданный только в специализированной группе доступности, учтите некоторые дополнительные рекомендации.

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

Например, в следующей строке подключения AdventureWorks — это база данных в автономной группе доступности, у которой есть MyContainedListener, и где MyUser — пользователь, определенный в автономной группе доступности, а не в одном из участвующих экземпляров.

"Persist Security Info=False;
User ID=MyUser;Password=*****;
Initial Catalog=AdventureWorks;
Server=MyContainedListener;
ApplicationIntent=ReadOnly"

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

Различия между подключением к экземпляру и подключением к автономной группе доступности

При подключении к автономной группе доступности пользователи видят только базы данных в автономной группе доступности, а также tempdb.
На уровне экземпляра находятся имена master и msdb, а также [contained AG]_master и [contained AG]_msdb. Внутри контейнерной ГД, их имена master и msdb.
Идентификатор базы данных для автономной группы доступности находится master внутри автономной группы доступности1, но что-то другое при подключении к экземпляру.
Хотя пользователи не видят базы данных за пределами содержащейся группы доступности sys.databases при подключении к содержащейся группе доступности, они могут получить доступ к этим базам данных по трехуровневому имени или с помощью команды USE.
Конфигурацию сервера через sp_configure можно считывать из содержащегося подключения AG, но записывать только с уровня экземпляра.
Из подключений, содержащихся в группе доступности, системный администратор может выполнять операции на уровне экземпляра, такие как остановка SQL Server.
Большинство операций на уровне базы данных, на уровне конечной точки или на уровне группы доступности могут выполняться только из подключений экземпляров, а не из подключений, связанных с группами доступности.

Взаимодействие с другими функциями

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

Резервное копирование

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

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

Если расположение резервного копирования находится в сетевом ресурсе, все серверы, на которых размещаются реплики, нуждаются в доступе к такому ресурсу.

Регулятор ресурсов

В SQL Server 2022 (16.x) до накопительного обновления 18 и в более ранних версиях SQL Server настройка или использование регулятора ресурсов для подключений к автономной группе доступности не поддерживается.

Начиная с кумулятивного обновления 18 для SQL Server 2022 (16.x), если вы настраиваете регулятор ресурсов для подключения экземпляра, потребление ресурсов для подключений к экземплярам или подключениям внутри группы доступности регулируется должным образом. Если вы пытаетесь настроить регулятор ресурсов для подключения к автономной группе доступности, появится сообщение об ошибке.

Регулятор ресурсов работает на уровне экземпляра ядра СУБД. Конфигурация регулятора ресурсов на уровне экземпляра не распространяется на реплики доступности. Необходимо настроить регулятор ресурсов на каждом экземпляре с репликой доступности.

Подсказка

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

Дополнительные сведения см. в регулятора ресурсов и примеры конфигурации регулятора ресурсов и рекомендации.

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

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

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

доставка журналов;

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

Чтобы настроить доставку журналов с помощью встроенной группы доступности (contained AG), выполните следующие действия.

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

Прозрачное шифрование данных (TDE)

Чтобы использовать прозрачное шифрование данных (TDE) с базами данных в автономной группе доступности, вручную установите главный ключ базы данных (DMK) в содержащуюся базу данных master в этой автономной группе доступности.

Базы данных, использующие TDE, применяют сертификаты в базе данных master для расшифровки ключа шифрования базы данных (DEK). Без этого сертификата SQL Server не может расшифровывать базы данных, зашифрованные с помощью TDE, или использовать их в сети. Для расшифровки базы данных в контейнированной группе доступности SQL Server проверяет обе master базы данных на наличие DMK, master базу данных для экземпляра и содержащуюся master базу данных в контейнированной группе доступности. Если сертификат не удается найти в любом расположении, SQL Server не сможет подключить базу данных в режим "в сети".

"Чтобы перенести DMK из базы данных master экземпляра в содержащуюся в ней базу данных master, обратитесь к статье «Перемещение защищенной базы данных TDE в другой SQL Server», уделяя главное внимание частям, где DMK передаётся со старого сервера на новый."

Заметка

Шифрование любой базы данных в экземпляре SQL Server также шифрует системную tempdb базу данных.

Пакеты SSIS и планы обслуживания

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

Не поддерживается

В настоящее время следующие функции SQL Server не поддерживаются в автономной группе доступности:

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

Изменения DDL

Единственные изменения в DDL находятся в рабочем процессе CREATE AVAILABILITY GROUP. Существует два новых WITH положения.

<with_option_spec> ::=
CONTAINED |
REUSE_SYSTEM_DATABASES

СОДЕРЖИМОЕ

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

ПОВТОРНОЕ ИСПОЛЬЗОВАНИЕ СИСТЕМНЫХ БАЗ ДАННЫХ (REUSE_SYSTEM_DATABASES)

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

Изменения в Департаменте транспортных средств

Существует два дополнения к динамическим представлениям, связанным с содержащимися AG:

DmV sys.dm_exec_sessions содержит добавленный столбец: contained_availability_group_id
В sys.availability_groups представлении каталога есть добавленный столбец: is_contained

СОЗДАНИЕ ГРУППЫ ДОСТУПНОСТИ (Transact-SQL)