O que é um grupo de disponibilidade contido?

Aplica-se a: SQL Server 2022 (16.x)

Um grupo de disponibilidade contido é um grupo de disponibilidade Always On (AG) que suporta:

• gerenciando objetos de metadados (usuários, logons, permissões, trabalhos do SQL Agent e assim por diante) no nível AG, além do nível da instância.

• bases de dados especializadas contidas em sistemas dentro da AG.

Este artigo detalha as semelhanças, diferenças e funcionalidades dos AGs confinados.

Visão geral

Os AGs geralmente consistem em um ou mais bancos de dados de usuários destinados a operar como um grupo coordenado e que são replicados em algum número de nós em um cluster. Quando há uma falha no nó ou na integridade do SQL Server no nó que hospeda a cópia primária, o grupo de bancos de dados é movido como uma unidade para outro nó de réplica no AG. Todos os bancos de dados de usuários são mantidos sincronizados em todas as réplicas do AG, no modo síncrono ou assíncrono.

Isso funciona bem para aplicativos que interagem apenas com esse conjunto de bancos de dados de usuários, mas há desafios quando os aplicativos também dependem de objetos como usuários, logins, permissões, trabalhos de agente, etc., que são armazenados em um dos bancos de dados do sistema (master ou msdb). Para que os aplicativos funcionem de forma suave e previsível, o administrador deve manualmente garantir que qualquer alteração nesses objetos seja duplicada em todas as instâncias de réplica no AG. Se uma nova instância for trazida para o AG, os bancos de dados poderão ser propagados automática ou manualmente em um processo simples, mas todas as personalizações do banco de dados do sistema deverão ser reconfiguradas na nova instância para corresponder às outras réplicas.

As AGs contidas alargam o conceito dos grupos de bases de dados que estão a ser replicadas para incluir partes relevantes das bases de dados master e msdb. Pense nisso como o contexto de execução para aplicativos que usam o AG contido. A ideia é que o ambiente AG contido inclua configurações que afetariam o aplicativo que depende delas. Como tal, o ambiente AG contido diz respeito a todos os bancos de dados com os quais o aplicativo interage, a autenticação que ele usa (logins, usuários, permissões), quaisquer trabalhos agendados que ele espera estar executando e outras definições de configuração que afetam o aplicativo.

Isso é diferente dos bancos de dados contidos, que usam um mecanismo diferente para as contas de usuário, armazenando as informações do usuário dentro do próprio banco de dados. Os bancos de dados contidos apenas replicam logons e usuários, e o escopo do login ou usuário replicado é limitado a esse único banco de dados (e suas réplicas).

Por outro lado, num AG contido, é possível criar usuários, logins, permissões e assim por diante, ao nível AG, e eles são automaticamente consistentes entre réplicas no AG, assim como consistentes entre bases de dados dentro desse AG contido. Isso evita que o administrador tenha que fazer essas alterações manualmente.

Diferenças

Há algumas diferenças práticas a considerar ao trabalhar com Grupos de Disponibilidade contidos, tais como a criação de bases de dados de sistema contidas e forçar a conexão ao nível do Grupo de Disponibilidade contido, em vez de se conectar ao nível de instância.

Bases de dados do sistema contidas

Cada AG contido tem os seus próprios bancos de dados de sistema master e msdb, denominados após o nome do grupo de disponibilidade. Por exemplo, no AG MyContainedAGcontido, tem bancos de dados denominados MyContainedAG_master e MyContainedAG_msdb. Esses bancos de dados do sistema são automaticamente propagados para novas réplicas e as atualizações são replicadas para esses bancos de dados como qualquer outro banco de dados em um grupo de disponibilidade. Isso significa que, quando se adiciona um objeto, como um login ou uma tarefa do agente, enquanto está conectado ao AG contido, e este faz failover para outra instância, ao conectar-se novamente ao AG contido, ainda é possível ver as tarefas do agente e autenticar-se usando o login criado no AG contido.

Importante

