Partilhar via

Pré-requisitos, restrições e recomendações para grupos de disponibilidade Always On

  • Artigo

Aplica-se a: SQL Server

Este artigo descreve considerações sobre a implantação do Grupos de disponibilidade AlwaysOn, incluindo pré-requisitos, restrições e recomendações para computadores host, clusters WSFC (Cluster de Failover do Windows Server), instâncias de servidor e grupos de disponibilidade. Para cada um desses componentes, são indicadas considerações sobre segurança e as permissões exigidas, se houver.

Importante

Antes de implantar o Grupos de disponibilidade AlwaysOn, é altamente recomendável que você leia cada seção deste tópico.

Hotfixes do .NET que dão suporte a grupos de disponibilidade

Dependendo dos componentes e recursos do SQL Server usados com o Grupos de disponibilidade Always On, você poderá precisar instalar hotfixes do .NET adicionais identificados na tabela a seguir. Os hotfixes podem ser instalados em qualquer ordem.

Recurso dependente Hotfix Link
Reporting Services O hotfix para o .NET 3.5 SP1 adiciona suporte aos recursos Always On de intenção de Leitura, somente leitura e multisubnetfailover no Cliente do SQL. O hotfix precisa ser instalado em cada servidor de relatório do Reporting Services . KB 2654347: Hotfix para .NET 3.5 SP1 para adição de suporte aos recursos Always On

Lista de verificação: requisitos (sistema Windows)

Para oferecer suporte ao recurso Grupos de disponibilidade AlwaysOn , verifique se cada computador que participará de um ou mais grupos de disponibilidade atende aos seguintes requisitos básicos:

Requisito Link
Certifique-se de que o sistema não seja um controlador de domínio. Os grupos de disponibilidade não têm suporte em controladores de domínio.
Certifique-se de que cada computador esteja em execução em uma versão compatível do Windows Server Requisitos de hardware e software para:
- SQL Server 2022
- SQL Server 2019
- SQL Server 2017
- SQL Server 2016
Verifique se cada computador é um nó em um WSFC. Clustering de Failover do Windows Server com o SQL Server
Verifique se o WSFC contém nós suficientes para dar suporte às configurações de grupo de disponibilidade. Um nó de cluster pode hospedar uma réplica de um grupo de disponibilidade. O mesmo nó não pode hospedar duas réplicas do mesmo grupo de disponibilidade. O nó de cluster pode participar de vários grupos de disponibilidade, com uma réplica de cada grupo.

Pergunte aos administradores de banco de dados quantos nós de cluster são necessários para dar suporte às réplicas de disponibilidade dos grupos de disponibilidade planejados.

O que é um grupo de disponibilidade Always On?.

Importante

Verifique também se seu ambiente está corretamente configurado para a conexão a um grupo de disponibilidade. Para obter mais informações, confira Suporte de driver e conectividade de cliente para grupos de disponibilidade.

Recomendações para computadores que hospedam réplicas de disponibilidade (sistema Windows)

  • Sistemas comparáveis: para um determinado grupo de disponibilidade, todas as réplicas de disponibilidade devem ser executadas em sistemas comparáveis que possam lidar com cargas de trabalho idênticas.

  • Adaptadores de rede dedicados: para obter um melhor desempenho, use um adaptador de rede dedicado (placa de adaptador de rede) para grupos de disponibilidade Always On.

  • Espaço suficiente em disco: cada computador em que uma instância de servidor hospeda uma réplica de disponibilidade deve ter espaço em disco suficiente para todos os bancos de dados do grupo de disponibilidade. Lembre-se de que à medida que os bancos de dados primários crescem, seus bancos de dados secundários correspondentes crescem na mesma proporção.

  • Layout de disco idêntico: cada computador no qual uma instância de servidor hospeda uma réplica de disponibilidade deve ter um layout de disco idêntico (com letras e tamanhos exatos de unidade de disco) para garantir que os caminhos de arquivo para arquivos de banco de dados (mdf, ldf) sejam espelhados, evitando complicações durante a propagação e sincronização. Consulte as Restrições (bancos de dados de disponibilidade) para layouts de disco diferentes.

