Configurar alta disponibilidade e recuperação de desastres
Uma parte importante da configuração de soluções de recuperação de desastres e alta disponibilidade no SQL Server permanece a mesma no SQL Server em execução na Máquina Virtual do Azure. A solução de alta disponibilidade foi projetada para garantir que nenhum dado comprometido seja perdido devido a falhas, que sua carga de trabalho não seja afetada pelas operações de manutenção e que o banco de dados não se torne um único ponto de falha em sua arquitetura de software.
A maioria das camadas de serviço SQL do Azure oferece uma variedade de opções de alta disponibilidade, desde redundância local até modelos de redundância de zona.
Em seguida, exploraremos as soluções específicas para recuperação de desastres e alta disponibilidade para as ofertas de PaaS do Azure.
Backup contínuo
O Banco de Dados SQL do Azure garante backups regulares e contínuos de bancos de dados, que são replicados para um armazenamento com rededição geográfica de acesso de leitura (RA-GRS).
Backups completos semanais, backups diferenciais a cada 12 a 24 horas e backups de log de transações a cada 5 a 10 minutos fazem parte da estratégia de backup automatizado. Para disponibilidade de backup estendida (até 10 anos), a retenção de longo prazo (LTR) pode ser configurada para bancos de dados únicos e em pool.
Retenção de longo prazo (LTR)
O Azure oferece uma política de retenção que você pode definir além dos limites usuais, o que é útil para cenários que exigem retenção de longo prazo. Você pode definir uma política de retenção por até 10 anos, e essa opção é desabilitada por padrão.
A imagem mostra como configurar políticas de retenção de longo prazo no portal do Azure. Depois de escolher o banco de dados, um painel aparecerá no lado direito da tela, onde você pode alterar as configurações padrão.
Para obter mais informações sobre retenção de longo prazo, consulte Retenção de longo prazo - Banco de Dados SQL do Azure e Instância Gerenciada SQL do Azure.
Restauro geográfico
Os backups para Banco de Dados SQL e Instância Gerenciada SQL são redundantes geograficamente por padrão. Isso permite que você restaure facilmente bancos de dados para uma região geográfica diferente, um recurso que é útil para cenários de recuperação de desastres menos rigorosos.
O armazenamento de backup é cobrado além do armazenamento regular de arquivos de banco de dados. No entanto, ao provisionar um Banco de Dados SQL, o armazenamento de backup é criado com o tamanho máximo da camada de dados selecionada para seu banco de dados, sem custo extra.
A duração de uma operação de restauração geográfica pode ser afetada por vários componentes subjacentes, incluindo o tamanho do banco de dados, o número de logs de transações envolvidos em uma operação de restauração e a quantidade de solicitações de restauração simultâneas sendo processadas na região de destino.
Restauração point-in-time (PITR)
Você pode restaurar seus bancos de dados para um ponto específico no tempo de acordo com a retenção definida, mas o PITR só é suportado se você estiver restaurando um banco de dados no mesmo servidor em que o backup foi originado. Você pode usar o portal do Azure, o Azure PowerShell, a CLI do Azure ou a API REST para restaurar um Banco de Dados SQL.
Georreplicação ativa
Um método para aumentar a disponibilidade do Banco de Dados SQL do Azure é usar a replicação geográfica ativa. A replicação geográfica ativa cria uma réplica de banco de dados secundária em outra região que é mantida atualizada de forma assíncrona.
Essa réplica é legível, semelhante a um grupo de disponibilidade AlwaysOn no SQL Server. Abaixo da superfície, o Azure usa grupos de disponibilidade para manter essa funcionalidade, e é por isso que algumas das terminologias são semelhantes.
A replicação geográfica ativa fornece continuidade de negócios, permitindo que os clientes façam failover programático ou manual de bancos de dados primários para regiões secundárias durante um desastre de grandes proporções.
Nota
A Instância Gerenciada SQL do Azure não oferece suporte à replicação geográfica ativa. Em vez disso, você deve usar grupos de failover automático, um tópico que exploraremos mais adiante nesta unidade.
Todos os bancos de dados envolvidos em uma relação de replicação geográfica devem ter a mesma camada de serviço. Além disso, para evitar problemas de desempenho de replicação devido a uma carga de trabalho de gravação pesada, recomendamos configurar a réplica secundária com o mesmo tamanho de computação que a principal.
Você pode configurar manualmente a replicação geográfica para o Banco de Dados SQL do Azure acessando a folha do banco de dados, na seção Gerenciamento de dados, selecionando Réplicas e, em seguida, + Criar réplica.
Depois que a réplica secundária for estabelecida, você terá a opção de iniciar manualmente um failover. Neste processo, os papéis são invertidos - a réplica secundária assume o papel de primária, enquanto a primária original torna-se a secundária.
Georreplicação entre subscrições
Em determinados cenários, talvez seja necessário configurar uma réplica secundária em uma assinatura diferente do banco de dados primário. É aqui que entra em jogo o recurso de replicação geográfica entre assinaturas.
Nota
A replicação geográfica entre assinaturas só está disponível programaticamente.
Para saber mais sobre as etapas necessárias para configurar uma replicação geográfica entre assinaturas, consulte Replicação geográfica entre assinaturas.
Grupos de ativação pós-falha automática
Um grupo de failover automático é um recurso de alta disponibilidade suportado pelo Banco de Dados SQL do Azure e pela Instância Gerenciada SQL do Azure. Os grupos de failover automático permitem gerenciar como os bancos de dados são replicados para outra região e como o failover pode acontecer. O nome atribuído ao grupo de failover automático deve ser exclusivo dentro do domínio *.database.windows.net .
Um grupo de failover automático pode incluir vários bancos de dados. Tanto o primário quanto o secundário têm o mesmo tamanho de banco de dados.
Os grupos de failover automático fornecem uma funcionalidade semelhante à AG chamada ouvinte, que permite atividades de leitura-gravação e somente leitura. Existem dois tipos diferentes de ouvintes: um para leitura-gravação e outro para tráfego somente leitura. Nos bastidores de um failover, o DNS é atualizado para que os clientes possam apontar para o nome do ouvinte abstrato e não precisem saber mais nada. O servidor de banco de dados que contém as cópias de leitura-gravação é o primário e o servidor que está recebendo as transações do primário é secundário.
Há duas políticas diferentes para grupos de failover automático.
| Tipo de Política | Description |
|---|---|
| Automático | Quando uma falha é detetada, o sistema dispara um failover automaticamente por padrão. No entanto, se necessário, você pode desativar o failover automático. |
| Só de leitura | Durante um failover, o mecanismo desabilita o ouvinte somente leitura por padrão para manter o desempenho do novo primário quando o secundário está inativo. No entanto, você pode alterar esse comportamento para permitir ambos os tipos de tráfego após um failover. |
O failover é um processo que pode ser iniciado manualmente, mesmo quando o failover automático está habilitado. No entanto, o tipo de failover pode influenciar se a perda de dados ocorre. Por exemplo, um failover não planejado pode levar à perda de dados se for forçado e o banco de dados secundário não tiver sido totalmente sincronizado com o principal.
O GracePeriodWithDataLossHours determina a duração que o Azure aguarda antes de iniciar um failover, com o valor padrão definido como uma hora. Se o RPO (Recovery Point Objetive, objetivo de ponto de recuperação) for rigoroso e a perda de dados não for uma opção, você poderá definir esse valor mais alto. Embora isso signifique que o Azure espera mais tempo antes de iniciar um failover, ele pode potencialmente reduzir a perda de dados, pois fornece mais tempo para o banco de dados secundário sincronizar totalmente com o principal.
Nota
O banco de dados secundário é criado automaticamente através de um processo conhecido como propagação, que pode levar tempo dependendo do tamanho do banco de dados. Por isso, é importante planejar com antecedência, considerando fatores como a velocidade da rede.
Para saber mais sobre alta disponibilidade e recuperação de desastres para o Banco de Dados SQL do Azure, consulte Lista de verificação de alta disponibilidade e recuperação de desastres do Banco de Dados SQL do Azure.