Os agrupamentos de disponibilidade contidos são um mecanismo para assegurar consistência nas configurações do ambiente de execução nas réplicas de um grupo de disponibilidade. Eles não representam um limite de segurança. Não há nenhuma fronteira que impeça uma ligação a um AG interno de aceder a bases de dados fora do AG, por exemplo.

Os bancos de dados do sistema num Grupo de Disponibilidade contido recém-criado não são cópias da instância onde o comando CREATE AVAILABILITY GROUP é executado. Inicialmente, são modelos vazios sem quaisquer dados. Imediatamente após a criação, as contas de administrador na instância que cria o AG contido são copiadas para o AG contido master. Dessa forma, o administrador pode fazer login no AG contido e configurar o restante da configuração.

Se você criar usuários ou configurações locais em sua instância, eles não aparecerão automaticamente quando você criar os bancos de dados do sistema contidos e não ficarão visíveis quando você se conectar ao AG contido. Uma vez que o banco de dados de usuários tenha sido unido a um AG contido, ele se tornará imediatamente inacessível para esses usuários. Você precisa recriá-los manualmente nos bancos de dados do sistema contidos dentro do contexto do AG contido, conectando-se diretamente ao banco de dados ou usando o endpoint do listener. A exceção é que todos os logins na função sysadmin na instância principal são copiados para a nova base de dados específica do AG master.

Observação

Como o banco de dados master é separado para cada grupo de disponibilidade contido, as atividades de escopo do servidor executadas no contexto do AG contido são mantidas apenas no banco de dados do sistema contido. Isso inclui auditoria. Se auditas a atividade ao nível do servidor com a Auditoria do SQL Server, deves criar as mesmas auditorias de servidor em cada Grupo de Disponibilidade contido.

Restaurar um banco de dados do sistema contido

Você pode restaurar um banco de dados do sistema contido usando uma das duas maneiras diferentes.

• Restaurar um banco de dados contido usando uma réplica secundária:

  1. Restaure os bancos de dados master e msdb contidos em uma instância de servidor que hospeda a réplica secundária, usando RESTORE WITH NORECOVERY para cada operação de restauração. Para mais informações, consulte Preparar uma base de dados secundária para um grupo de disponibilidade Always On.

  2. Junte cada banco de dados contido ao grupo de disponibilidade. Para obter mais informações, consulte associar um banco de dados secundário a um grupo de disponibilidade Always On.

• Restaure um banco de dados contido descartando oAG contido :

  1. Solte o AG contido.

  2. Restaure o banco de dados contido master e o banco de dados msdb em cada uma das instâncias que participam do AG contido.

  3. Recrie o AG contido usando os nós e o nome originais, usando a sintaxe WITH (CONTAINED, REUSE_SYSTEM_DATABASES).

Trabalhos de grupos de disponibilidade contida

Os trabalhos que pertencem a um grupo de disponibilidade contido são executados apenas na réplica primária. Eles não são executados em réplicas secundárias.

Conectar (ambiente fechado)

É importante distinguir a diferença entre conectar-se à instância e conectar-se ao AG contido. A única maneira de aceder ao ambiente do AG contido é conectar-se ao listener do AG contido ou conectar-se a uma base de dados que está no AG contido.

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

Onde MyContainedDatabase é um banco de dados dentro do AG contido com o qual você deseja interagir.

Isso significa que é necessário criar um ouvinte para o AG contido, a fim de utilizar eficazmente um AG contido. Se se ligar a uma das instâncias que hospedam o AG contido em vez de diretamente ao AG contido através do 'listener', estará no ambiente da instância e não no AG contido.

Por exemplo, se o grupo de disponibilidade MyContainedAG está hospedado no servidor SERVER\MSSQLSERVERe, em vez de se conectar ao listener MyContainedAG_Listener, se conectar à instância usando SERVER\MSSQLSERVER, estará no ambiente da instância e não no ambiente de MyContainedAG. Isso significa que você está sujeito aos conteúdos (usuários, permissões, trabalhos, etc.) encontrados nos bancos de dados do sistema da instância. Para aceder ao conteúdo encontrado nas bases de dados do sistema de um AG contido, ligue-se ao listener do AG contido (por exemplo,MyContainedAG_Listener). Quando o utilizador está conectado à instância através do agente AG contido e interage com master, é redirecionado para o banco de dados master contido (por exemplo, MyContainedAG_master).