Permissões (sistema Windows)

Para administrar um WSFC, o usuário deve ser um administrador do sistema em cada nó de cluster.

Para obter mais informações sobre a conta usada para administrar o cluster, confira Apêndice A: Requisitos do cluster de failover.

Tarefas relacionadas (sistema Windows)

Tarefa Link
Defina o valor de HostRecordTTL. Alterar o HostRecordTTL (usando o Windows PowerShell)

Altere o HostRecordTTL (usando o PowerShell)

  1. Abra a janela do PowerShell por meio da opção Executar como Administrador.

  2. Importe o módulo FailoverClusters.

  3. Use o cmdlet Get-ClusterResource para encontrar o recurso de Nome de Rede, depois use o cmlet Set-ClusterParameter para definir o valor de HostRecordTTL , da seguinte maneira:

    Get-ClusterResource "<NetworkResourceName>" | Set-ClusterParameter HostRecordTTL <TimeInSeconds>

    O exemplo do PowerShell a seguir define o HostRecordTTL como 300 segundos para um recurso de nome de rede chamado SQL Network Name (SQL35).

    Import-Module FailoverClusters

$nameResource = "SQL Network Name (SQL35)"
Get-ClusterResource $nameResource | Set-ClusterParameter HostRecordTTL 300

    Dica

    Sempre que você abrir uma nova janela do PowerShell, deverá importar o módulo FailoverClusters .

Conteúdo relacionado (PowerShell)

Conteúdo relacionado (sistema Windows)

Pré-requisitos e restrições da Instância do SQL Server

Cada grupo de disponibilidade requer um conjunto de parceiros de failover, conhecidos como réplicas de disponibilidade, que são hospedados por instâncias do SQL Server. Uma instância de servidor específica pode ser uma instância independente ou uma instância de cluster de failover (FCI) do SQL Server.

Nesta seção:

Lista de verificação: pré-requisitos (instância de servidor)

Pré-requisito Links
O computador host deve ser um nó WSFC. As instâncias do SQL Server que hospedam as réplicas de disponibilidade de determinado grupo de disponibilidade residem em nós separados do cluster. Um grupo de disponibilidade pode temporariamente abranger dois clusters, enquanto está migrando para outro cluster. O SQL Server 2016 (13.x) introduziu grupos de disponibilidade distribuídos. Em um grupo de disponibilidade distribuído, dois grupos de disponibilidade residem em clusters diferentes. Clustering de Failover do Windows Server com o SQL Server

Clustering de Failover e Grupos de Disponibilidade Always On (SQL Server)

Grupos de disponibilidade distribuída
Se você desejar um grupo de disponibilidade para funcionar com o Kerberos:

Todas as instâncias de servidor que hospedam uma réplica de disponibilidade para o grupo de disponibilidade deve usar a mesma conta de serviço do SQL Server.

O administrador de domínio precisa registrar um Nome de entidade de serviço (SPN) manualmente com Active Directory na conta de serviço do SQL Server para o nome de rede virtual (VNN) do ouvinte de grupo de disponibilidade. Se o SPN for registrado em uma conta diferente da conta de serviço SQL Server, a autenticação falhará.

Para usar a autenticação Kerberos para a comunicação entre pontos de extremidade do AG (grupo de disponibilidade), registre manualmente os SPNs para os pontos de extremidade de espelhamento de banco de dados usados pelo AG.

Importante: se você alterar a conta de serviço SQL Server, o administrador de domínio precisará registrar de novo o SPN manualmente.		 Registrar um nome da entidade de serviço para conexões de Kerberos

Observação:

O Kerberos e os SPNs impõem a autenticação mútua. O SPN é mapeado para a conta do Windows que inicia os serviços do SQL Server. Se o SPN não estiver registrado corretamente ou se ele falhar, a camada de segurança do Windows não poderá determinar a conta associada ao SPN e a autenticação Kerberos não será utilizada.

