O Database Mirroring no SQL Server (introduzido no SQL Server 2005) foi, por muitos anos, a forma mais simples de alta disponibilidade “sem storage compartilhada”, mantendo uma cópia sincronizada de uma base por vez e permitindo failover (inclusive automático com witness). Porém, trata-se de um recurso em modo de manutenção e com aviso de remoção futura, sendo recomendado planejar migração para Always On Availability Groups (HADR), que traz uma alternativa de nível enterprise ao mirroring: failover de conjuntos de bases, múltiplas réplicas secundárias e possibilidade de leitura (read-only) e offload de backups em secundárias.
Pontos-chave
- Mirroring (SQL Server 2005+): alta disponibilidade por base (uma base por sessão), com sincronismo via log e opção de witness para failover automático.
- Limitação crítica do mirror: a base secundária fica indisponível para leitura (modo restoring) na abordagem clássica e o failover é por base, não por grupo.
- Always On Availability Groups (SQL Server 2012+): alternativa enterprise ao mirroring: failover de um conjunto de bases, até 1–8 réplicas secundárias e secundárias podem ser read-only e usadas para algumas rotinas de backup.
- Pré-requisito chave do Always On: em cenários tradicionais de HA, as réplicas participam de um WSFC (Windows Server Failover Cluster).
SQL Server Mirroring vs Always On (HADR/HADRON): o que muda na alta disponibilidade
A cada versão do SQL Server, surgem novas capacidades — e, às vezes, uma mudança de “patamar” na forma de garantir disponibilidade. O Database Mirroring foi esse salto no SQL Server 2005, oferecendo uma solução relativamente simples para manter uma base espelhada em outra instância, sem exigir storage compartilhada, com foco em rápida recuperação.
Já o que muita gente conheceu por codinome “HADRON” (na época do ciclo do SQL Server 2012) se consolidou como Always On Availability Groups — um modelo unificado de alta disponibilidade e disaster recovery (HADR) que evolui o conceito do mirroring e substitui várias arquiteturas legadas em um desenho mais flexível.
Como o Database Mirroring funciona (na prática)
O mirroring mantém duas cópias de uma mesma base: a principal (principal), que recebe as transações, e a espelho (mirror), que aplica os registros de log enviados pela principal. É uma tecnologia por base (cada sessão de mirror protege uma base) e exige recovery model FULL.
Dependendo do modo escolhido (alta segurança / alta performance), você equilibra proteção de dados e latência. E, quando há um witness, é possível configurar failover automático em cenários suportados.
Onde o mirroring ainda faz sentido?
- Ambientes legados (SQL Server 2005–2016/2019) já padronizados em mirroring e com dependências difíceis de mudar rapidamente.
- Cenários em que você precisa de HA por base e quer simplicidade operacional (ciente do status de descontinuação futura).
Importante: a própria Microsoft sinaliza que Database Mirroring será removido em uma versão futura, recomendando Always On availability groups para alta disponibilidade.
As limitações do mirroring que pesam no dia a dia
Mesmo sendo muito útil, o mirroring traz limitações conhecidas:
- Failover por base: se você precisa proteger várias bases que “andam juntas” (aplicação depende de várias), o failover fica fragmentado (base a base).
- Secundária com uso restrito: no uso clássico, a base espelho não fica aberta para consultas de leitura do jeito que um desenho de read-scale exige.
- Rede influencia performance (sincronia): em modo síncrono, a latência entre servidores pode impactar o tempo de commit da principal.
O que é Always On Availability Groups (HADR) e por que ele supera o mirror
O Always On Availability Groups foi introduzido no SQL Server 2012 como uma solução HADR que funciona como uma alternativa enterprise ao mirroring, elevando o nível de flexibilidade do desenho: em vez de proteger uma base por vez, você protege um conjunto de bases (availability databases) que falham juntas.
Um availability group possui uma réplica primária (read-write) e de 1 a 8 réplicas secundárias (dependendo de edição e configuração), com a opção de tornar secundárias read-only e, em alguns cenários, usá-las para operações de backup suportadas.
Na configuração tradicional de alta disponibilidade on-premises, as instâncias que hospedam as réplicas residem em nós de um WSFC (Windows Server Failover Cluster), e o recurso “Always On” precisa estar habilitado nas instâncias participantes.
Comparativo rápido: Mirroring vs Always On Availability Groups
| Critério | Database Mirroring | Always On Availability Groups |
|---|---|---|
| Unidade de failover | Uma base por sessão (per-database). | Conjunto de bases falha junto (availability databases). |
| Leitura em secundária | Uso limitado na secundária (espelho) no modelo clássico. | Secundárias podem ser read-only e usadas para algumas operações. |
| Quantidade de réplicas | Principal + espelho (+ witness opcional). | 1 primária + até 8 secundárias (dependendo de edição/cenário). |
| Status do recurso | Em manutenção e com aviso de remoção futura. | Recomendado como alternativa enterprise ao mirroring para HADR. |
| Dependência de cluster | Não requer WSFC para existir (witness é outro papel). | Em HA clássico, requer WSFC (ou cenários específicos como read-scale). |
Quando migrar: sinais de que o Always On é a próxima etapa
- Sua aplicação depende de múltiplas bases e você precisa de failover “em bloco”.
- Você quer usar a secundária para leitura (relatórios, consultas pesadas) sem impactar a primária.
- Você precisa consolidar HA + DR em um desenho mais moderno, substituindo combinações de mirror + log shipping, por exemplo.
- Roadmap e suporte: você não quer ficar preso a um recurso com aviso de remoção futura.
Checklist prático (alto nível) para implantar Always On Availability Groups
- Preparar WSFC (quando aplicável): garantir nós, rede, quorum e pré-requisitos do cluster.
- Habilitar Always On: ativar o recurso nas instâncias que participarão do AG.
- Endpoints e comunicação: assegurar endpoint de database mirroring para comunicação entre réplicas.
- Definir réplicas e modos: síncrono/assíncrono, failover automático/manual, read-only routing (se necessário).
- Criar listener: padronizar conexão da aplicação via listener do availability group.
- Testar failover e operação: simular cenários de troca de papéis e validar RTO/RPO real.
Recomendações finais (sem romantizar a decisão)
Se você está em um ambiente mais antigo, o mirroring pode continuar cumprindo seu papel no curto prazo — mas o recado oficial é claro: é uma tecnologia com aviso de remoção futura e não deve ser usada em novos projetos. Para novos desenhos (ou modernização), Always On Availability Groups tende a oferecer mais flexibilidade para HA + DR e ganhos operacionais (leitura em secundária, failover em grupo e múltiplas réplicas).
Quer transformar isso em plano executável (inventário, desenho de topologia, testes de failover, monitoramento e operação 24×7)? Conheça os serviços gerenciados de infraestrutura e banco e fale com o time via canal de contato da Tripletech.
Para referência oficial e detalhes técnicos, consulte a documentação da Microsoft sobre: Database Mirroring (SQL Server) e Always On Availability Groups (visão geral).
Perguntas Frequentes
1) O mirroring “morreu”? Preciso desligar amanhã?
Não é isso. Ele continua disponível em versões atuais, mas está em manutenção e com aviso de remoção futura — ou seja, evite novos projetos e planeje migração com calma e testes.
2) Always On é “só mirroring melhorado”?
Ele é mais do que isso: é uma alternativa enterprise ao mirroring, com failover de grupos de bases, múltiplas secundárias e possibilidade de leitura em secundária.
3) Always On exige cluster?
No cenário tradicional de HA on-premises, as réplicas normalmente ficam em nós de um WSFC, e o recurso deve ser habilitado nas instâncias.
4) Posso usar a secundária para relatórios?
Sim, availability groups podem tornar secundárias disponíveis para leitura (read-only), dependendo da configuração e da edição.
5) Qual caminho mais seguro para migrar de mirroring para Always On?
O caminho recomendado envolve desenho de topologia (HA/DR), preparação do WSFC, criação do AG, listener, testes de failover e plano de cutover com janelas controladas — sempre validando RTO/RPO na prática.
Sua operação não pode parar. Proteja seu negócio hoje.
Alta disponibilidade não é “instalar e esquecer”: exige arquitetura correta, testes recorrentes, monitoramento e resposta rápida a incidentes. Se o seu SQL Server sustenta processos críticos, a Tripletech pode ajudar a desenhar e operar um ambiente resiliente — do diagnóstico ao plano de migração para Always On, com governança e suporte especializado.
