Pular para o conteúdo principal

Desafio 31: projetar alta disponibilidade para dados relacionais

Tempo Estimado e Custo

60-90 min | Custo estimado: $15-30 | Peso no Exame: 15-20%

Introdução​

A GlobalPay Corporation processa folha de pagamento para 100.000 funcionários em 15 paises abrangendo América do Norte, Europa e Asia-Pacifico. As execucoes de folha são processos batch críticos em tempo que devem ser concluidos até a meia-noite no fuso horario local de cada pais, com resultados disponíveis para transferencias bancarias até as 6:00 AM. Se uma execução de folha falhar ou dados forem perdidos durante o processamento, a janela de re-execução e extremamente apertada, e folha de pagamento perdida aciona penalidades regulatorias imediatas em múltiplas jurisdicoes.

O banco de dados principal de folha de pagamento é um Azure SQL Database (tier Business Critical, 32 vCores) em East US, com read replicas em West Europe e Southeast Asia para relatórios regionais. O sistema processa folha em ondas rotativas: Asia-Pacifico executa primeiro (comecando as 15:00 UTC), Europa executa em seguida (comecando as 21:00 UTC), e América do Norte por último (comecando as 05:00 UTC). Durante cada execução, o banco de dados lida com operações intensivas de escrita (calculos de salario, retencoes de impostos, deducoes) seguidas por leituras pesadas (gerando contracheques, formularios fiscais, arquivos bancarios).

A GlobalPay não pode perder NENHUM dado durante um failover. Um failover durante o processamento que perca mesmo uma transação pode significar calculos de impostos incorretos para milhares de funcionários, exigindo correcoes caras e registros regulatorios. O banco de dados também deve estar disponível 24/7 porque o cronograma rotativo de folha significa que alguma região esta sempre processando.

Habilidades do exame cobertas​

  • Recomendar uma solução de alta disponibilidade para dados relacionais

Tarefas de design​

Parte 1: arquitetura de HA do Azure SQL database​

  1. Avalie as capacidades de HA integradas em cada tier de serviço do Azure SQL Database:
RecursoGeneral PurposeBusiness CriticalHyperscale
Zone redundancyOpcional (custo extra)IncluidoOpcional
Read replicas (na região)01-3 (incluidas)0-4
Tempo de failover30+ segundos< 30 segundosVaria
RPO (falha de zona)0 (replicação sincrona)0 (replicação sincrona)0
Named replicasNãoNãoSim
SLA (zone-redundant)99,995%99,995%99,99%

  1. Justifique por que o tier Business Critical é necessário para a carga de trabalho de folha de pagamento da GlobalPay:

    • Requisito de zero perda de dados (replicação sincrona para replicas secundarias)
    • Failover em menos de 30 segundos (batch de folha não pode tolerar longos atrasos de reconexao)
    • Read replicas integradas (consultas de relatórios descarregadas do processamento)
    • Armazenamento SSD local (alto IOPS para processamento batch)

  2. Documente como o tier Business Critical alcanca recuperação de falha de zona com RPO zero internamente (arquitetura Always On Availability Group com replicas sincronas).

Parte 2: failover Groups para HA Cross-Region​

  1. Projete a topologia de failover group para o requisito multi-região da GlobalPay:

    • Primário: East US (Business Critical, 32 vCores)
    • Secundário 1: West Europe (mesmo tier, usado para relatórios europeus)
    • Secundário 2: Southeast Asia (mesmo tier, usado para relatórios APAC)
    • Limitacao: Failover groups suportam apenas UM secundário. Como você trata três regiões?

  2. Avalie as opcoes para acesso de leitura multi-região:

AbordagemRegiõesAuto-failoverAcesso de LeituraLimitacao
Failover group (secundário único)2SimSecundário legivelApenas 1 secundário
Active geo-replicationAté 4Apenas manualTodos os secundários legiveisSem auto-failover
Failover group + geo-replication3+ParcialMistoTopologia complexa
  1. Projete a topologia recomendada:
    • Failover group entre East US e West Europe (auto-failover para DR primário)
    • Active geo-replication de East US para Southeast Asia (read-only, failover manual)
    • Documente o RPO e RTO para cada secundário

Parte 3: comportamento de failover e impacto na aplicação​

  1. Análise o que acontece durante um evento de failover automático:

    • Como a connection string da aplicação muda? (Não muda - endpoint do failover group e estavel)
    • O que acontece com transações em andamento? (Rollback no antigo primário)
    • Quanto tempo o banco de dados fica indisponível durante o failover?
    • Qual é o grace period, e quais são os trade-offs de defini-lo mais curto vs. mais longo?

  2. Projete a lógica de retry em nível de aplicação para cenários de failover:

    • Codigos de erro transientes para retry: 40613, 40197, 40501, 49918
    • Estratégia de retry: Exponential backoff com máximo de 5 retries
    • Circuit breaker: Pare de retentar apos 60 segundos e alerte operações
    • Connection string deve usar endpoint do failover group, não nome individual do servidor

  3. Aborde o cenário de risco "split-brain":

    • O que acontece se o primário ficar isolado (não consegue alcancar o secundário) mas ainda esta aceitando escritas?
    • Como o grace period previne failover prematuro?
    • Qual é a exposicao máxima de perda de dados durante o grace period?