Roteamento de só leitura e grupos de disponibilidade contidos

Se configurar o roteamento de leitura apenas para redirecionar conexões com intenção de leitura para uma réplica secundária (consulte Configurar o roteamento de leitura apenas para um grupo de disponibilidade Always On) e quiser conectar-se usando um login criado apenas no próprio AG, há algumas considerações adicionais:

• Você deve especificar um banco de dados que faça parte do AG incluído na string de conexão.
• O utilizador especificado na cadeia de conexão deve ter permissão para acessar os bancos de dados nos AG contidos.

Por exemplo, na seguinte cadeia de ligação, onde AdventureWorks é uma base de dados dentro do AG contido que tem MyContainedListenere onde MyUser é um utilizador definido no AG contido e em nenhuma das instâncias participantes:

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

Essa cadeia de conexão conectaria você ao secundário legível que faz parte da configuração de Roteamento Somente Leitura e você estaria dentro do contexto do AG contido.

Diferenças entre conectar-se à instância e conectar-se ao grupo de disponibilidade contido

• Quando conectados a um AG contido, os usuários só veem bancos de dados no AG contido e tempdb.
• Ao nível da instância, os nomes dos AG contidos master e msdb são [contained AG]_mastere [contained AG]_msdb. Dentro do AG contido, seus nomes são master e msdb.
• O ID do banco de dados para o AG contido master é 1 quando visto de dentro do próprio AG contido, mas algo diferente ao se conectar à instância.
• Embora os usuários não vejam bancos de dados fora do AG contido em sys.databases quando conectados em uma conexão AG contida, eles podem acessar esses bancos de dados por nome de três partes ou por meio do comando USE.
• A configuração do servidor através do sp_configure pode ser lida a partir da conexão AG contida, mas só pode ser gravada a partir do nível da instância.
• A partir de conexões AG contidas, o sysadmin é capaz de executar operações no nível da instância, como desligar o SQL Server.
• A maioria das operações ao nível de banco de dados, ponto de extremidade ou nível AG só pode ser executada a partir de conexões de instância, e não de conexões AG contidas.

Interações com outros recursos

Há considerações adicionais ao usar certas funcionalidades com AGs contidos, e há algumas funcionalidades que atualmente não são suportadas.

Fazer uma cópia de segurança

Os procedimentos para fazer backup de bancos de dados em um AG contido são os mesmos que qualquer procedimento de backup de banco de dados de usuário. Isso é verdade tanto para os bancos de dados de usuários AG contidos quanto para os bancos de dados contidos do sistema AG.

Se o local de backup for local, os arquivos de backup serão colocados no servidor que executa o trabalho de backup. Isso significa que seus arquivos de backup podem estar em locais diferentes.

Se o local de backup estiver em um recurso de rede, todos os servidores que hospedam réplicas precisarão acessar esse recurso.

Administrador de recursos

No SQL Server 2022 (16.x) antes da Atualização Cumulativa 18 e em versões mais antigas do SQL Server, não há suporte para configurar ou usar o administrador de recursos em conexões de grupo de disponibilidade contidas.

A partir da Atualização Cumulativa 18 do SQL Server 2022 (16.x), se você configurar o administrador de recursos em uma conexão de instância, o consumo de recursos em conexões de instância ou conexões de grupo de disponibilidade contidas será regido conforme o esperado. Se você tentar configurar o administrador de recursos em uma conexão de grupo de disponibilidade contida, receberá um erro.

O administrador de recursos funciona no nível da instância do Mecanismo de Banco de Dados. A configuração do administrador de recursos no nível da instância não se propaga para réplicas disponíveis. Você deve configurar o administrador de recursos em cada instância que hospeda uma réplica de disponibilidade.

Sugestão

Recomendamos que você use a mesma configuração do administrador de recursos para todas as instâncias do Mecanismo de Banco de Dados que hospedam réplicas de disponibilidade para garantir um comportamento consistente à medida que ocorrem failovers do grupo de disponibilidade.

