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 contidos.

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, em um AG contido, você pode criar usuários, logins, permissões e assim por diante, no nível AG, e eles são automaticamente consistentes entre réplicas no AG, bem como consistentes entre bancos 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.

Bancos de dados contidos do sistema

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 você adiciona um objeto, como um login ou trabalho de agente enquanto estiver conectado ao AG contido, quando o AG contido faz failover para outra instância, conectando-se ao AG contido, você ainda vê os trabalhos do agente e pode autenticar usando o login criado no AG contido.

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 contidos do sistema dentro do contexto do AG contido, conectando-se diretamente ao banco de dados ou usando o ponto de extremidade do ouvinte. 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.

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).

Conectar (ambiente contido)

É 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 você se conectar a uma das instâncias hospedar o AG contido em vez de diretamente ao AG contido por meio do ouvinte, você 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 você está conectado à instância por meio do ouvinte AG contido, quando interage com master, na verdade é redirecionado para o banco de dados master contido (por exemplo, MyContainedAG_master).

Roteamento de só leitura e grupos de disponibilidade contidos

Se você configurar o roteamento somente leitura para redirecionar conexões com intenção de leitura para uma réplica secundária (consulte Configurar roteamento somente leitura para um grupo de disponibilidade Always On) e desejar se conectar usando um login criado somente no AG contido, 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 mais 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 determinados recursos com AGs contidos, e há alguns recursos que não são suportados no momento.

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, mesclagem, instantâneo e assim por diante).
• 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.

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 ouvinte AG ao configurar o CDC para que os metadados CDC sejam configurados usando os bancos de dados contidos do sistema.

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 em um 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 de 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.

Pacotes SSIS &, planos de manutenção

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

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.

REUSE_SYSTEM_DATABASES

Esta opção só é válida para AGs contidas e especifica que a AG recém-criada deve reutilizar bancos de dados de sistema contidos existentes para 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 sys.availability_groups catálogo tem a coluna adicionada: is_contained

Conteúdo relacionado

• CRIAR GRUPO DE DISPONIBILIDADE (Transact-SQL)