Configurar uma réplica em espera sem licença para o Banco de Dados SQL do Azure
Aplica-se a: 
Banco de Dados SQL do Azure
Este artigo descreve como você pode economizar nos custos de licenciamento ao designar seu banco de dados secundário de recuperação de desastres (DR) para em espera ao usar o Banco de Dados SQL do Azure.
Visão geral
Quando uma réplica de banco de dados secundário é usada apenas para recuperação de desastres e não tem cargas de trabalho em execução ou aplicativos conectados a ela, é possível economizar nos custos de licenciamento ao designar o banco de dados como uma réplica em espera. Quando um banco de dados secundário é designado como em espera, a Microsoft fornece a você o número de vCores licenciados para o banco de dados primário sem nenhum custo extra sob o benefício de direitos de failover nos termos de licenciamento do produto. Você ainda será cobrado pela computação e armazenamento usados pelo banco de dados secundário.
Você pode designar uma réplica para espera ao configurar uma nova replicação de replicação geográfica ativa ou pode converter uma réplica existente em espera.
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ário para em espera. Os grupos de failover oferecem suporte a uma réplica de banco de dados secundário por banco de dados primário, e ela pode ser legível ou em espera.
Durante o failover planejado ou não planejado, a réplica em espera torna-se a nova primária e começa a incorrer nos custos regulares de licenciamento de vCores, enquanto a primária original torna-se a nova secundária em espera e para de incorrer em custos de licenciamento de vCores.
Benefício de custo
Ao designar uma réplica de banco de dados como em espera, a Microsoft não cobra pelos custos de licenciamento do SQL Server para os vCores usados pela réplica em espera. No entanto, como o banco de dados é cobrado por toda a hora, você ainda pode ser cobrado pelos custos de licenciamento por toda a hora se a mudança de estado for feita no meio da hora.
O benefício é traduzido 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 na 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 seu pool de licenças.
Por exemplo, como um cliente pré-pago, se você tiver 16 vCores atribuídos ao banco de dados secundário, um desconto de 16 vCores aparecerá em sua fatura se você designar seu banco de dados secundário apenas como em espera.
Em outro exemplo, se você tiver 16 licenças Benefício Híbrido do Azure e implantar um banco de dados com 16 vCores, depois de designar o banco de dados secundário como em espera, 16 vCores serão retornados ao pool de licenças para você usar com outras implantações do Azure SQL.
Funcionalidades funcionais
A seguinte tabela descreve as capacidades funcionais de uma réplica de banco de dados secundário em espera:
| Funcionalidade | Descrição |
|---|---|
| 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 exibições de gerenciamento dinâmico (DMVs), backups e consultas de comandos de console de banco de dados (DBCC). |
| Failover planejado | Todos os cenários de failover planejados, incluindo simulações de recuperação, relocação de bancos de dados para regiões diferentes e retorno de bancos de dados para o primário, são compatíveis com a réplica em espera. Quando o secundário alterna para o primário, ele pode atender a 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. |
| Failover não planejado | Durante um failover não planejado, depois que o secundário alterna para a função primária, ele pode atender às 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 em espera secundária e não deve ser usado para cargas de trabalho de leitura. |
| Fazer backup e restaurar | O comportamento de backup e restauração em uma réplica em espera e em uma réplica de banco de dados secundário legível é o mesmo. |
| Monitoramento | Todas as operações de monitoramento compatíveis com uma réplica secundária para leitura são compatíveis com a réplica em espera. |
A réplica de banco de dados em espera deve ser usada apenas para recuperação de desastres. A seguinte lista mostra as únicas atividades permitidas no banco de dados em espera:
- Executar operações de manutenção, como checkDB
- Conectar os aplicativos de monitoramento
- Executar simulações de recuperação de desastre
Limitações
A tabela a seguir lista os modelos de implantação suportados e sem suporte:
| Modelo de implantação | Camada de computação | Camada de serviço | Réplica em espera suportada | Hardware |
|---|---|---|---|---|
| Banco de dados individual | Provisionado | Uso Geral | Sim | Standard-series (Gen5), FSv2-Series, DC-Series |
| Banco de dados individual | Provisionado | Comercialmente Crítico | Sim | Standard-series (Gen5), DC-Series |
| Banco de dados individual | Provisionado | Hiperescala | N/D | N/D |
| Banco de dados individual | Sem servidor | Tudo | No | N/D |
| Pool elástico | Tudo | Todos | No | N/D |
Usar um banco de dados em espera possui as seguintes limitações:
- Somente uma réplica de banco de dados secundário pode ser designada como em espera.
- Não há suporte para a camada de computação sem servidor. A réplica em espera não pode ser ativada se o banco de dados primário ou secundário estiver na camada de computação sem servidor.
- Não há suporte para o modelo de compra DTU. É possível habilitar uma réplica em espera apenas para bancos de dados que usam o modelo de compra vCore.
- Não há suporte para a camada de serviço Hiperescala. Somente bancos de dados nas camadas de serviço de Uso Geral e Comercialmente Crítico podem ser designados como em 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 de grupo de failover, e devem ser atribuídos separadamente para cada banco de dados dentro do grupo de failover.
- Não há suporte para a designação de uma réplica secundária como em espera quando a réplica é uma réplica secundária de uma réplica secundária (um processo conhecido como encadeamento).
Pré-requisitos
- Uma assinatura do Azure. Caso você não tenha uma assinatura do Azure, crie uma conta gratuita do Azure antes de começar.
- Um Banco de Dados SQL do Azure provisionado com vCore primário na camada de serviço de Uso Geral ou Comercialmente Crítico em execução em hardware com suporte. Consulte o Guia de início rápido para obter uma introdução.
Configurar nova réplica para o modo em espera
Você pode designar uma réplica como em espera ao configurar um novo relacionamento de replicação geográfica ativa usando o portal do Azure, o PowerShell, a CLI do Azure ou a API REST.
Para criar um novo relacionamento de replicação geográfica ativa e designar seu banco de dados secundário para em espera no portal do Azure, siga estas etapas:
Acesse o recurso do seu 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 como em 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 a nova réplica de banco de dados em espera.
Observação
Você também pode designar seus bancos de dados para espera ao criar um grupo de failover ou adicionar bancos de dados a um grupo de failover existente no portal do Azure.
Converter réplica existente
Você pode usar o portal do Azure ou o comando Links de Replicação - Atualizar da API REST para converter uma réplica existente de uma réplica geográfica regular em uma réplica em espera ou uma réplica em espera em uma réplica geográfica regular.
Para converter uma réplica existente no portal do Azure, siga estas etapas:
- Acesse o recurso do seu banco de dados SQL no portal do Azure.
- Selecione Réplicas em Gerenciamento de dados.
- Selecione as reticências (...) para a réplica e:
- Para converter uma réplica normal em uma réplica em espera, escolha Converter para em espera. Marque a caixa ao lado de Confirmo... na janela pop-up Converter em réplica em espera e selecione Sim para salvar sua alteração e converter sua réplica.
- Para converter uma réplica em espera em uma réplica geográfica regular, escolha Converter em geográfica. Marque a caixa ao lado de Confirmo... na janela pop-up Converter em réplica geográfica e selecione Sim para salvar sua alteração e converter sua réplica.
Para converter uma réplica existente usando o comando da Links de replicação - Atualizar da REST API, designe linkType como STANDBY para uma réplica em espera ou GEO para converter uma réplica em espera existente novamente em uma réplica geográfica regular.
Visualizar direitos de licenciamento
Você pode visualizar os direitos de licenciamento de um banco de dados existente usando o portal do Azure, o PowerShell, a CLI do Azure ou a API REST.
Para verificar os direitos de licenciamento para um banco de dados existente usando o portal do Azure, siga estas etapas:
Vá para o seu banco de dados SQL no portal do Azure.
Na página de Visão geral, marque Tipo de réplica em Essentials. Um valor de
Standbyindica que seu banco de dados é uma réplica em espera, e você não é cobrado pelos custos de licença do SQL para esse banco de dados:
Remover réplica em espera
Depois que um banco de dados é designado como em espera, você não pode simplesmente remover a propriedade de em espera. Para remover uma réplica em espera, você deve interromper a replicação para encerrar o relacionamento de replicação geográfica ativa. Depois que a replicação for interrompida, seu banco de dados se torna 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, a CLI do Azure ou a API REST.
Para remover uma réplica em espera encerrando a replicação geográfica no portal do Azure, siga estas etapas:
- Vá para o seu banco de dados SQL no portal do Azure.
- Selecione Réplicas em Gerenciamento de dados.
- Selecione os pontos de reticências (...) para a Réplica em espera e selecione Parar replicação no menu pop-up. Isso interrompe a replicação, tornando seu banco de dados secundário autônomo em vez de designado como em espera e evitando custos de licenciamento.
Perguntas frequentes
Quais são as implicações de preços?
Réplicas de banco de dados secundários são cobradas por licença do SQL, recursos de computação e armazenamento para dados e backups. Quando você designa uma réplica de banco de dados para em espera, você não é cobrado pelos custos de licenciamento dos vCores usados pela réplica secundária, mas ainda é cobrado pelos custos de computação e armazenamento.
Quais são as economias aproximadas com uma réplica em espera?
Sem custos de licenciamento inclusos, uma réplica em espera pode gerar economias de cerca de 35% a 40% em comparação a uma réplica secundária padrão totalmente legível, embora a economia possa variar por região. Para obter preços precisos, use a Calculadora de Preços do Azure e escolha Réplica em espera na lista suspensa **Recuperação de Desastres.
Quantos vCores serão isentos de licença para a réplica em espera?
O mesmo número de vCores que o banco de dados primário utiliza. Configurar a réplica secundária com o mesmo número de vCores que o banco de dados primário é recomendado para um desempenho ideal de replicação geográfica.
Preciso ter uma licença do SQL Server com 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 Software Assurance ativo.
Como posso usar a réplica em espera?
As réplicas em espera destinam-se apenas a 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 execução de DMVs (Exibições de gerenciamento dinâmico), e CheckDB.
Posso atualizar minha réplica secundária para leitura existente para uma réplica em espera para economizar?
Sim, no portal do Azure, no painel Réplicas. Selecione as reticências (...) e depois a opção para Converter sua réplica.
Posso habilitar o Benefício Híbrido do Azure para a réplica em espera?
Designar uma réplica como em espera substitui o desconto do Benefício Híbrido do Azure, então não é possível modificar o modelo de licenciamento da réplica usando o portal do Azure. No entanto, caso deseje que a réplica em espera use o Benefício Híbrido do Azure no failover, você poderá usar o comando Set-AzSqlDatabase do PowerShell ou o comando az sql db update da CLI do Azure para atualizar o tipo de licença para
BasePrice(Benefício Híbrido do Azure) na réplica em espera, para ser usado quando ela 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 torna-se a nova primária, incorrendo nos custos regulares de licenciamento, enquanto a primária original torna-se a nova secundária em espera e para de incorrer em custos de licenciamento de vCores. No entanto, como a instância é cobrada por toda a hora, você ainda pode ser cobrado pelos custos de licenciamento para o novo secundário por toda a hora se a mudança de estado acontecer no meio da hora. Se o primário original (que se torna o modo em espera após o failover) estava usando o Benefício Híbrido do Azure, o desconto de licenciamento em espera prevalece sobre o Benefício Híbrido do Azure usado pelo banco de dados.
E se eu escalar verticalmente o tamanho do vCore do primário ou secundário?
Ao escalar verticalmente, é recomendado fazer primeiro no secundário e, em seguida, no primário. Embora a réplica secundária tenha um número maior de vCores do que a primária 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 verticalmente o tamanho do vCore do primário ou secundário?
Ao reduzir verticalmente, é recomendado fazer primeiro no primário e, em seguida, no secundário. Embora a réplica secundária tenha um número maior de vCores do que a primária 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 o relacionamento de replicação geográfica entre a réplica primária e a 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 passa 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.
Posso designar uma réplica para o modo de espera ao criar um novo grupo de failover ou ao adicionar bancos de dados a ele?
Sim, mas somente ao criar um novo grupo de failover ou adicionar bancos de dados a um grupo de failover existente no portal do Azure. O PowerShell e a CLI do Azure não estão disponíveis no momento.