Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Aplica-se a:
do 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.
Visã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 que se conectam 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 de produto . Você ainda é cobrado pela computação e armazenamento que o banco de dados secundário usa.
Você pode designar uma réplica para espera ao configurar uma nova replicação replicação geográfica ativa replicação, 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á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, que pode ser legível ou em espera.
Durante o failover planeado ou não planeado, a réplica em reserva torna-se 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 reserva e deixa de incorrer em custos de licenciamento vCore.
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 traduz-se 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 com pagamento sob demanda, os vCores são descontados na sua fatura. Para um cliente que utiliza o Benefício Híbrido do Azure para a réplica em espera, o número de vCores usados pela réplica secundária é devolvido ao seu pool de licenciamento.
Por exemplo: enquanto cliente "pay-as-you-go", se tiver 16 vCores atribuídos ao banco de dados secundário, um desconto para 16 vCores aparecerá na sua fatura caso designe o seu banco de dados secundário como apenas em standby.
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 | Descrição |
|---|---|
| Cargas de trabalho de leitura limitadas | Depois de designar o seu banco de dados como em espera, poderá executar apenas um número limitado de cargas de trabalho de leitura no banco de dados secundário, como Exibições de Gestão Dinâmica (DMVs), backups e consultas de Comandos da Consola de Base de Dados (DBCC). |
| Alternância planeada | Todos os cenários de failover planeados, incluindo testes de recuperação, reposicionar as bases de dados em diferentes regiões e devolver as bases de dados à original, são suportados pela réplica de reserva. Quando o secundário muda para o primário, ele pode processar consultas de leitura e escritas. 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. |
| 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 é resolvida e a réplica primária original se reconecta, ela se torna a nova réplica secundária de espera e não deve ser utilizada para operações de leitura. |
| Backup e restauração | 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 de banco de dados em espera deve apenas ser usada para recuperação após desastres. 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 | Camada de computação | Nível de serviço | Réplica em espera suportada | Equipamento |
|---|---|---|---|---|
| Base de dados única | Aprovisionado | Finalidade Geral | Sim | Série Padrão (Gen5), Série FSv2, DC-Series |
| Base de dados única | Aprovisionado | Negócios Críticos | Sim | Série padrão (Gen5), DC-Series |
| Base de dados única | Aprovisionado | Hiperescala | N/A | N/A |
| Base de dados única | Sem servidor | Todos | Não | N/A |
| Piscina elástica | Todos | Todos | Não | N/A |
O uso de um banco de dados em espera tem as seguintes limitações:
- 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 utilizar um grupo de failover, os direitos de standby são atribuídos ao nível do banco de dados, e não ao nível do grupo de failover, devendo ser atribuídos separadamente para cada banco de dados dentro do grupo de failover.
- Não é suportado 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 como encadeamento).
Pré-requisitos
- Uma assinatura do Azure. Se não tiver uma subscrição do Azure, crie uma conta gratuita do Azure antes de começar.
- Um Azure SQL Database vCore provisionado como primário na camada de serviço de Propósito Geral ou Crítico para Negócios, em execução em hardware suportado. Consulte o Guia Rápido para começar.
Configurar nova réplica para modo de 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, a CLI do Azure ou a API REST.
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 o recurso da base de dados SQL no portal do Azure.
Escolha Réplicas sob gerenciamento de dados no menu de recursos e, em seguida, 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éplicas Geográficas, selecione réplica de espera para tipo de réplica em Configuração de Réplica . Marque a caixa para confirmar que você usará a réplica em modo de espera.
Forneça um novo servidor ou um servidor existente para o novo banco de dados de espera e, em seguida, use Rever + 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.
Observação
Você também pode designar os seus bancos de dados para standby quando criar um grupo de alternância, ou adicionar bancos de dados a um grupo de alternância existente no portal do Azure.
Converter réplica existente
Você pode usar o portal do Azure ou o comando Replication Links - Update REST API 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:
- Vá para o seu recurso de banco de dados SQL no portal do Azure .
- Selecione Réplicas em Gerenciamento de dados.
- Selecione as reticências (...) para a réplica e, em seguida:
- Para converter uma réplica normal em uma réplica em espera, escolha Converter emem espera . Marque a caixa ao lado de Confirmo... na janela pop-up Converter para réplica de espera e, em seguida, selecione Sim para salvar a alteração e converter a réplica.
- Para converter uma réplica em espera numa réplica geográfica normal, escolha Converter em Geo. Marque a caixa ao lado de Eu confirmo... na janela pop-up Converter em réplica geográfica e, em seguida, selecione Sim para salvar as suas alterações e converter a sua réplica.
Para converter uma réplica existente usando o comando REST API Replication Links - Update, designe o linkType como STANDBY para uma réplica em espera ou GEO para converter uma réplica em espera existente numa réplica geográfica regular.
Ver direitos de licenciamento
Você pode exibir 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 de um banco de dados existente usando o portal do Azure, siga estas etapas:
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, a CLI do Azure ou a API REST.
Para remover uma réplica em espera terminando a replicação geográfica no portal do Azure, siga estas etapas:
- Vá para o seu banco de dados SQL no portal 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 frequentes (FAQ)
Quais são as implicações em termos de preços?
As réplicas de base de dados secundárias são cobradas pelo licenciamento SQL, computação e armazenamento para dados e backups. Quando se designa uma réplica de base de dados para estado de espera, não se é cobrado pelos custos de licenciamento dos vCores utilizados pela réplica secundária, mas ainda é cobrado pelos recursos computacionais e armazenamento.
Quais são as economias aproximadas com uma réplica em espera?
Sem custos de licenciamento incluídos, 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 escolha Réplica de espera na lista suspensa **Recuperação de desastres.
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 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, não é necessária 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 a fins de recuperação de desastres (DR) e não podem ter cargas ativas de leitura. 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?
Sim, no portal do Azure, no painel Réplicas. Selecione as reticências (...) e, em seguida, selecione a opção para Converter a sua réplica.
Posso ativar 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ê pode usar o Set-AzSqlDatabase PowerShell ou az sql db update comando da CLI do Azure para atualizar o tipo de licença para
BasePrice(Benefício Híbrido do Azure) para 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 pela hora completa, ainda pode ser cobrado o custo de licenciamento para a nova instância secundária durante a hora completa se a alteração de estado ocorrer a 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 ampliar a primária ou secundária para um tamanho vCore maior?
Ao expandir, é uma boa prática aumentar primeiro o secundário e, depois, o 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 de espera continuam a aplicar-se. Tente minimizar ao máximo o período de transição.
E se eu redimensionar o primário ou o secundário para um tamanho de vCore mais baixo?
Ao reduzir a escala, é uma prática recomendada reduzir primeiro o primário 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 associados à 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 uma reserva benefícios para a réplica em espera?
Sim. O preço de reserva é totalmente compatível com a réplica em espera.
Posso designar uma réplica para estado 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.