Para obter mais informações, consulte Governador de Recursos e Exemplos de configuração e práticas recomendadas do Governador de Recursos.

Alterar a captura de dados

A captura de dados de alteração (CDC) é implementada como tarefas do SQL Agent, portanto, o SQL Agent precisa estar em execução em todas as instâncias com réplicas na AG contida.

Para usar a captura de dados de alteração com um AG contido, conecte-se ao listener do AG ao configurar o CDC, para que os metadados do CDC sejam configurados usando os bancos de dados do sistema contidos.

Envio de logs

O envio de logs pode ser configurado se o banco de dados de origem estiver no AG contido. No entanto, um destino de envio de logs não é suportado num AG contido. Além disso, há uma etapa extra para modificar o trabalho de envio de logs após a configuração do CDC.

Para configurar o envio de logs com um AG contido, siga estas etapas:

1. Conecte-se ao ouvinte AG contido.
2. Configure envio de logs como faria normalmente.
3. Depois que o trabalho de envio de logs for configurado, altere-o para se conectar ao ouvinte AG contido antes de fazer um backup.

Criptografia de dados transparente (TDE)

Para usar a criptografia de dados transparente (TDE) com bases de dados num AG contido, instale manualmente a chave mestra do banco de dados (DMK) na base de dados contida master dentro do AG contido.

Os bancos de dados que usam TDE dependem de certificados no banco de dados master para descriptografar a DEK (Chave de Criptografia de Banco de Dados). Sem esse certificado, o SQL Server não pode descriptografar bancos de dados criptografados com TDE ou colocá-los online. Em um AG contido, o SQL Server verifica os bancos de dados master para o DMK, o banco de dados master para a instância e o banco de dados master contido dentro do AG contido para descriptografar o banco de dados. Se não conseguir localizar o certificado em nenhum dos locais, o SQL Server não conseguirá colocar o banco de dados online.

Para transferir o DMK do banco de dados master da instância para o banco de dados master contido, consulte Mover um banco de dados protegido por TDE para outro SQL Server, concentrando-se principalmente nas partes em que o DMK é transferido do servidor antigo para o novo.

Observação

A criptografia de qualquer banco de dados em uma instância do SQL Server também criptografa o banco de dados do tempdb sistema.

Pacotes SSIS &, planos de manutenção

O uso de pacotes SSIS, incluindo planos de manutenção, não é suportado com grupos de disponibilidade contidos.

Não suportado

Atualmente, os seguintes recursos do SQL Server não são suportados com um AG contido:

• Replicação do SQL Server de qualquer tipo (transacional, fusão, instantâneo, etc.).
• Grupos de disponibilidade distribuídos.
• Envio de logs onde o banco de dados de destino está no AG contido. O envio de logs com o banco de dados de origem no AG contido é suportado.

Alterações de DDL

As únicas alterações na DDL estão no fluxo de trabalho CREATE AVAILABILITY GROUP. Existem duas novas cláusulas WITH:

<with_option_spec> ::=
CONTAINED |
REUSE_SYSTEM_DATABASES

CONTIDO

Isto especifica que a AG que está a ser criada deve ser uma AG contida.

REUTILIZAR_BANCOS_DE_DADOS_DO_SISTEMA

Esta opção só é válida para AGs contidas e especifica que a AG recém-criada deve reutilizar os bancos de dados de sistema existentes de uma AG contida anterior com o mesmo nome. Por exemplo, se tivesses um AG contido com o nome MyContainedAGe quisesses removê-lo e recriá-lo, poderias usar esta opção para reutilizar o conteúdo dos bancos de dados originalmente contidos no sistema.

Alterações no Departamento de Veículos Motorizados

Existem duas novidades nos DMVs relacionadas aos grupos de disponibilidade contidos:

• O DMV sys.dm_exec_sessions teve uma coluna adicionada: contained_availability_group_id
• A visualização do catálogo sys.availability_groups tem a coluna adicionada: is_contained

Conteúdo relacionado

• CRIAR GRUPO DE DISPONIBILIDADE (Transact-SQL)