Observação: o NTLM não tem esse requisito.
Se você pretende usar uma instância de cluster de failover (FCI) do SQL Server para hospedar uma réplica de disponibilidade, verifique se compreende as restrições de FCI e se os requisitos de FCI são atendidos. Pré-requisitos e requisitos para usar uma FCI (Instância de Cluster de Failover) do SQL Server para hospedar uma réplica de disponibilidade (mais adiante neste artigo)
Cada instância de servidor deve estar executando a mesma versão do SQL Server para participar de um Grupo de Disponibilidade. Para obter mais informações, confira a lista de edições e recursos com suporte no final desta seção.
Todas as instâncias de servidor que hospedam réplicas de disponibilidade para um grupo de disponibilidade devem usar a mesma ordenação do SQL Server. Definir ou alterar a ordenação do servidor
Habilite o recurso Grupos de disponibilidade AlwaysOn em cada instância de servidor que hospedará uma réplica de disponibilidade para qualquer grupo de disponibilidade. Em determinado computador, você pode habilitar quantas instâncias de servidor desejar para o Grupos de disponibilidade AlwaysOn , desde que tenham suporte da instalação do SQL Server . Habilitar ou desabilitar o recurso de grupo de disponibilidade Always On

Importante: caso destrua e recrie um WSFC, você deverá desabilitar e reabilitar o recurso Grupos de Disponibilidade Always On em cada instância de servidor habilitada para grupos de disponibilidade Always On no cluster original.
Cada instância de servidor exige um ponto de extremidade de espelhamento de banco de dados. Esse ponto de extremidade é compartilhado por todas as réplicas de disponibilidade, parceiros de espelhamento de banco de dados e testemunhas na instância de servidor.

Se uma instância de servidor selecionada para hospedar uma réplica de disponibilidade estiver sendo executada em uma conta de usuário de domínio e ainda não tiver um ponto de extremidade de espelhamento de banco de dados, Usar o Assistente de Grupo de Disponibilidade (SQL Server Management Studio) (ou Adicionar uma réplica ao grupo de disponibilidade Always On usando o Assistente de Grupo de Disponibilidade no Gerenciador de Servidores do SQL) poderá criar o ponto de extremidade e conceder a permissão CONNECT à conta de serviço da instância de servidor. No entanto, se o serviço SQL Server estiver sendo executado como uma conta interna, por exemplo, Sistema Local, Serviço Local ou Serviço de Rede, ou como uma conta que não pertença a um domínio, você deverá usar certificados para autenticação de ponto de extremidade, e o assistente não poderá criar um ponto de extremidade de espelhamento de banco de dados na instância de servidor. Nesse caso, é recomendável criar manualmente os pontos de extremidade de espelhamento de banco de dados antes de iniciar o assistente.

Observação de segurança: a segurança do transporte para grupos de disponibilidade Always On é a mesma do espelhamento de banco de dados.		 O ponto de extremidade de espelhamento de banco de dados (SQL Server)

Segurança do transporte – Espelhamento de banco de dados – Disponibilidade Always On
Se algum banco de dados que utilize o FILESTREAM for adicionado a um grupo de disponibilidade, verifique se o FILESTREAM está habilitado em cada instância de servidor que hospedará uma réplica de disponibilidade do grupo de disponibilidade. Habilitar e configurar o FILESTREAM
Se algum banco de dados independente for adicionado a um grupo de disponibilidade, certifique-se de que a autenticação de banco de dados independente (opção de configuração do servidor) esteja definida como 1 em cada instância de servidor que hospedará uma réplica de disponibilidade do grupo de disponibilidade. Opção de configuração do servidor contained database authentication

Opções de configuração do servidor (SQL Server)

Para obter uma lista dos recursos com suporte das edições do SQL Server no Windows, confira:

Uso de thread por grupos de disponibilidade

Grupos de disponibilidade AlwaysOn tem os seguintes requisitos para threads de trabalho:

  • Em uma instância ociosa do SQL Server, o Grupos de disponibilidade AlwaysOn não usa nenhum thread.

  • O número máximo de threads usados por grupos de disponibilidade é a configuração definida para o número máximo de threads de servidor ('máximo de threads de trabalho') menos 40.

  • As réplicas de disponibilidade hospedadas em uma determinada instância de servidor compartilham um único pool de threads no SQL Server 2019 (15.x) e em versões anteriores.

    Os threads são compartilhados sob demanda, da seguinte maneira:

    • Normalmente, há 3 a 10 threads compartilhados, mas esse número pode aumentar dependendo da carga de trabalho da réplica primária.

    • Se um determinado thread ficar ocioso por um tempo, ele será liberado novamente no pool de threads geral do SQL Server. Normalmente, um thread inativa é liberado após ~15 segundos de inatividade. No entanto, dependendo da última atividade, um thread ocioso pode ser retido por mais tempo.

    • Uma instância do SQL Server usa até 100 threads de restauração paralela para réplicas secundárias. Cada banco de dados usa até metade do número total de núcleos de CPU, mas não mais de 16 threads por banco de dados. Se o número total de threads necessários para uma única instância exceder 100, o SQL Server usará um único thread de restauração para cada banco de dados restante. Os threads de restauração serial são liberados após, aproximadamente, 15 segundos de inatividade.

  • Além disso, os grupos de disponibilidade usam threads não compartilhados, da seguinte maneira:

    • Cada réplica primária usa 1 thread de captura de log para cada banco de dados primário. Além de isso, ela usa 1 thread de envio de log para cada banco de dados secundário. Os threads de envio de log são liberados após ~15 segundos de inatividade.

    • Um backup em uma réplica secundária mantém um thread na réplica primária durante a operação de backup.

  • O SQL Server 2022 (16.x) introduziu o pool de threads de restauração paralela, que é um pool de threads em nível de instância compartilhado com todos os bancos de dados que têm trabalho de restauração. Com esse pool, o mesmo conjunto de threads pode processar os registros de log para diferentes bancos de dados ao mesmo tempo (em paralelo). No SQL Server 2019 (15.x) e em versões anteriores, o número de threads disponíveis para restauração é limitado a 100.

  • O SQL Server 2019 (15.x) apresentou a fase de restauração paralela para bancos de dados do grupo de disponibilidade com otimização de memória. No SQL Server 2016 (13.x) e no SQL Server 2017 (14.x), as tabelas baseadas em disco não usarão a fase de restauração paralela se um banco de dados em um grupo de disponibilidade também tiver otimização de memória.

Para obter mais informações, confira Always On – HADRON Learning Series: Worker Pool Usage for HADRON Enabled Databases (AlwaysOn – Série de Aprendizado do HADRON: Uso do pool de trabalho para bancos de dados habilitados para HADRON) (blog dos Engenheiros do CSS SQL Server).

Permissões (instância de servidor)

Tarefa Permissões necessárias
Criando o ponto de extremidade de espelhamento de banco de dados Requer permissão CREATE ENDPOINT ou associação na função de servidor fixa sysadmin . Também requer a permissão CONTROL ON ENDPOINT. Para obter mais informações, confira Permissões GRANT do ponto de extremidade (Transact-SQL).
Habilitando o Grupos de disponibilidade AlwaysOn Exige a associação ao grupo Administrador no computador local e o controle total no WSFC.

Tarefas relacionadas (instância de servidor)

Tarefa Artigo
Determinando se existe um ponto de extremidade de espelhamento de banco de dados sys.database_mirroring_endpoints (Transact-SQL)
Criar o ponto de extremidade de espelhamento de banco de dados (caso ainda não exista) Criar um ponto de extremidade de espelhamento de banco de dados para a Autenticação do Windows (Transact-SQL)

Usar certificados para um ponto de extremidade de Espelhamento de Banco de Dados (Transact-SQL)

Criar um ponto de extremidade de espelhamento de banco de dados para um grupo de disponibilidade usando o PowerShell
Habilitar grupos de disponibilidade Habilitar ou desabilitar o recurso de grupo de disponibilidade Always On

Conteúdo relacionado (instância de servidor)

Recomendações de conectividade de rede

É altamente recomendável usar os mesmos links de rede para a comunicação entre nós do WSFC e a comunicação entre réplicas de disponibilidade. Usar links de rede separados pode causar comportamentos inesperados se algum dos links falhar (até mesmo com intermitência).

Por exemplo, para que um grupo de disponibilidade dê suporte a failover automático, a réplica secundária que é o parceiro de failover automático deverá estar no estado SYNCHRONIZED. Se o link de rede para essa réplica secundária falhar (ainda que com intermitência), a réplica entrará no estado UNSYNCHRONIZED e não poderá começar a ressincronização até que o link seja restaurado. Se o WSFC solicitar um failover automático enquanto a réplica secundária não estiver sincronizada, o failover automático não ocorrerá.

Suporte à conectividade de cliente

Para obter informações sobre o suporte a grupos de disponibilidade Always On para conectividade de cliente, confira Suporte de driver e conectividade de cliente para grupos de disponibilidade.

Pré-requisitos e restrições para usar uma instância de cluster de failover (FCI) do SQL Server para hospedar uma réplica de disponibilidade

Nesta seção:

Restrições (FCIs)

Observação

As instâncias de cluster de failover (FCIs) são compatíveis com Volume Compartilhado Clusterizado (CSV). Para obter mais informações sobre o CSV, consulte Entendendo Volumes Compartilhados Clusterizados em um Cluster de Failover.

  • Os nós de cluster de uma FCI podem hospedar somente uma réplica de determinado grupo de disponibilidade: se você adicionar uma réplica de disponibilidade a uma FCI, os nós do WSFC, que são possíveis proprietários da FCI, não poderão hospedar outra réplica para o mesmo grupo de disponibilidade. Para evitar possíveis conflitos, é recomendável configurar os possíveis proprietários para a instância de cluster de failover. Isso evitará a possibilidade de que um único WSFC tente hospedar duas réplicas de disponibilidade para o mesmo grupo de disponibilidade.

    Além disso, cada uma das outras réplicas deve ser hospedada por uma instância do SQL Server que resida em um nó de cluster diferente no mesmo cluster de failover do Windows Server. A única exceção é que, embora tenha sido migrado para outro cluster, um grupo de disponibilidade pode temporariamente abranger dois clusters.

    Aviso

    Usando o Gerenciador de Cluster de Failover para mover uma FCI que hospeda um grupo de disponibilidade para um nó que já está hospedando uma réplica do mesmo grupo de disponibilidade pode resultar na perda da réplica do grupo de disponibilidade, impedindo que ele seja colocado online no nó de destino. Um único nó de um cluster de failover não pode hospedar mais de uma réplica do mesmo grupo de disponibilidade. Para obter mais informações sobre como isso ocorre e como recuperar, veja no blog Réplica removida inesperadamente no grupo de disponibilidade.

  • FCIs não são compatíveis com failover automático por grupos de disponibilidade: FCIs não são compatíveis com failover automático por grupos de disponibilidade; portanto, qualquer réplica de disponibilidade hospedada por uma FCI pode ser configurada apenas para failover manual.

  • Alteração do nome da rede de FCI: caso precise alterar o nome de rede de uma FCI que hospeda uma réplica de disponibilidade, você precisará remover a réplica de seu grupo de disponibilidade e, então, adicionar novamente a réplica ao grupo de disponibilidade. Você não pode remover a réplica primária; então, se estiver renomeando uma FCI que esteja hospedando a réplica primária, realize failover em uma réplica secundária e, depois, remova a réplica primária anterior e adicione-a novamente. Renomear uma FCI pode alterar a URL de seu ponto de extremidade de espelhamento de banco de dados. Ao adicionar a réplica, especifique a URL do ponto de extremidade atual.

Lista de verificação: pré-requisitos (FCIs)

Pré-requisito Link
Verifique se cada instância de cluster de failover do SQL Server (FCI) possui o armazenamento compartilhado exigido pela instalação de instância de cluster de failover do SQL Server padrão.

Tarefas relacionadas (FCIs)

Tarefa Artigo
Instalar uma FCI do SQL Server Criar uma instância de cluster de failover do Always On (instalação)
Atualização in-loco da FCI existente do SQL Server Atualizar uma instância de cluster de failover
Manutenção da FCI existente do SQL Server Adicionar ou remover nós em uma instância de cluster de failover (instalação)

Conteúdo relacionado (FCIs)

Pré-requisitos e restrições do grupo de disponibilidade

Nesta seção:

Restrições (grupos de disponibilidade)

  • As réplicas de disponibilidade devem ser hospedadas por nós diferentes de um WSFC: para um grupo de disponibilidade específico, as réplicas de disponibilidade devem ser hospedadas por instâncias de servidor executadas em diferentes nós do mesmo WSFC. A única exceção é que, embora tenha sido migrado para outro cluster, um grupo de disponibilidade pode temporariamente abranger dois clusters.

    Observação

    Cada uma das máquinas virtuais no mesmo computador físico pode hospedar uma réplica de disponibilidade para o mesmo grupo de disponibilidade, pois cada uma delas funciona como um computador separado.

  • Nome do grupo de disponibilidade exclusivo: o nome de cada grupo de disponibilidade deve ser exclusivo no WSFC. O tamanho máximo de um nome de grupo de disponibilidade é 128 caracteres.

  • Réplicas de disponibilidade: cada grupo de disponibilidade dá suporte a uma réplica primária e a até oito réplicas secundárias. Todas as réplicas podem ser executadas no modo de confirmação assíncrona ou até cinco delas podem ser executadas no modo de confirmação síncrona (uma réplica primária com duas réplicas secundárias síncronas). Cada réplica deve ter um nome de servidor exclusivo tanto no Windows quanto no SQL Server. Os nomes de servidor entre o Windows e o SQL Server devem ser correspondentes.

  • Número máximo de grupos de disponibilidade e bancos de dados de disponibilidade por computador: o número real de bancos de dados e grupos de disponibilidade que você pode colocar em um computador (VM ou físico) depende do hardware e da carga de trabalho, mas nenhum limite é imposto. A Microsoft testou até dez grupos de disponibilidade e cem bancos de dados por computador físico, mas isso não é um limite de associação. Dependendo da especificação de hardware no servidor e da carga de trabalho, é possível colocar um número maior de bancos de dados e grupos de disponibilidade em uma instância do SQL Server. Os sinais de sistemas sobrecarregados podem incluir, entre outros, esgotamento de thread de trabalho, lentidão nos tempos de resposta para exibições do sistema dos grupos de disponibilidade e nas DMVs e despejos de sistema do dispatcher parados. Não se esqueça de testar completamente seu ambiente com uma carga de trabalho semelhante à de produção para assegurar que ele possa manipular a capacidade da carga de trabalho de pico nos SLAs do seu aplicativo. Ao considerar SLAs, não se esqueça de considerar a carga sob condições de falha, bem como os tempos de resposta esperados.

  • Não use o Gerenciador de Cluster de Failover para manipular grupos de disponibilidade. O estado de uma FCI do SQL Server é compartilhado entre o SQL Server e o cluster de failover do Windows Server (WSFC), com o SQL Server mantendo informações de estado mais detalhadas sobre as instâncias do que com as quais o cluster se preocupa. O modelo de gerenciamento é que o SQL Server deve orientar as transações e é responsável por manter a exibição do estado do cluster em sincronia com a exibição do estado do SQL Server. Se o estado do cluster for alterado fora do SQL Server, é possível que o estado saia da sincronização entre o WSFC e o SQL Server, o que poderá levar a um comportamento imprevisível.

    Por exemplo:

    • Não altere nenhuma propriedade de grupo de disponibilidade, como os possíveis proprietários.

    • Não use o Gerenciador de Cluster de Failover para executar failover de grupos de disponibilidade. Você deve usar o Transact-SQL ou o SQL Server Management Studio.

  • Não adicione recursos nem altere dependências associadas à função de grupo de disponibilidade. Não recomendamos colocar recursos adicionais (incluindo usuário ou terceiros) na função de grupo de disponibilidade nem alterar as dependências de função, pois essas alterações podem afetar negativamente o desempenho de failover.

Pré-requisitos (grupos de disponibilidade)

Ao criar ou reconfigurar uma configuração de grupo de disponibilidade, cumpra os requisitos a seguir.

Pré-requisito Descrição
Se você pretende usar uma instância de cluster de failover (FCI) do SQL Server para hospedar uma réplica de disponibilidade, verifique se compreende as restrições de FCI e se os requisitos de FCI são atendidos. Pré-requisitos e restrições do uso de uma instância de cluster de failover (FCI) do SQL Server para hospedar uma réplica de disponibilidade (anteriormente neste artigo)

Segurança (grupos de disponibilidade)

  • A segurança é herdada do WSFC. O clustering de failover do Windows Server fornece dois níveis de segurança do usuário na granularidade de todo o cluster:

    • Acesso somente leitura

    • Controle total

      O Grupos de disponibilidade AlwaysOn precisa de controle total; a habilitação do Grupos de disponibilidade AlwaysOn em uma instância do SQL Server concede a ela controle total do cluster (por meio do SID de Serviço).

      Não é possível adicionar nem remover diretamente a segurança de uma instância de servidor no Gerenciador de Cluster. Para gerenciar sessões de segurança de cluster, use o SQL Server Configuration Manager ou o WMI equivalente no SQL Server.

  • Cada instância do SQL Server deve ter permissões para acessar o Registro, o cluster e assim sucessivamente.

  • É recomendável que você use a criptografia para conexões entre instâncias de servidor que hospedam réplicas de disponibilidade do Grupos de disponibilidade AlwaysOn .

Permissões (grupos de disponibilidade)

Tarefa Permissões necessárias
Criando um grupo de disponibilidade Requer a associação na função de servidor fixa sysadmin e a permissão de servidor CREATE AVAILABILITY GROUP, a permissão ALTER ANY AVAILABILITY GROUP ou a permissão CONTROL SERVER.
Alterando um grupo de disponibilidade Requer a permissão ALTER AVAILABILITY GROUP no grupo de disponibilidade, a permissão CONTROL AVAILABILITY GROUP, a permissão ALTER ANY AVAILABILITY GROUP ou a permissão CONTROL SERVER.

Além disso, unir um banco de dados a um grupo de disponibilidade exige a associação na função de banco de dados fixa db_owner .
Descartando/excluindo um grupo de disponibilidade Requer a permissão ALTER AVAILABILITY GROUP no grupo de disponibilidade, a permissão CONTROL AVAILABILITY GROUP, a permissão ALTER ANY AVAILABILITY GROUP ou a permissão CONTROL SERVER. Para descartar um grupo de disponibilidade não hospedado na localização de réplica local, você precisará da permissão CONTROL SERVER ou CONTROL nesse grupo de disponibilidade.

Tarefas relacionadas (grupos de disponibilidade)

Tarefa Artigo
Criando um grupo de disponibilidade Usar a caixa de diálogo Assistente de Grupo de Disponibilidade (SQL Server Management Studio)

Criar um grupo de disponibilidade Always On usando o Transact-SQL (T-SQL)

Criar um grupo de disponibilidade Always On usando o PowerShell

Especificar a URL de ponto de extremidade – Adicionar ou modificar uma réplica de disponibilidade
Modificando o número de réplicas de disponibilidade Adicionar uma réplica secundária a um Grupo de Disponibilidade Always On

Ingressar uma réplica secundária em um grupo de disponibilidade Always On

Remover uma réplica secundária de um grupo de disponibilidade (SQL Server)
Criando um ouvinte do grupo de disponibilidade Configurar um ouvinte para um grupo de disponibilidade Always On
Descartando um grupo de disponibilidade Remover um grupo de disponibilidade (SQL Server)

Pré-requisitos e restrições do banco de dados de disponibilidade

Para ser qualificado para ser adicionado a um grupo de disponibilidade, um banco de dados precisa atender aos pré-requisitos e restrições a seguir.

Nesta seção:

Lista de verificação: requisitos (bancos de dados de disponibilidade)

Para estar qualificado para ser adicionado a um grupo de disponibilidade, um banco de dados deve ter as seguintes condições:

Requisitos Link
Ser um banco de dados de usuário. Os bancos de dados do sistema não podem pertencer a um grupo de disponibilidade.
Residir na instância do SQL Server em que você cria o grupo de disponibilidade e ser acessível à instância de servidor.
Ser um banco de dados de leitura/gravação. Os bancos de dados somente leitura não podem ser adicionados a um grupo de disponibilidade. sys.databases (is_read_only = 0)
Ser um banco de dados de vários usuários. sys.databases (user_access = 0)
Não usar AUTO_CLOSE. sys.databases (is_auto_close_on = 0)
Usar o modelo de recuperação completa. sys.databases (recovery_model = 1)
Ter pelo menos um backup de banco de dados completo.

Observação: após definir um banco de dados para um modelo de recuperação completa, um backup completo será necessário para iniciar a cadeia de log de recuperação completa.		 Criar um backup de banco de dados completo
Não pertencer a um grupo de disponibilidade existente. sys.databases (group_database_id = NULL)
Não ser configurado para espelhamento de banco de dados. sys.database_mirroring (se o banco de dados não participar do espelhamento, todas as colunas prefixadas com "mirroring_" serão NULL.)
Antes de adicionar um banco de dados que usa o FILESTREAM a um grupo de disponibilidade, verifique se o FILESTREAM está habilitado em cada instância de servidor que hospeda ou hospedará uma réplica de disponibilidade do grupo de disponibilidade. Habilitar e configurar o FILESTREAM
Antes de adicionar um banco de dados independente a um grupo de disponibilidade, verifique se a opção de servidor contained database authentication está definida como 1 em cada instância de servidor que hospeda ou hospedará uma réplica de disponibilidade do grupo de disponibilidade. Opção de configuração do servidor contained database authentication

Opções de configuração do servidor (SQL Server)

Observação

O Grupos de disponibilidade AlwaysOn funciona com qualquer nível de compatibilidade de banco de dados com suporte.

Restrições (bancos de dados de disponibilidade)

  • Se o caminho do arquivo (incluindo a letra da unidade) de um banco de dados secundário diferir do caminho do banco de dados primário correspondente, as seguintes restrições se aplicarão:

  • Você não pode remover um banco de dados que pertence atualmente a um grupo de disponibilidade.

Acompanhamento para bancos de dados protegidos com TDE

Se você usar criptografia de dados transparente (TDE), o certificado ou a chave assimétrica para criação e descriptografia de outras chaves deverá ser igual em todas as instância de servidor que hospedam uma réplica de disponibilidade para o grupo de disponibilidade. Para obter mais informações, veja Mover um banco de dados protegido por TDE para outro SQL Server.

Permissões (bancos de dados de disponibilidade)

Requer a permissão ALTER no banco de dados.

Tarefas relacionadas (bancos de dados de disponibilidade)

Tarefa Artigo
Preparando um banco de dados secundário (manualmente) Preparar um banco de dados secundário para um Grupo de Disponibilidade Always On
Unindo um banco de dados secundário ao grupo de disponibilidade (manualmente) Unir um banco de dados secundário com um Grupo de Disponibilidade Always On
Modificando o número de bancos de dados de disponibilidade Adicione um banco de dados a um grupo de disponibilidade Always On

Remover um banco de dados primário de um grupo de disponibilidade (SQL Server)

Remover um banco de dados primário de um grupo de disponibilidade Always On

Conteúdo relacionado