Parte 4: SQL managed instance Business Critical​

  1. A GlobalPay esta considerando migrar para Azure SQL Managed Instance por recursos como consultas cross-database e SQL Agent. Compare as capacidades de HA:
RecursoSQL Database BCSQL MI BC
Zone redundancySimSim
Failover groupsSimSim (nível de instância)
Consultas cross-databaseNãoSim
SQL AgentNãoSim
Unidade de failoverBanco de dados únicoInstância inteira
Escopo do failover groupBancos de dados selecionadosTodos os bancos na instância

  1. Projete a arquitetura de HA se a GlobalPay usar SQL Managed Instance:

    • Tier BC com zone redundancy (AG Always On de 4 nos)
    • Failover group para região secundária (instância inteira faz failover junto)
    • Impacto no failover: todos os bancos de dados movem juntos (vantagem para DBs de folha relacionados)

  2. Crie uma estratégia de monitoramento e alertas:

    • Monitore a defasagem de replicação para secundários (deve ser < 5 segundos)
    • Alerte sobre eventos de failover (notificação automatizada para equipe DBA)
    • Monitore utilizacao de DTU/vCore durante execucoes de folha
    • Rastreie conexões bem-sucedidas para o endpoint do failover group

Criterios de sucesso​

  • ⬜Business Critical tier selected with justification for zero-RPO and sub-30s failover
  • ⬜Failover group configured with apprópriate grace period for automatic failover
  • ⬜Multi-region read access topology designed (failover group + active geo-replication)
  • ⬜Application retry logic designed for transient failover errors
  • ⬜Split-brain scenário analyzed with grace period trade-offs documented
  • ⬜Monitoring and alerting configured for replication lag and failover events

Dicas​

Dica 1: Arquitetura Interna do Business Critical

O tier Business Critical do Azure SQL Database usa uma arquitetura baseada em Always On Availability Groups:

  • 1 replica primária + 3 replicas secundarias (todas sincronas)
  • Dados armazenados em SSD local (não armazenamento remoto como General Purpose)
  • Toda transação e confirmada em todas as replicas antes de reconhecer ao cliente
  • Failover promove um secundário a primário em < 30 segundos
  • Um secundário esta disponível como endpoint read-only (sem custo extra)

Configuração zone-redundant:

  • Replicas são distribuidas entre availability zones
  • Sobrevive a falha completa de zona com zero perda de dados
  • SLA aumenta de 99,99% para 99,995%

Esta arquitetura garante RPO = 0 para qualquer falha de zona porque todas as replicas confirmaram a transação antes de ser reconhecida.

Dica 2: Grace Period do Failover Group

O grace period (GracePeriodWithDataLossHours) controla quanto tempo o failover automático espera apos detectar indisponibilidade do primário:

  • Mínimo: 1 hora
  • Recomendado: 1 hora para a maioria das cargas de trabalho
  • Trade-off: Grace period mais curto = failover mais rápido mas maior risco de falsos positivos

Durante o grace period:

  • Primário esta inalcancavel (confirmado pelo monitoramento do Azure)
  • Nenhuma escrita é possível (banco de dados e efetivamente read-only via secundário)
  • Apos o grace period expirar: failover automático aciona, promovendo secundário a primário
  • Quaisquer transações confirmadas no antigo primário mas ainda não replicadas para o secundário são PERDIDAS

Para GlobalPay: Defina grace period para 1 hora. Durante esse tempo, processamento de folha para, mas nenhum dado e perdido. Se o primário recuperar dentro de 1 hora, nenhum failover ocorre. A pausa de 1 hora e aceitavel dado que a janela de processamento de folha e de 6+ horas.

Dica 3: Connection Strings do Failover Group

Failover group fornece endpoints estaveis que redirecionam automaticamente:

  • Read-write: <failover-group-name>.database.windows.net (sempre aponta para o primário atual)
  • Read-only: <failover-group-name>.secondary.database.windows.net (sempre aponta para o secundário)

Beneficios para a aplicação:

  • Nenhuma mudança de connection string necessária durante failover
  • TTL DNS para endpoints do failover group e 30 segundos
  • Apos failover, novas conexões roteiam para o novo primário dentro de ~30 segundos
  • Conexoes existentes são descartadas e devem reconectar (lógica de retry trata isso)
