Новое в SQL Server 2022: Контейнерные группы доступности

В этой статье мы кратко познакомимся с контейнерными (автономными в терминологии BOL) группами доступности, которые появились в SQL Server 2022. Подробно о них можно почитать в документации: Что такое автономная группа доступности?Также, можно почитать уже вышедшие статьи из других источников:

Это новая концепция обеспечения идентичности ограниченного набора системных объектов и сущностей, которой до этого очень недоставало. Администраторам баз данных приходилось «вручную» синхронизировать логины, задания агента, планы обслуживания и множество других системных сущностей, которые описывались в таблицах системных баз данных master и msdb. Теперь появился способ возложить это на SQL Server 2022, но ждать этой возможности нам пришлось 10 лет…

Итак, вот определение из документации:

Автономная группа доступности — это группа доступности Always On, которая поддерживает:

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

При создании группы нужно пометить чек-бокс что это будет контейнерная группа или добавить в команду ключевое слово: CONTAINED. Всё это подробно описано в статье: CREATE AVAILABILITY GROUP (Transact-SQL). Возможно использование параметра REUSE_SYSTEM_DATABASES - он может быть полезен при повторном создании группы, тогда можно использовать контейнерные системные базы от предыдущей попытки. Также может оказаться важным то, что в документации: ALTER AVAILABILITY GROUP (Transact-SQL) на сегодняшний день нет указаний что можно сделать из существующей группы доступности контейнерную. Придётся удалять и создавать заново.

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

Если при создании контейнерной группы всё будет сделано правильно, то в sys.availability_groups появился единица в новой колонке с именем is_contained.

Важным моментом является то, что собственные системные базы данных контейнерной группы почти полностью заменяют те метаданные, которые хранятся в метаданных экземпляров кластера. Работать и видеть системные объекты и сущности msdb можно только подключившись через прослушивателя группы, который для неё является обязательным элементом. Это касается не только первичной реплики, но и реплики для чтения, к которой идёт подключение с «ApplicationIntent=ReadOnly». В строке подключения, как и прежде, необходимо указать базу из группы доступности, а логин с паролем должны существовать в числе логинов контейнерной группы. Системная база данных tempdb будет использоваться в зависимости от того куда подключение попадёт по правилам роутинга в группе. Она не становится контейнерной, но доступна из контейнерной группы.

При подключении через прослушивателя произойдёт маленькое «чудо», многие компоненты сервера баз данных станут недоступны (например, сама группа доступности в SSMS не видна, управлять ей можно при подключении к экземплярам кластера, а многие объекты просто исчезнут как Чеширский кот – вы не увидите там, например, логины экземпляров, задания, алерты и много другое. Но исчезнет не всё, все логины из серверной роли sysadmins родительского экземпляра попадут в контейнерную базу данных master.

Ещё более чудно что, хотя не входящие в контейнерную группу базы данных внутри неё не указаны в sys.databases и потому не видны в SSMS, доступ к ним возможен по полному имени, состоящему из трех частей, или с помощью команды use.

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

Также трудности возможны, когда для включения опций используется sp_configure, которой можно что-то изменить только непосредственно на экземпляре, а не в контейнерной группе. А то, что получить данные от sp_configure в контейнерной группе тоже возможно – ещё одно маленькое чудо.

На данный момент есть ограничения в отличие от базовых групп доступности. Контейнерные группы не могут быть Распределенными группами доступности и не могут использоваться совместно с репликацией. Также не поддерживается доставка журналов, где целевая база находится в контейнерной группе доступности; такое возможно только с базой данных-источником в контейнерной группе.

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

У вас может возникнуть недоумении, поскольку системные базы контейнерной группы не полностью закрывают метаданные системных баз экземпляром, пока это «сплошное решето». Надеюсь, всё это постепенно станет стройным и понятным. А пока ещё остаётся много нелогичного или трудно объяснимого. Впрочем, как и просто необъяснённого. В документации не упомянуто, например, про то, как восстанавливать из копии контейнерные системные базы. Пока видится логичным восстанавливать их подобно пользовательским базам в группе доступности, т.е. предварительно убрав их из группы.

Ещё из непонятного, на закладке Options задачи резервного копирования в плане обслуживания стал недоступен для отключения чек-бокс «For availability databases, ignore replica priority for backup and backup on primary settings». Наверное, потому, что внутри контейнерной группы нет особого смысла его выключать, с учётом возможной смены роли.

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

Важно!

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

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

Учтите, что пишут в документации: