Configurar uma réplica em espera sem licença (visualização) para o Banco de Dados SQL do Azure

Artigo
01/29/2024

Aplica-se a:Banco de Dados SQL do Azure

Este artigo descreve como você pode economizar nos custos de licenciamento designando seu banco de dados secundário de recuperação de desastres (DR) para espera ao usar o Banco de Dados SQL do Azure.

Nota

As réplicas do Banco de Dados SQL do Azure em espera estão atualmente em visualização.

Descrição geral

Quando uma réplica de banco de dados secundária é usada apenas para recuperação de desastres e não tem nenhuma carga de trabalho em execução ou aplicativos se conectando a ela, você pode economizar nos custos de licenciamento designando o banco de dados como uma réplica em espera. Quando um banco de dados secundário é designado para espera, a Microsoft fornece o número de vCores licenciados para o banco de dados primário sem custo adicional sob o benefício de direitos de failover nos termos de licenciamento do produto. Você ainda é cobrado pela computação e armazenamento que o banco de dados secundário usa.

Você designa uma réplica para espera ao configurar uma nova replicação de replicação geográfica ativa. Em seguida, opcionalmente, você pode adicionar a réplica a um grupo de failover.

Embora a replicação geográfica ativa ofereça suporte à adição de quatro réplicas secundárias, você só pode designar uma réplica de banco de dados secundária para espera. Os grupos de failover oferecem suporte a uma réplica de banco de dados secundária por banco de dados primário e podem ser legíveis ou em espera.

Durante o failover planejado ou não planejado, a réplica em espera se torna a nova primária e começa a incorrer em custos regulares de licenciamento vCore, enquanto a primária original se torna a nova secundária em espera e para de incorrer em custos de licenciamento vCore.

Para saber mais, assista a este vídeo do Data Exposed:

Custo-benefício

Quando você designa uma réplica de banco de dados como espera, a Microsoft não cobra custos de licenciamento do SQL Server pelos vCores usados pela réplica em espera. No entanto, como o banco de dados é cobrado por toda a hora, ainda poderão ser cobrados custos de licenciamento para a hora inteira se a alteração de estado for feita no meio da hora.

O benefício se traduz de forma diferente entre os clientes que usam o modelo de pagamento conforme o uso e os clientes que usam o modelo de Benefício Híbrido do Azure. Para um cliente pré-pago, os vCores são descontados em sua fatura. Para um cliente que usa o Benefício Híbrido do Azure para a réplica em espera, o número de vCores que a réplica secundária usa é retornado ao pool de licenciamento.

Por exemplo, como um cliente pré-pago, se você tiver 16 vCores atribuídos ao banco de dados secundário, um desconto para 16 vCores aparecerá em sua fatura se você designar seu banco de dados secundário como somente em espera.

Em outro exemplo, se você tiver 16 licenças do Benefício Híbrido do Azure e implantar um banco de dados com 16 vCores, depois de designar o banco de dados secundário para espera, 16 vCores serão retornados ao seu pool de licenças para você usar com outras implantações SQL do Azure.

Capacidades funcionais

A tabela a seguir descreve os recursos funcionais de uma réplica de banco de dados secundário em espera:

Funcionalidade	Description
Cargas de trabalho de leitura limitadas	Depois de designar seu banco de dados como em espera, você pode executar apenas um número limitado de cargas de trabalho de leitura no banco de dados secundário, como DMVs (Exibições de Gerenciamento Dinâmico), backups e consultas DBCC (Database Console Commands).
Ativação pós-falha planeada	Todos os cenários de ativação pós-falha planeados, incluindo testes de recuperação, reposicionamento das bases de dados em diferentes regiões e devolução das bases de dados às principais, são suportados pela réplica de reserva. Quando o secundário muda para o primário, ele pode servir consultas de leitura e gravação. O novo secundário (o primário original) torna-se a réplica em espera e não deve ser usado para cargas de trabalho de leitura.
Ativação pós-falha não planeada	Durante um failover não planejado, depois que o secundário muda para a função principal, ele pode servir consultas de leitura e gravação. Depois que a interrupção é atenuada e o primário original se reconecta, ele se torna a nova réplica secundária em espera e não deve ser usado para cargas de trabalho de leitura.
Cópia de segurança e restauro	O comportamento de backup e restauração em uma réplica em espera e em uma réplica de banco de dados secundária legível são os mesmos.
Monitorização	Todas as operações de monitorização suportadas por uma réplica secundária legível são suportadas pela réplica de reserva.

A réplica do banco de dados em espera só deve ser usada para recuperação de desastres. Nenhum aplicativo de produção pode ser conectado à réplica. A seguir estão listadas as únicas atividades permitidas no banco de dados em espera:

Executar operações de manutenção, como checkDB
Ligar aplicações de monitorização
Executar exercícios de recuperação de desastres

Limitações

A tabela a seguir lista os modelos de implantação com e sem suporte:

Modelo de implementação	Escalão de computação	Escalão de serviço	Réplica em espera suportada	Hardware
Base de dados individual	Aprovisionado	Fins Gerais	Sim	Série padrão (Gen5), série FSv2, série DC
Base de dados individual	Aprovisionado	Crítico para a Empresa	Sim	Série padrão (Gen5), série DC
Base de dados individual	Aprovisionado	Hyperscale	No	N/A
Base de dados individual	Sem servidor	Todas as	No	N/A
Conjunto elástico	Todos	Todos	No	N/A

O uso de um banco de dados em espera tem as seguintes limitações:

Você só pode designar um banco de dados para espera ao estabelecer uma nova relação de replicação geográfica ativa. Os bancos de dados com relações de replicação geográfica ativa existentes ou em grupos de failover existentes não podem ser designados para espera.
Apenas uma réplica de banco de dados secundária pode ser designada para espera.
A camada de computação sem servidor não é suportada. A réplica em espera não poderá ser habilitada se o banco de dados primário ou secundário estiver na camada de computação sem servidor.
O modelo de compra DTU não é suportado. Você pode habilitar uma réplica em espera para bancos de dados usando apenas o modelo de compra vCore.
A camada de serviço Hyperscale não é suportada. Somente os bancos de dados nas camadas de serviço de uso geral e de negócios críticos podem ser designados para espera.
Ao usar um grupo de failover, os direitos de espera são atribuídos no nível do banco de dados, não no nível do grupo de failover, e devem ser atribuídos separadamente para cada banco de dados dentro do grupo de failover.
Não há suporte para designar uma réplica secundária para espera quando a réplica é uma réplica secundária de uma réplica secundária (um processo conhecido é encadeamento).

Pré-requisitos

Uma subscrição do Azure. Se não tiver uma subscrição do Azure, crie uma conta gratuita do Azure antes de começar.
Um banco de dados SQL do Azure vCore provisionado primário na camada de serviço de uso geral ou de negócios críticos em execução em hardware suportado . Reveja o Guia de início rápido para começar.

Configurar uma réplica em espera

Você pode designar uma réplica para espera ao configurar uma nova relação de replicação geográfica ativa usando o portal do Azure, o PowerShell ou a CLI do Azure.

Para criar uma nova relação de replicação geográfica ativa e designar seu banco de dados secundário para espera no portal do Azure, siga estas etapas:

Vá para seu recurso de banco de dados SQL no portal do Azure.
Escolha Réplicas em Gerenciamento de dados no menu de recursos e selecione + Criar réplica para abrir a página Criar Banco de Dados SQL - Réplica Geográfica.
Na página Criar Banco de Dados SQL - Réplica Geográfica, selecione Réplica em espera para Tipo de réplica em Configuração de réplica. Marque a caixa para confirmar que você usará a réplica para espera.
Forneça um servidor novo ou existente para o novo banco de dados em espera e, em seguida, use Revisar + criar para fazer uma validação final do banco de dados e dos detalhes do servidor.
Use Criar para confirmar suas configurações e criar sua nova réplica de banco de dados em espera.

Para criar uma nova relação de replicação geográfica ativa e designar seu banco de dados secundário para espera com o PowerShell, use New-AzSqlDatabaseSecondary e especifique SecondaryType como Standby, como o seguinte script de exemplo:

$StandbyReplica = @{
   ResourceGroupName = "<PrimaryResourceGroup>"
   ServerName = "<PrimaryServerName>"
   DatabaseName = "<PrimaryDatabaseName>"
   PartnerResourceGroup = "<SecondaryResourceGroup>"
   PartnerServerName = "<SecondaryServerName>"
   PartnerDatabaseName = "<SecondaryDatabaseName>"
   SecondaryType = Standby
}

New-AzSqlDatabaseSecondary @StandByReplica

Para criar uma nova relação de replicação geográfica ativa e designar seu banco de dados secundário para espera com a CLI do Azure, use az sql db replica create e especifique secondary-type como Standby, como o seguinte script de exemplo:

az sql db replica create --resource-group  <PrimaryResourceGroup> --server <PrimaryServerName> \
   --name <PrimaryDatabaseName> --partner-resource-group <SecondaryResourceGroup> \
   --partner-server <SecondaryServerName> --secondary-type Standby

Adicionar a um grupo de failover (opcional)

Depois que seu relacionamento de replicação geográfica ativo tiver sido estabelecido para sua nova réplica de banco de dados em espera, você poderá optar por adicioná-lo a um grupo de failover. Para obter mais informações, consulte Configurar grupos de failover.

Ver direitos de licenciamento

Você pode exibir os direitos de licenciamento de um banco de dados existente usando o portal do Azure, o PowerShell e a CLI do Azure.

Para verificar os direitos de licenciamento de um banco de dados existente usando o portal do Azure, siga estas etapas:

Vá para seu banco de dados SQL no portal do Azure.
Na página Visão geral, marque Tipo de réplica em Essenciais. Um valor de indica que seu banco de dados é uma réplica em espera e que você não é cobrado pelos custos de licenciamento SQL para esse banco de Standby dados:

Remover réplica em espera

Depois que um banco de dados é designado como standby, você não pode simplesmente remover a propriedade standby. Para remover uma réplica em espera, você deve interromper a replicação para encerrar a relação de replicação geográfica ativa. Depois que a replicação parar, seu banco de dados se tornará autônomo e você começará a incorrer em custos de licenciamento.

Você pode interromper a replicação geográfica usando o portal do Azure, o PowerShell e a CLI do Azure.

Para remover uma réplica em espera terminando a replicação geográfica no portal do Azure, siga estas etapas:

Vá para seu banco de dados SQL no portal do Azure.
Selecione Réplicas em Gerenciamento de dados.
Selecione as reticências (...) para a réplica em espera e, em seguida, selecione Parar replicação no menu pop-up. Isso interrompe a replicação para que seu banco de dados secundário agora seja autônomo em vez de designado para espera e incorra em custos de licenciamento.

Perguntas mais frequentes (FAQ)

Quais são as implicações em termos de preços?

As réplicas de banco de dados secundárias são cobradas pelo licenciamento, computação e armazenamento SQL para dados e backups. Quando você designa uma réplica de banco de dados para espera, não é cobrado pelos custos de licenciamento dos vCores usados pela réplica secundária, mas ainda é cobrado pela computação e armazenamento.
Quais são as economias aproximadas com uma réplica em espera?

Sem custos de licenciamento, uma réplica em espera pode economizar entre 35% e 40% em comparação com uma réplica secundária normal totalmente legível, embora as economias variem de acordo com a região. Para obter preços precisos, use a Calculadora de Preços do Azure e defina a licença do SQL Server como Benefício Híbrido do Azure.
Quantos vCores estarão livres de licença para a réplica em espera?

O mesmo número de vCores que o banco de dados primário usa. A configuração da réplica secundária com o mesmo número de vCores que o banco de dados primário é recomendada para um desempenho ideal de replicação geográfica.
Preciso ter uma licença do SQL Server com o Software Assurance ativo para usar uma réplica em espera?

Não Como a réplica em espera não incorre em custos de licenciamento, você não precisa de uma licença ativa do SQL Server com o Software Assurance ativo.
Como posso usar a réplica em espera?

As réplicas em espera destinam-se apenas para fins de recuperação de desastres (DR) e não podem ter cargas de trabalho de leitura ativas. As únicas cargas de trabalho aceitáveis são para monitoramento, manutenção, como a execução de DMVs (Dynamic Management Views) e CheckDB.
Posso atualizar minha réplica secundária legível existente para uma réplica em espera para economizar custos?

Não Apenas novas réplicas podem ser designadas como standby. Não há suporte para a atualização de réplicas existentes. No entanto, você pode criar uma nova réplica em espera designada para espera e, em seguida, excluir a réplica geosecundária existente para economizar custos.
Posso habilitar o Benefício Híbrido do Azure para a réplica em espera?

Designar uma réplica para espera substitui o desconto do Benefício Híbrido do Azure, portanto, você não pode modificar o modelo de licenciamento para a réplica usando o portal do Azure. No entanto, se desejar que a réplica em espera use o Benefício Híbrido do Azure após o failover, você poderá usar o comando Set-AzSqlDatabase PowerShell ou az sql db update Azure CLI para atualizar o tipo de licença para (Benefício Híbrido do Azure) para BasePrice que a réplica em espera seja usada quando a réplica em espera se tornar primária após o failover.
O que acontece com o status da réplica em espera durante o failover?

Durante o failover planejado ou não planejado, a réplica em espera se torna a nova primária incorrendo em custos regulares de licenciamento, enquanto a primária original se torna a nova secundária em espera e para de incorrer em custos de licenciamento vCore. No entanto, como a instância é cobrada por toda a hora, ainda poderão ser cobrados custos de licenciamento para o novo secundário durante toda a hora se a alteração de estado ocorrer no meio da hora. Se o primário original (que se torna o modo de espera após failover) estava usando o Benefício Híbrido do Azure, o desconto de licenciamento em espera substitui o Benefício Híbrido do Azure usado pelo banco de dados.
E se eu aumentar a escala primária ou secundária para um tamanho vCore maior?

Ao aumentar a escala, é uma prática recomendada aumentar a escala do secundário primeiro e, em seguida, do primário. Embora a réplica secundária tenha um número maior de vCores do que a principal durante o período de transição, os benefícios da réplica em espera ainda se aplicam. Tente minimizar ao máximo o período de transição.
E se eu reduzir o primário ou secundário para um tamanho vCore mais baixo?

Ao reduzir a escala, é uma prática recomendada reduzir o primário primeiro e, em seguida, o secundário. Embora a réplica secundária tenha um número maior de vCores do que a principal durante o período de transição, os benefícios da réplica em espera ainda se aplicam. Tente minimizar ao máximo o período de transição.
O que acontece se eu remover a relação de replicação geográfica entre a réplica primária e a réplica em espera?

Depois que a replicação geográfica é removida, o banco de dados em espera se torna um banco de dados autônomo regular e começa a incorrer em custos de licenciamento.
Posso obter benefícios de capacidade reservada para a réplica em espera?

Sim. O preço da capacidade reservada é totalmente compatível com a réplica em espera.

Próximos passos

Para saber mais sobre a replicação geográfica ativa, consulte Replicação geográfica ativa.
Para obter uma visão geral e cenários de continuidade de negócios, consulte Visão geral de continuidade de negócios.
Economize nos custos de licenciamento designando sua réplica de DR secundária para espera.
Para saber mais sobre grupos de failover, consulte Grupos de failover.