# Create failover group
az sql failover-group create \
  --resource-group rg-globalpay \
  --server sql-globalpay-eastus \
  --partner-server sql-globalpay-westeurope \
  --name fg-globalpay \
  --failover-policy Automatic \
  --grace-period 1 \
  --add-db PayrollDB
Dica 4: Active Geo-Replication para Leituras Multi-Região

Como failover groups suportam apenas um secundário, use active geo-replication para read replicas adicionais:

# Create geo-replica in southeast asia (in addition to failover group secondary in west europe)
az sql db replica create \
  --resource-group rg-globalpay \
  --server sql-globalpay-eastus \
  --name PayrollDB \
  --partner-server sql-globalpay-southeastasia \
  --partner-resource-group rg-globalpay-apac

Diferencas-chave dos failover groups:

  • Sem failover automático (deve promover manualmente)
  • Sem endpoint DNS estavel (deve tratar na aplicação)
  • Pode ter até 4 geo-replicas (vs 1 secundário de failover group)
  • Util para read-offload em regiões adicionais

Para GlobalPay: A região APAC usa geo-replica para leituras de relatórios, com procedimento de failover manual documentado como runbook (não esperado ser alvo principal de DR).

Recursos de aprendizagem​

Verificação de conhecimento​

1. A GlobalPay requer zero perda de dados durante failover. Qual tier e combinacao de recursos do Azure SQL garante RPO = 0 para falhas de zona?

Tier Business Critical com zone redundancy habilitado. Business Critical usa replicação sincrona para 3 replicas secundarias (Always On AG). Com zone redundancy, essas replicas são distribuidas entre availability zones. Toda transação deve ser confirmada em TODAS as replicas antes do cliente receber reconhecimento, garantindo zero perda de dados para qualquer falha de zona única. O tier General Purpose também suporta zone redundancy mas armazena dados em armazenamento remoto com diferentes caracteristicas de HA. Para failover cross-region, RPO e aproximadamente 5 segundos (assincrono) porque replicação sincrona entre regiões não é possível devido a latência.

2. Por que você não pode usar um failover group para fornecer failover automático para AMBOS West Europe E Southeast Asia simultaneamente?

Failover groups suportam exatamente um servidor secundário. Um failover group estabelece uma relação 1:1 entre um servidor primário é um servidor parceiro, com failover automático, endpoints DNS estaveis e movimentacao coordenada de bancos de dados. Para regiões adicionais, você deve usar active geo-replication, que fornece secundários legiveis mas requer failover manual (sem promocao automática, sem endpoint DNS estavel). O padrão recomendado e: failover group para sua região principal de DR (failover automático) + active geo-replication para regiões adicionais (failover manual, read-offload apenas).

3. Durante um failover automático de failover group, o que acontece com um processo batch de folha que tem uma transação em andamento inserindo 10.000 registros de salario?

A transação em andamento sofre rollback no antigo primário, e a aplicação deve detectar a desconexao e retentar. Quando o failover ocorre, o antigo primário se torna read-only (ou indisponível), e quaisquer transações não confirmadas sofrem rollback. O novo primário tem todas as transações previamente confirmadas (aquelas replicadas antes da falha). A aplicação recebe um erro de conexão (SQL error 40613 ou erro transiente similar), e a lógica de retry deve: reconectar ao endpoint do failover group (que agora resolve para o novo primário), detectar quais registros já foram confirmados, e retomar o batch a partir do último ponto confirmado. Isso requer design de batch idempotente com checkpointing.

4. Uma empresa define o grace period do failover group para 0 (se possível) para failover automático mais rápido. Por que o Azure impoe um mínimo de 1 hora?

O mínimo de 1 hora previne perda de dados de failover prematuro durante problemas de rede transientes. Se o grace period fosse 0, uma breve particao de rede entre o primário e secundário acionaria failover imediato para o secundário, que pode não ter recebido as transações mais recentes (defasagem de replicação de até 5 segundos). O grace period de 1 hora garante que interrupcoes transientes (blips de rede, manutenção breve) se resolvam sem acionar failover. Apenas interrupcoes sustentadas (> 1 hora) acionam failover automático, ponto no qual o risco de perda de dados (até 5 segundos de transações) e aceito como o custo de restaurar disponibilidade.

Limpeza​

# Delete resources in reverse dependency order
az sql failover-group delete \
  --resource-group rg-globalpay \
  --server sql-globalpay-eastus \
  --name fg-globalpay

az group delete --name rg-globalpay --yes --no-wait
az group delete --name rg-globalpay-europe --yes --no-wait
az group delete --name rg-globalpay-apac --yes --no-wait

Próximo: Challenge 32: Design High Availability for Non-Relational Data