O exame DP-300 se concentra em escolher a opção correta para cada cenário de alta disponibilidade e recuperação de desastres. O Azure SQL Database e o SQL Managed Instance oferecem mecanismos de backup, replicação e failover que abordam problemas distintos: backups tratam de corrupção lógica, a replicação lida com desastres físicos e o failover automático garante a continuidade do serviço.
PITR — Uma máquina do tempo para desfazer erros
Imagine que um desenvolvedor executa uma instrução UPDATE incorreta durante o fim de semana e sobrescreve milhares de registros críticos. Não existe script de reversão e a única informação disponível é o horário exato do erro. O Azure SQL Database oferece o Point-in-Time Restore (PITR) precisamente para esse tipo de corrupção lógica de dados.
O PITR combina três tipos de backups automatizados: completos semanalmente, diferenciais a cada 12 horas e de log de transações a cada 5 a 10 minutos. Juntos permitem a restauração para qualquer minuto dentro do período de retenção. O período padrão é de 7 dias, configurável até 35 dias.
A restauração sempre cria um novo banco de dados — o original nunca é sobrescrito. Após a conclusão, o administrador valida os dados e redireciona manualmente as conexões. Essa etapa faz parte do tempo de recuperação e deve ser considerada no planejamento do RTO.
LTR — Um cofre para registros de uma década
Uma autoridade fiscal exige sete anos de histórico de transações. Uma regulamentação de saúde obriga a manter dados de pacientes por dez anos. A retenção máxima de 35 dias do PITR não atende esses requisitos. O Long-Term Retention (LTR) foi projetado especificamente para esse tipo de conformidade regulatória.
O LTR armazena backups completos no Azure Blob Storage por até 10 anos. As políticas semanal, mensal e anual podem ser configuradas independentemente — por exemplo, semanais por 12 semanas, mensais por 36 meses e anuais por 5 anos simultaneamente.
LTR e PITR têm propósitos distintos. O PITR serve para recuperação precisa após uma consulta incorreta. O LTR é para arquivamento de longo prazo — preservar um snapshot do 1º de janeiro para uma auditoria anual. Ambos podem estar ativos no mesmo banco de dados.
!PITR vs LTR
Active Geo-Replication — Um gêmeo em espera do outro lado do país
Quando um centro logístico fica fora de serviço por causa de uma tempestade, ter um centro de backup equivalente em outra cidade significa que as entregas podem continuar com interrupção mínima. O Active Geo-Replication fornece exatamente essa estrutura para o Azure SQL Database.
O Active Geo-Replication cria até quatro réplicas secundárias legíveis em regiões diferentes para um único banco de dados. A replicação é assíncrona e as réplicas secundárias podem ser usadas para cargas de trabalho somente leitura, como relatórios e consultas analíticas, aliviando a pressão sobre a primária.
Quando ocorre uma falha, um failover manual promove uma réplica secundária para primária. Essa é a distinção fundamental em relação ao Auto-Failover Group — não há alternância automática, alguém deve iniciá-la. O Active Geo-Replication não tem suporte para SQL Managed Instance.
Auto-Failover Group — Um sistema de sprinklers automáticos para seu banco de dados
Quando o alarme de incêndio dispara, alguém deveria correr para pegar um extintor ou os sprinklers deveriam ser ativados automaticamente? O Auto-Failover Group é o sistema de sprinklers para falhas de banco de dados — atua sem intervenção humana.
O Auto-Failover Group oferece suporte a failover automático para um grupo de bancos de dados ou SQL Managed Instances. Quando a região primária falha, o sistema muda automaticamente para a secundária com base em uma política configurada. As aplicações se conectam por meio de um endpoint de ouvinte, portanto não são necessárias alterações na cadeia de conexão após o failover.
Ao contrário do Active Geo-Replication, o Auto-Failover Group suporta tanto SQL Database quanto SQL Managed Instance, e gerencia vários bancos de dados como um único grupo para garantir consistência no failover.
Geo-Replication vs Auto-Failover Group — Como escolher
| Característica | Active Geo-Replication | Auto-Failover Group | |:--|:--|:--| | Escopo | Banco de dados individual | Grupo de bancos de dados ou MI | | Produtos compatíveis | Somente SQL Database | SQL Database + SQL MI | | Tipo de failover | Manual | Automático (baseado em política) | | Secundárias legíveis | Até 4 | Sim (ouvinte somente leitura) | | Endpoint de ouvinte | Não | Sim | | Gerenciamento multi-banco | Não | Sim |
Escolha o Active Geo-Replication quando precisar de um único banco de dados com réplicas secundárias legíveis e controle manual do momento do failover. Escolha o Auto-Failover Group quando vários bancos de dados devem sofrer failover como uma unidade, a alternância automática é necessária e o endpoint de ouvinte deve permanecer estável após a troca.
Always On AG e FCI — HA para ambientes IaaS (SQL em VM)
Quando o SQL Server é executado em máquinas virtuais do Azure em vez de um serviço PaaS, a alta disponibilidade é configurada de forma diferente. O Always On Availability Groups (AG) e o Failover Cluster Instance (FCI) são as principais opções nesse ambiente IaaS.
O Always On AG suporta configurações de vários nós com replicação síncrona ou assíncrona. Um listener roteia os clientes para o nó primário. Em caso de falha, outro nó assume automaticamente ou manualmente. A replicação síncrona aproxima o RPO de zero, mas adiciona latência de gravação.
O FCI fornece disponibilidade em nível de instância usando armazenamento compartilhado. Se um nó falhar, outro assume a mesma instância. Para o SQL Managed Instance, a disponibilidade integrada se assemelha ao FCI e é gerenciada automaticamente pela plataforma.
Armadilhas comuns no exame — Conceitos semelhantes mas diferentes
A maior fonte de confusão é tratar PITR e Geo-Replication como se resolvessem o mesmo problema. O PITR desfaz corrupção lógica — um UPDATE incorreto. O Geo-Replication mantém uma cópia ativa em outra região para desastres físicos. Confundi-los quase sempre leva a uma resposta errada.
O Active Geo-Replication não tem suporte para SQL Managed Instance. Quando uma questão combinar SQL MI com réplicas legíveis ou replicação entre regiões, a resposta é Auto-Failover Group.
O Geo-restore não é o mesmo que o Geo-replication. O Geo-restore recupera de um backup com redundância geográfica com RPO de várias horas — não é uma solução de HA em tempo real. Se o cenário exige replicação contínua, Active Geo-Replication ou Auto-Failover Group é a resposta correta.
Resumo do Exame
"Corrupção lógica, recuperação de consulta incorreta" -- PITR (Point-in-Time Restore) "Retenção regulatória de 7 ou 10 anos" -- LTR (Long-Term Retention) "Período de retenção padrão do PITR" -- 7 dias (até 35 dias) "Período máximo de retenção do LTR" -- 10 anos "Banco de dados único, secundárias legíveis, failover manual" -- Active Geo-Replication "Grupo de bancos de dados, failover automático, endpoint de ouvinte" -- Auto-Failover Group "SQL MI + replicação entre regiões" -- Auto-Failover Group (Geo-Replication não disponível no MI) "IaaS SQL em VM, replicação síncrona/assíncrona, vários nós" -- Always On Availability Groups "IaaS SQL em VM, HA em nível de instância, armazenamento compartilhado" -- Failover Cluster Instance "Sem alteração na cadeia de conexão após o failover" -- Endpoint de ouvinte do Auto-Failover Group "Falha de toda a região primária, restaurar a partir de backup" -- Backup com redundância geográfica + Geo-restore
PITR = recuperação de curto prazo para corrupção lógica, LTR = arquivamento de longo prazo para conformidade regulatória, Active Geo-Replication = alternância manual de banco de dados individual, Auto-Failover Group = alternância automática de grupo