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:
Instância Gerenciada do Azure SQL
Este artigo fornece uma visão geral dos recursos de continuidade de negócios e recuperação de desastres da Instância Gerenciada SQL do Azure, descrevendo as opções e recomendações para a recuperação de eventos com interrupções que podem levar à perda de dados ou fazer com que sua instância e aplicativo fiquem indisponíveis. Saiba o que fazer quando um erro de usuário ou aplicativo afeta a integridade dos dados, uma zona ou região de disponibilidade do Azure tem uma interrupção ou seu aplicativo requer manutenção.
Visão geral
Continuidade de negócios na Instância Gerenciada SQL do Azure refere-se aos mecanismos, políticas e procedimentos que permitem que a sua empresa continue operando em caso de interrupções, fornecendo disponibilidade, alta disponibilidade e recuperação de desastres.
Na maioria dos casos, a Instância Gerenciada SQL lida com eventos disruptivos que podem acontecer em um ambiente de nuvem e mantém seus aplicativos e processos de negócios em execução. No entanto, existem alguns eventos disruptivos em que a mitigação pode levar algum tempo, tais como:
- O usuário exclui ou atualiza acidentalmente uma linha em uma tabela.
- Invasor mal-intencionado exclui dados com êxito ou descarta um banco de dados.
- Um evento de desastre natural catastrófico derruba um datacenter ou uma zona ou região de disponibilidade.
- Datacenter raro, zona de disponibilidade ou interrupção em toda a região causada por uma alteração de configuração, bug de software ou falha de componente de hardware.
Para obter recomendações prescritivas para maximizar a disponibilidade e alcançar maior continuidade de negócios, consulte:
- Lista de verificação de disponibilidade
- Lista de verificação de alta disponibilidade
- Lista de verificação de recuperação de desastres
Alta Disponibilidade
A Instância Gerenciada SQL do Azure vem com uma promessa de resiliência e confiabilidade central que a protege contra falhas de software ou hardware. Os backups de banco de dados são automatizados para proteger seus dados contra corrupção ou exclusão acidental. Como uma plataforma como serviço (PaaS), o serviço de Instância Gerenciada SQL do Azure fornece disponibilidade como um recurso pronto para uso com um SLA de disponibilidade líder do setor de 99,99%.
Para obter alta disponibilidade no ambiente de nuvem do Azure, habilite a redundância de zona. Com redundância de zona, a instância usa zonas de disponibilidade para garantir resiliência a falhas zonais.
- Muitas regiões do Azure fornecem zonas de disponibilidade, que são grupos separados de data centers dentro de uma região que têm infraestrutura independente de energia, resfriamento e rede.
- As zonas de disponibilidade são projetadas para fornecer serviços regionais, capacidade e alta disponibilidade nas zonas restantes se uma zona sofrer uma interrupção.
Ao habilitar a redundância de zona, a instância é resiliente a falhas zonais de hardware e software e a recuperação é transparente para os aplicativos. Quando a alta disponibilidade está habilitada, o serviço de Instância Gerenciada SQL do Azure é capaz de fornecer um SLA de disponibilidade mais alta de 99,99%.
Recuperação de desastres
Para obter maior disponibilidade e redundância entre regiões, você pode habilitar os recursos de recuperação de desastres para recuperar rapidamente a instância de uma falha regional catastrófica. As opções para recuperação de desastres com a Instância Gerenciada SQL do Azure são:
- Os grupos de redundância habilitam a sincronização contínua entre uma instância primária e uma secundária. Os grupos de comutação por falha fornecem pontos de extremidade de escuta de leitura-escrita e somente leitura que permanecem inalterados, portanto, não é necessário atualizar as strings de ligação da aplicação após a comutação por falha.
- A restauração geográfica permite recuperar-se de uma interrupção regional, restaurando a partir de backups replicados geograficamente, quando não for possível aceder ao seu banco de dados na região primária. Pode criar uma nova base de dados em qualquer instância existente em qualquer região do Azure.
RTO e RPO
Ao desenvolver seu plano de continuidade de negócios, entenda o tempo máximo aceitável antes que o aplicativo se recupere totalmente após o evento de interrupção. Duas maneiras comuns de quantificar os requisitos de negócios em torno da recuperação de desastres são:
- RTO (Recovery Time Objetive, objetivo de tempo de recuperação): o tempo necessário para que um aplicativo se recupere totalmente após um evento de interrupção não planejado.
- RPO (Recovery Point Objetive, objetivo de ponto de recuperação): a quantidade de tempo de perda de dados que pode ser tolerada a partir de um evento de interrupção não planejado.
A tabela a seguir compara RPO e RTO de cada opção de continuidade de negócios:
| Opção de continuidade de negócios | RTO (tempo de inatividade) | RPO (perda de dados) |
|---|---|---|
| Alta Disponibilidade (com redundância de zona) |
Normalmente menos de 30 segundos | 0 |
| Recuperação de Desastres (Usando grupos de tolerância a falhas com política de tolerância a falhas gerida pelo cliente) |
Normalmente menos de 60 segundos | Igual ou superior a 0 (Depende de alterações de dados anteriores ao evento de interrupção que não foram replicadas) |
| Recuperação de Desastres (usando restauração geográfica) |
12 horas | 1 hora |
Recursos que fornecem continuidade de negócios
Por exemplo, existem quatro grandes cenários potenciais de perturbação. A tabela a seguir lista os recursos de continuidade de negócios da Instância Gerenciada SQL que você pode usar para mitigar um possível cenário de interrupção de negócios:
| Cenário de interrupção de negócios | Funcionalidade de continuidade de negócios |
|---|---|
| Falhas locais de hardware ou software que afetam o nó do banco de dados. | Para mitigar falhas locais de hardware e software, a Instância Gerenciada SQL inclui uma arquitetura de disponibilidade , que garante a recuperação automática dessas falhas com SLA de disponibilidade de até 99,99%. |
| Corrupção ou exclusão de dados normalmente causada por um bug do aplicativo ou erro humano. Essas falhas são específicas do aplicativo e normalmente não podem ser detetadas pelo serviço. | Para proteger sua empresa contra perda de dados, a Instância Gerenciada SQL cria automaticamente backups completos de banco de dados semanalmente, backups diferenciais de banco de dados a cada 12 ou 24 horas e backups de log de transações a cada 5 a 10 minutos. Por padrão, os backups são armazenados em armazenamento com redundância geográfica por sete dias e suportam um período de retenção de backup configurável para restauração no ponto no tempo de até 35 dias. Você pode restaurar um banco de dados eliminado até ao ponto em que foi eliminado se a instância não tiver sido eliminada, ou se configurou a retenção de longo prazo . |
| Rara interrupção do datacenter ou da zona de disponibilidade, possivelmente causada por um evento de desastre natural, alteração de configuração, bug de software ou falha de componente de hardware. | Para atenuar a interrupção no nível do datacenter ou da zona de disponibilidade, habilite o de redundância de zona para que a Instância Gerenciada do SQL use Zonas de Disponibilidade do Azure e forneça redundância em várias zonas físicas dentro de uma região do Azure. A ativação da redundância de zona garante que a instância gerida seja resiliente a falhas zonais, com um SLA de alta disponibilidade de até 99,99%. |
| Rara interrupção da região que afeta todas as zonas de disponibilidade e os datacenters que as compõem, possivelmente causada por um evento catastrófico de desastre natural. | Para mitigar uma interrupção em toda a região, habilite a recuperação de desastres usando uma das opções: - Sincronização contínua de dados com os grupos de failover para réplicas numa região secundária usada para failover. - Definir a redundância de armazenamento de backup como armazenamento de backup com redundância geográfica para usar restauração geográfica. |
Recuperar um banco de dados dentro da mesma região do Azure
Você pode usar backups automáticos de banco de dados para restaurar um banco de dados para um ponto no tempo no passado. Desta forma, você pode se recuperar de corrupções de dados causadas por erros humanos. A restauração point-in-time (PITR) permite criar um novo banco de dados para a mesma instância, ou uma instância diferente, que representa o estado dos dados antes do evento corrompido. A operação de restauração é uma operação de dados cujo tamanho também depende da carga de trabalho atual da instância de destino. Pode levar mais tempo para recuperar um banco de dados muito grande ou muito ativo. Para obter mais informações sobre o tempo de recuperação, consulte tempo de recuperação do banco de dados.
Se o período máximo de retenção de backup suportado para restauração point-in-time (PITR) não for suficiente para seu aplicativo, você poderá estendê-lo configurando uma política de retenção de longo prazo (LTR) para o(s) banco(s) de dados. Para obter mais informações, consulte retenção de longo prazo.
Recuperar um banco de dados para uma instância existente
Embora raro, um datacenter do Azure pode ter uma interrupção. Quando ocorre uma interrupção, ela causa uma interrupção nos negócios que pode durar apenas alguns minutos ou horas.
- Uma opção é esperar que sua instância fique online novamente quando a interrupção do datacenter terminar. Isso funciona para aplicativos que podem se dar ao luxo de ter seu banco de dados offline. Por exemplo, um projeto de desenvolvimento ou avaliação gratuita em que você não precisa trabalhar constantemente. Quando um datacenter tem uma interrupção, você não sabe quanto tempo a interrupção pode durar, então essa opção só funciona se você não precisar do banco de dados por algum tempo.
- Se estiver a utilizar armazenamento com redundância geográfica (GRS) ou com redundância de zona geográfica (GZRS), outra opção é restaurar uma base de dados para qualquer instância gerida do SQL em qualquer região do Azure utilizando cópias de segurança de bases de dados com redundância geográfica (restauro geográfico). A restauração geográfica utiliza um backup com redundância geográfica como fonte e pode ser usada para recuperar uma base de dados até ao último ponto de recuperação disponível, mesmo que a base de dados ou o centro de dados esteja inacessível devido a uma interrupção. O backup disponível pode ser encontrado na região emparelhada.
- Finalmente, você pode se recuperar rapidamente de uma interrupção se tiver configurado um geosecundário usando um grupo de failover para sua instância, usando failover gerenciado pelo cliente (recomendado) ou gerenciado pela Microsoft. Enquanto o failover em si leva apenas alguns segundos, o serviço leva pelo menos 1 hora para ativar um failover geográfico gerenciado pela Microsoft, se configurado. Isso é necessário para garantir que o failover seja justificado pela escala da interrupção. Além disso, o failover pode resultar na perda de dados recentemente alterados devido à natureza da replicação assíncrona entre as regiões emparelhadas.
Ao desenvolver seu plano de continuidade de negócios, você precisa entender o tempo máximo aceitável antes que o aplicativo se recupere totalmente após o evento de interrupção. O tempo necessário para que o aplicativo se recupere totalmente é conhecido como Recovery Time Objetive (RTO). Você também precisa entender o período máximo de atualizações de dados recentes (intervalo de tempo) que o aplicativo pode tolerar perder ao se recuperar de um evento disruptivo não planejado. A perda potencial de dados é conhecida como RPO (Recovery Point Objetive, objetivo de ponto de recuperação).
Diferentes métodos de recuperação oferecem diferentes níveis de RPO e RTO. Você pode escolher um método de recuperação específico ou usar uma combinação de métodos para obter a recuperação completa do aplicativo.
Use grupos de failover se seu aplicativo atender a qualquer um destes critérios:
- É missão crítica.
- Tem um contrato de nível de serviço (SLA) que não permite 12 horas ou mais de tempo de inatividade.
- O tempo de inatividade pode resultar em responsabilidade financeira.
- Tem uma alta taxa de alteração de dados e 1 hora de perda de dados não é aceitável.
- O custo adicional da replicação geográfica ativa é menor do que o potencial passivo financeiro e a perda de negócios associada.
Você pode optar por usar uma combinação de backups de banco de dados e grupos de failover, dependendo dos requisitos do aplicativo.
As seções a seguir fornecem uma visão geral das etapas de recuperação usando backups de banco de dados ou grupos de failover.
Prepare-se para uma interrupção
Independentemente do recurso de continuidade de negócios usado, você deve:
- Identifique e prepare a instância de destino, incluindo regras de firewall IP de rede, logins e permissões de nível de banco de dados
master. - Determinar como redirecionar clientes e aplicativos cliente para a nova instância
- Documente outras dependências, como configurações de auditoria e alertas
Se você não se preparar corretamente, colocar seus aplicativos on-line após um failover ou uma recuperação de banco de dados leva tempo adicional e, provavelmente, também requer solução de problemas em um momento de estresse - uma má combinação.
Troca para uma instância secundária replicada geograficamente
Se você estiver usando grupos de failover como mecanismo de recuperação, poderá configurar uma política de failover automática. Uma vez iniciado, o failover faz com que a instância secundária se torne a nova principal, pronta para registrar novas transações e responder a consultas - com perda mínima de dados para os dados ainda não replicados.
Observação
Quando o datacenter volta a ficar online, o primário antigo se reconecta automaticamente ao novo primário para se tornar a instância secundária. Se precisar reverter o servidor principal de volta para a região original, pode-se iniciar um failover planejado manualmente (failback).
Executar uma restauração geográfica
Se estiveres a usar backups automatizados com armazenamento com redundância geográfica (a opção de armazenamento predefinida ao criar a tua instância), podes recuperar a base de dados utilizando geo-restore. A recuperação geralmente ocorre dentro de 12 horas - com perda de dados de até uma hora determinada por quando o último backup de log foi feito e replicado. Até que a recuperação seja concluída, o banco de dados não poderá registrar nenhuma transação ou responder a quaisquer consultas. Note que a restauração geográfica apenas recupera o banco de dados para o último momento específico disponível.
Observação
Se o datacenter voltar a ficar online antes de alternares a tua aplicação para o banco de dados recuperado, poderás cancelar a recuperação.
Executar tarefas de recuperação/pós-falha
Após a recuperação de qualquer mecanismo de recuperação, você deve executar as seguintes tarefas adicionais antes que seus usuários e aplicativos estejam de volta e em execução:
- Redirecionar clientes e aplicativos cliente para a nova instância e o banco de dados restaurado.
- Verifique se as regras apropriadas de firewall IP de rede estão em vigor para que os usuários se conectem.
- Verifique se os logins apropriados e
masterpermissões no nível do banco de dados estão em vigor (ou use utilizadores contidos). - Configure a auditoria, conforme necessário.
- Configure alertas, conforme apropriado.
Observação
Se estiveres a usar um grupo de failover e te conectares à instância usando o listener de leitura-escrita, o redirecionamento após o failover acontecerá automaticamente e de forma transparente para a aplicação.
Réplicas de DR sem necessidade de licença
Você pode economizar nos custos de licenciamento configurando uma Instância Gerenciada SQL do Azure secundária apenas para recuperação de desastres (DR). Esse benefício estará disponível se você estiver usando um grupo de failover entre duas instâncias gerenciadas do SQL ou se tiver configurado um link híbrido entre o SQL Server e a Instância Gerenciada do SQL do Azure. Desde que a instância secundária não tenha quaisquer cargas de leitura ou escrita e esteja apenas em espera passiva de DR, não se cobra pelos custos de licenciamento vCore utilizados pela instância secundária.
Quando você designa uma instância secundária apenas para recuperação de desastres e nenhuma carga de trabalho de leitura ou gravação está sendo executada na instância, a Microsoft fornece o número de vCores licenciados para a instância principal sem custo adicional sob o benefício de direitos de failover. Você ainda é cobrado pela computação e armazenamento que a instância secundária usa. Para obter termos e condições precisos do benefício de direitos de failover híbrido, consulte os termos de licenciamento do SQL Server online na seção "SQL Server – Direitos de failover".
O nome do benefício depende do seu cenário:
- Direitos de Failover Híbridos para uma réplica passiva: ao configurar uma ligaçãde entre o SQL Server e a Instância Gerida do Azure SQL, pode usar o benefício de Direitos de Failover Híbridos para economizar nos custos de licenciamento de vCore para a réplica secundária passiva.
- Direitos de failover para uma réplica em espera: Ao configurar um grupo de failover entre duas instâncias gerenciadas, você pode usar o benefício direitos de failover para economizar nos custos de licenciamento vCore para a réplica secundária em espera.
O diagrama a seguir demonstra o benefício para cada cenário:
