Ескертпе
Бұл бетке кіру үшін қатынас шегін айқындау қажет. Жүйеге кіруді немесе каталогтарды өзгертуді байқап көруге болады.
Бұл бетке кіру үшін қатынас шегін айқындау қажет. Каталогтарды өзгертуді байқап көруге болады.
Область применения: SQL Server 2022 (16.x)
Содержащаяся группа доступности — это группа доступности AlwaysOn, которая поддерживает:
управление объектами метаданных (пользователями, именами входа, разрешениями, заданиями агента SQL и т. д.) на уровне группы доступности в дополнение к уровню экземпляра.
специализированные изолированные системные базы данных в группе доступности AG.
В этой статье подробно описаны сходство, различия и функциональные возможности содержащихся групп доступности.
Обзор
Группы доступности обычно состоят из одной или нескольких пользовательских баз данных, предназначенных для работы как единое целое, которые реплицируются на некотором количестве узлов в кластере. При сбое узла или работоспособности SQL Server на узле, в котором размещена первичная копия, группа баз данных перемещается в виде единицы в другой узел реплики в группе доступности. Все пользовательские базы данных синхронизируются во всех репликах АГ в синхронном или асинхронном режиме.
Эта архитектура хорошо подходит для приложений, которые взаимодействуют только с этим набором пользовательских баз данных. Однако проблемы возникают, когда приложения также используют такие объекты, как пользователи, имена входа, разрешения, задания агента и другие объекты, хранящиеся в одной из системных баз данных (master или msdb). Чтобы обеспечить плавность и прогнозируемую работу приложений, администратор должен вручную убедиться, что любые изменения этих объектов дублируются во всех экземплярах реплик в группе доступности (AG). При добавлении нового экземпляра в группу доступности (AG) можно автоматически или вручную заполнять базы данных простым способом. Однако необходимо перенастроить все настройки системной базы данных в новом экземпляре, чтобы они соответствовали другим репликам.
Группы доступности, содержащиеся в системе, расширяют концепцию репликации групп баз данных, чтобы включить соответствующие части баз данных master и msdb. Рассматривайте это как контекст выполнения приложений, использующих содержащуюся группу доступности (AG). Идея заключается в том, что среда автономной группы доступности включает параметры, влияющие на приложение, зависящее от них. Таким образом, среда ВГ охватывает все базы данных, с которыми взаимодействует приложение, используемую аутентификацию (имена входа, пользователи, разрешения), все запланированные задания, которые должны выполняться, и другие параметры конфигурации, влияющие на приложение.
Эта концепция отличается от содержащихся баз данных, которые используют другой механизм для учетных записей пользователей, сохраняя сведения о пользователе в самой базе данных. Автономные базы данных реплицируют только имена входа и пользователей, а область реплицированного имени входа или пользователя ограничена этой отдельной базой данных (и ее репликами).
В отличие от этого, в автономной группе доступности вы создаете пользователей, имена входа, разрешения и т. д. на уровне группы доступности. Эти объекты автоматически согласованы между репликами в группе доступности, а также согласованы между базами данных в пределах указанной группы доступности. Эта согласованность избавляет администратора от необходимости вручную вносить эти изменения.
Изменения SQL Server 2025
SQL Server 2025 (17.x) предоставляет поддержку распределенной группы доступности для содержащихся групп доступности.
Различия
При работе с содержащимися AG рассмотрите некоторые практические различия. Эти различия включают создание автономных системных баз данных и принудительное подключение на уровне автономной группы доступности вместо подключения на уровне экземпляра.
Автономные системные базы данных
Каждая группа доступности включает собственные master и msdb системные базы данных, названные по имени этой группы доступности. Например, в ограниченной группе доступности MyContainedAG есть базы данных с именем MyContainedAG_master и MyContainedAG_msdb. Эти системные базы данных автоматически заполняются новыми репликами, а обновления реплицируются в эти базы данных так же, как и любая другая база данных в группе доступности. При добавлении объекта, такого как логин или задание агента, при подключении к контейнерной группе доступности вы по-прежнему видите агентные задания и можете пройти аутентификацию с помощью логина, созданного в контейнерной группе доступности, при переключении этой группы на другой экземпляр.
Внимание
Контейнерные группы доступности — это механизм обеспечения согласованности конфигураций среды выполнения во всех репликах группы доступности. Они не представляют границу безопасности. Например, нет границы, которая сохраняет подключение к автономной группе доступности от доступа к базам данных за пределами группы доступности.
Системные базы данных в новой контейнированной группе доступности не являются копиями из экземпляра, где выполняется команда CREATE AVAILABILITY GROUP. Изначально они пустые шаблоны без каких-либо данных. Сразу после создания процесс копирует администраторские учетные записи на экземпляре в содержащуюся группу доступности, создавая содержащую группу доступности master. Таким образом администратор может войти в ограниченную группу доступности и завершить настройку конфигурации.
Если вы создаете локальных пользователей или конфигурации в вашем экземпляре, они не появляются автоматически при создании системных баз данных с ограничениями и не отображаются при подключении к группе доступности с ограничениями. Когда пользовательская база данных присоединяется к автономной группе доступности, эти пользователи немедленно теряют доступ. Необходимо вручную повторно создать их в автономных системных базах данных в контексте автономной группы доступности, подключив их непосредственно к базе данных или с помощью конечной точки прослушивателя. Исключением из этого правила является то, что все имена входа в роли sysadmin в родительском экземпляре копируются в новую базу данных группы доступности master во время создания автономной группы доступности.
Заметка
master Так как база данных отделена для каждой автономной группы доступности, действия области сервера, выполняемые в контексте автономной группы доступности, сохраняются только в автономной системной базе данных. Это правило включает аудит. При проверке активности на уровне сервера с помощью функций аудита SQL Server необходимо создать идентичные аудиты сервера в каждой автономной группе доступности.
Начальная синхронизация данных
Автономные системные базы данных поддерживают только автоматическое заполнение в качестве метода начальной синхронизации данных.
В SQL Server 2022 (16.x) и более ранних версиях изолированные группы доступности должны использовать автоматическое заполнение во время создания. При использовании оператора CREATE AVAILABILITY GROUP или мастера создания новой группы доступности в SQL Server Management Studio включайте только пользовательские базы данных, поддерживающие автоматическое засевание. Чтобы добавить большие базы данных с помощью ручного заполнения (JOIN ONLY), дождитесь создания автономной группы доступности.
В SQL Server 2025 (17.x) автономные системные базы данных всегда используют автоматическое заполнение, даже если CREATE AVAILABILITY GROUP инструкция указывает заполнение вручную. Вы можете настроить режим заполнения вручную для создания автономной группы доступности, а затем добавить пользовательские базы данных с помощью методов синхронизации, отличных от автоматического заполнения.
Восстановление автономной системной базы данных
Чтобы восстановить резервные копии автономных системных баз данных, выполните следующие действия.
Удалите содержащуюся AG.
Восстановите содержащиеся
masterиmsdbбазы данных на исходной первичной реплике автономной группы доступности.Удалите содержащиеся
masterиmsdbбазы данных из вторичных реплик.В первичной реплике повторно создайте включённую группу доступности с использованием исходного имени и узлов, с использованием синтаксиса
WITH (CONTAINED, REUSE_SYSTEM_DATABASES)иSEEDING_MODE = AUTOMATIC.
В инструкции CREATE AVAILABILITY GROUP по созданию изолированной группы доступности не включайте содержащиеся системные базы данных. SQL Server автоматически обнаруживает их при указании REUSE_SYSTEM_DATABASES. В SQL Server 2022 (16.x) и более ранних версиях включены только небольшие пользовательские базы данных, поддерживающие автоматическое заполнение. Добавьте большие базы данных отдельно после создания автономной группы доступности с помощью JOIN ONLY.
Задания изолированной группы доступности
Задания, принадлежащие автономной группе доступности, выполняются только на первичной реплике. Они не выполняются на вторичных репликах.
Подключение (изолированная среда)
Важно различать разницу между подключением к экземпляру и подключением к автономной группе доступности. Единственным способом доступа к среде включенной группы доступности является подключение к прослушивателю включенной группы доступности или подключение к базе данных, находящейся в включенной группе доступности.
"Persist Security Info=False;
User ID=MyUser;Password=*****;
Initial Catalog=MyContainedDatabase;
Server=MyServer;"
Где MyContainedDatabase — это база данных в содержащей группе доступности (Availability Group), с которой вы хотите взаимодействовать.
Необходимо создать прослушиватель для автономной группы доступности, чтобы эффективно использовать содержащуюся группу доступности. Если вы подключаетесь к одному из экземпляров, в котором размещена содержащаяся автономная группа, а не непосредственно к ней с помощью прослушивателя, вы находитесь в среде экземпляра, а не этой группы.
Например, если ваша группа доступности MyContainedAG размещена на сервере SERVER\MSSQLSERVER, и вместо того чтобы подключаться к прослушивателю MyContainedAG_Listener, вы подключаетесь к экземпляру SERVER\MSSQLSERVER, то вы находитесь в среде экземпляра, а не в среде MyContainedAG. Вы подчинены содержимому (пользователям, разрешениям, заданиям и т. д.), которые находятся в системных базах данных экземпляра. Чтобы получить доступ к содержимому, содержащемуся в системных базах данных, входящих в состав содержащей группы доступности, подключитесь к прослушивателю содержащей группы доступности (MyContainedAG_Listener, например). При подключении к экземпляру через прослушиватель автономной группы доступности при взаимодействии masterвы фактически перенаправляетесь в содержащуюся master базу данных (например, MyContainedAG_master).
Маршрутизация только для чтения и изолированные группы доступности
Если вы настраиваете маршрутизацию только для чтения для перенаправления подключений с намерением чтения на вторичную реплику (см. раздел "Настройка маршрутизации только для чтения для группы доступности AlwaysOn") и вы хотите подключиться только с помощью имени входа, созданного только в автономной группе доступности, есть дополнительные рекомендации.
- Необходимо указать базу данных, которая является частью группы доступности с автономными базами данных, в строке подключения.
- Пользователь, указанный в строка подключения, должен иметь разрешение на доступ к базам данных в автономной группе доступности.
Например, в следующей строке подключения AdventureWorks является базой данных внутри "contained AG", которая включает MyContainedListener, причем MyUser — это пользователь, определенный в "contained AG" и отсутствующий во всех участвующих экземплярах.
"Persist Security Info=False;
User ID=MyUser;Password=*****;
Initial Catalog=AdventureWorks;
Server=MyContainedListener;
ApplicationIntent=ReadOnly"
В этом примере вы подключаетесь к доступной для чтения вторичной среде, которая входит в конфигурацию маршрутизации ReadOnly, и вы находитесь в контексте автономной группы доступности.
Различия между подключением к экземпляру и подключением к автономной группе доступности
- При подключении к автономной группе доступности пользователи видят только базы данных в автономной группе доступности, а также
tempdb. - На уровне экземпляра находятся имена
masterиmsdb, а также[contained AG]_masterи[contained AG]_msdb. Внутри контейнерной ГД, их именаmasterиmsdb. - Идентификатор базы данных для автономной группы доступности находится
masterвнутри автономной группы доступности1, но что-то другое при подключении к экземпляру. - Хотя пользователи не видят базы данных за пределами содержащейся группы доступности
sys.databasesпри подключении к содержащейся группе доступности, они могут получить доступ к этим базам данных по трехуровневому имени или с помощью командыUSE. - Конфигурацию сервера через
sp_configureможно считывать из содержащегося подключения AG, но записывать только с уровня экземпляра. - Из подключений, содержащихся в группе доступности, системный администратор может выполнять операции на уровне экземпляра, такие как остановка SQL Server.
- Большинство операций на уровне базы данных, на уровне конечной точки или на уровне группы доступности могут выполняться только из подключений экземпляров, а не из подключений, связанных с группами доступности.
Взаимодействие с другими функциями
Учитывайте другие факторы при использовании определённых возможностей с включенными AGs. Некоторые функции в настоящее время не поддерживаются.
Резервное копирование
Процедуры резервного копирования баз данных в автономной группе доступности совпадают с процедурами резервного копирования пользовательских баз данных. Это утверждение справедливо как для содержащихся пользовательских баз данных группы доступности, так и для содержащихся системных баз данных группы доступности.
При использовании локального расположения резервного копирования файлы резервного копирования помещаются на сервер, на котором выполняется задание резервного копирования. Это означает, что файлы резервного копирования могут находиться в разных расположениях.
Если вы используете сетевой ресурс для расположения резервного копирования, все серверы, на которых размещаются реплики, должны получить доступ к такому ресурсу.
Включение возможности создания или восстановления базы данных в сеансах контейнерной группы доступности
Применимо к: SQL Server 2025 (17.x) CU 1 и более поздних версий.
В SQL Server 2025 (17.x) Накопительный пакет обновления (CU) 1 можно включить создание и восстановление базы данных непосредственно в сеансе автономной группы доступности с помощью автономного прослушивателя группы доступности. Это улучшение упрощает рабочие процессы для пользователей, назначенных соответствующим ролям, что позволяет легко выполнять операции в ограниченных AG средах.
Только пользователи с ролью dbcreator могут создавать базы данных в автономном сеансе группы доступности. Только пользователи с ролью db_owner или sysadmin могут восстанавливать базы данных.
В следующем примере функция для сеанса включается с помощью ключа allow_cag_create_db контекста сеанса в хранимой процедуре sp_set_session_contex . Чтобы отключить его, установите для него значение @value0.
EXECUTE sp_set_session_context
@key = N'allow_cag_create_db',
@value = 1;
Распределенные группы доступности
Распределенная группа доступности — это особый тип группы доступности, которая охватывает две базовые группы доступности. При настройке распределенной группы доступности изменения, внесенные на глобальную первичную (которая является основной репликой первой группы доступности), затем реплицируются в основную реплику второй группы доступности, которая называется пересылкой.
Начиная с SQL Server 2025 (17.x), можно настроить распределенную группу доступности между двумя контейнированными группами доступности. Так как содержащаяся группа доступности зависит от содержащихся master и msdb системных баз данных, для создания распределенной группы доступности вторая группа доступности (пересылка) должна иметь ту же содержащуюся системную базу данных ГРУППЫ доступности, что и глобальную первичную базу данных.
Если вы планируете использовать содержащую группу доступности в качестве сервера пересылки в распределенной группе доступности, необходимо создать содержащую группу доступности с помощью AUTOSEEDING_SYSTEM_DATABASES предложения для WITH | CONTAINED параметра инструкции CREATE AVAILABILITY GROUP . Предложение AUTOSEEDING_SYSTEM_DATABASES сообщает SQL Server пропустить создание собственных системных баз данных группы доступности, а вместо этого семена содержащихся системных баз данных группы доступности из глобальной первичной базы данных.
Регулятор ресурсов
Область применения: SQL Server 2022 (16.x) CU 18 и более поздних версий.
В SQL Server 2022 (16.x) до накопительного обновления (CU) 18, а в более старых версиях SQL Server настройка или использование регулятора ресурсов для подключений к автономной группе доступности не поддерживается.
В SQL Server 2022 (16.x) CU 18 и более поздних версий, если вы настраиваете диспетчер ресурсов для подключения к экземпляру, потребление ресурсов для подключений к экземплярам или подключений к содержимой группе доступности регулируется должным образом. Если вы пытаетесь настроить регулятор ресурсов для подключения к автономной группе доступности, появится сообщение об ошибке.
Регулятор ресурсов работает на уровне экземпляра ядра СУБД. Конфигурация регулятора ресурсов на уровне экземпляра не распространяется на реплики доступности. Необходимо настроить регулятор ресурсов на каждом экземпляре с репликой доступности.
Подсказка
Для всех экземпляров ядра СУБД следует использовать одну и ту же конфигурацию регулятора ресурсов, где размещаются реплики доступности, чтобы обеспечить согласованное поведение при отработке отказа группы доступности.
Дополнительные сведения см. в разделе "Регулятор ресурсов " и "Руководство. Примеры конфигурации регулятора ресурсов" и рекомендации.
отслеживание изменений данных
Запись измененных данных (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
В рабочем процессе CREATE AVAILABILITY GROUP есть WITH предложение с несколькими параметрами:
<with_option_spec> ::=
CONTAINED [REUSE_SYSTEM_DATABASES | AUTOSEEDING_SYSTEM_DATABASES ]
СОДЕРЖИМОЕ
Этот параметр указывает, что группа доступности, которую вы создаете, является автономной группой доступности.
ПОВТОРНОЕ ИСПОЛЬЗОВАНИЕ СИСТЕМНЫХ БАЗ ДАННЫХ (REUSE_SYSTEM_DATABASES)
Параметр REUSE_SYSTEM_DATABASES действителен только для содержащихся групп доступности. Он указывает, что новая группа доступности должна повторно использовать существующие содержащиеся системные базы данных из предыдущей автономной группы доступности с тем же именем. Например, если у вас есть изолированная группа доступности с именем MyContainedAG, и вы хотите удалить и заново создать её, вы можете использовать этот параметр для повторного использования содержимого исходных изолированных системных баз данных. При использовании этого параметра не указывайте системные имена баз данных. SQL Server автоматически обнаруживает их.
Автонасеивание_Системные_БазыДанных
Относится к: SQL Server 2025 (17.x) и более поздним версиям.
Если вы хотите использовать вашу вложенную группу доступности в качестве пересылщика в распределенной группе доступности, необходимо воспользоваться параметром AUTOSEEDING_SYSTEM_DATABASES при создании вложенной группы доступности. Эта опция указывает SQL Server пропустить создание собственных системных баз данных встроенной группы доступности и вместо этого инициализировать содержащиеся системные базы данных группы доступности из глобальной первичной базы данных.
Поддержка объектов системы для автономных групп доступности
Два системных представления включают дополнения, связанные с содержащимися группами доступности:
-
sys.dm_exec_sessions динамическое представление управления включает столбец
contained_availability_group_id. - Представление каталога sys.availability_groups включает
is_containedстолбец.