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:
Banco de Dados SQL do AzureBanco de Dados SQL no Fabric
Continuidade de Negócios no Banco de Dados SQL Azure refere-se aos mecanismos, políticas e procedimentos que permitem que a sua empresa continue operando mesmo em face de interrupções, fornecendo disponibilidade, alta disponibilidade e recuperação de desastres.
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
Na maioria dos casos, o Banco de dados 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 hardware.
Alta Disponibilidade
O Banco de Dados SQL do Azure vem com uma promessa básica de resiliência e confiabilidade que o 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 Banco de Dados 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 a redundância de zona, o banco de dados ou pool elástico usa zonas de disponibilidade do Azure 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, o banco de dados ou pool elástico é 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 Banco de Dados SQL do Azure é capaz de fornecer um SLA de maior disponibilidade de 99.995%.
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 o banco de dados de uma falha regional catastrófica. As opções para recuperação de desastres com o Banco de Dados SQL do Azure são:
- A replicação geográfica ativa permite criar, em qualquer região, um banco de dados secundário legível, continuamente sincronizado com um banco de dados primário.
- Grupos de failover, além de fornecer sincronização contínua entre um banco de dados primário e secundário, também permitem gerenciar a replicação e o failover de alguns ou todos os bancos de dados em um servidor lógico para um servidor lógico secundário em outra região. Os grupos de failover fornecem endpoints de escuta de leitura-gravação e somente leitura que permanecem inalterados, assim, não é necessário atualizar as strings de conexão da aplicação após o failover.
- Geo-restauro permite-lhe recuperar de uma interrupção regional ao restaurar a partir de cópias de segurança replicadas geograficamente, quando não conseguir aceder ao seu banco de dados na região primária. Pode criar um novo banco de dados em qualquer servidor existente em qualquer região do Azure.
A tabela a seguir compara grupos ativos de replicação geográfica e failover, duas opções de recuperação de desastres para o Banco de Dados SQL do Azure:
| Replicação geográfica ativa | Grupos de tolerância a falhas | |
|---|---|---|
| Sincronização contínua de dados entre o sistema primário e o secundário | Sim | Sim |
| Realizar failover de vários bancos de dados simultaneamente | Não | Sim |
| A cadeia de conexão permanece inalterada após o failover | Não | Sim |
| Suporta escalonamento de leitura | Sim | Sim |
| Várias réplicas | Sim | Não |
| Pode estar na mesma região que o primário | Sim | Não |
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 (usando redundância de zona) |
Normalmente menos de 30 segundos | 0 |
| Recuperação de desastres (usando grupos de failover com política de failover gerenciada pelo cliente ou replicação geográfica ativa) |
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) |
Normalmente, minutos ou horas, dependendo da replicação de armazenamento do Azure | Normalmente, minutos ou horas, dependendo do tamanho do backup do banco de dados |
Recursos que fornecem continuidade de negócios
Do ponto de vista do banco de dados, há quatro grandes cenários potenciais de interrupção. A tabela a seguir lista os recursos de continuidade de negócios do Banco de dados 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 atenuar falhas locais de hardware e software, o Banco de Dados SQL do Azure 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 de banco de dados. | Para proteger sua empresa contra perda de dados, o Banco de dados 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 de armazenamento com redundância geográfica por sete dias para todos os níveis de serviço. Todas as camadas de serviço, exceto a Basic, suportam um período de retenção de backup configurável para restauração no ponto no tempo (PITR) de até 35 dias. Você pode restaurar um banco de dados excluído ao ponto em que ele foi excluído se o servidor não tiver sido excluído ou se você tiver configurado retenção de longo prazo (LTR). |
| 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 hardware. | Para mitigar uma interrupção ao nível do datacenter ou da zona de disponibilidade, ative a redundância de zona para o banco de dados ou pool elástico, de forma a utilizar as Zonas de Disponibilidade do Azure e fornecer redundância através de várias zonas físicas dentro de uma região do Azure. Ao habilitar a redundância zonal, garante-se que o banco de dados ou grupo elástico seja resiliente a falhas de zona com um SLA de alta disponibilidade de até 99,995%%. |
| Rara interrupção regional 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 atenuar uma interrupção em toda a região, ative a recuperação de desastres usando uma das seguintes opções: - opções de sincronização contínua de dados, como os grupos de failover (recomendado) ou a replicação geográfica ativa, que permitem criar réplicas em uma região secundária para failover. - Configuração do armazenamento de backup com redundância geográfica para utilizar a restauração geográfica . |
Prepare-se para uma interrupção na região
Independentemente dos recursos de continuidade de negócios usados, você deve preparar o banco de dados secundário em outra região. Se não se preparar adequadamente, trazer as suas aplicações online após um failover ou recuperação leva mais tempo e requer provavelmente também resolução de problemas, o que pode atrasar o tempo de recuperação (RTO). Siga a lista de verificação para preparar o secundário para uma interrupção de região.
Restaurar 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 no mesmo servidor que representa o estado dos dados antes do evento corrompido. Para obter os tempos de recuperação, consulte RTO e RPO.
Se o período máximo de retenção de backup suportado para restauração point-in-time não for suficiente para seu aplicativo, você poderá estendê-lo configurando uma política de retenção de longo prazo (LTR). Para obter mais informações, consulte retenção de longo prazo.
Atualize um aplicativo com o mínimo de tempo de inatividade
Às vezes, um aplicativo deve ser colocado offline devido a manutenção, como uma atualização de aplicativo. Você pode gerenciar atualizações contínuas de aplicativos em nuvem usando a replicação geográfica ativa do Banco de dados SQL. A replicação geográfica também pode fornecer um caminho de recuperação se algo der errado.
Poupe nos custos com uma réplica de prontidão
Se sua réplica secundária for usada apenas para recuperação de desastres (DR) e não tiver cargas de trabalho de leitura ou gravação, você poderá economizar nos custos de licenciamento designando o banco de dados para espera ao configurar uma nova relação de replicação geográfica ativa.
Reveja a réplica em espera livre de licenças para saber mais.
Próximo passo
Conteúdo relacionado
- Projetando serviços disponíveis globalmente usando o Banco de Dados SQL do Azure
- Estratégias de recuperação de desastres para aplicativos que usam pools elásticos do Banco de Dados SQL do Azure
- Diretrizes de recuperação de desastres - Banco de Dados SQL do Azure
- Lista de verificação de alta disponibilidade e recuperação de desastres - Banco de Dados SQL do Azure