Configurar:
Alta disponibilidade básica
2 réplicas (1 primária, 1 secundária).
DB01 => primário inicial.
DB02 => secundário inicial
Confirmação síncrona em ambos
Ambos estão em estado sincronizado
Não há ouvinte configurado
Tipo de cluster Nenhum
Quando paramos o serviço SQL DB01 (inicial e primário atual) usando services.msc (simulando uma falha amigável do servidor) e iniciamos um failover forçado no DB02 (inicial e secundário atual) usando:
ALTER AVAILABILITY GROUP [TestHA] FORCE_FAILOVER_ALLOW_DATA_LOSS;
O banco de dados secundário fica online, que é o que queremos.
No entanto, quando o serviço DB01 SQL Server é iniciado novamente, usando services.msc, o banco de dados DB01 assume novamente a função primária .
Portanto, atualmente existem 2 instâncias legíveis/graváveis e fora de sincronia. Esperávamos que o primário inicial detectasse que um secundário assumiu a função primária e assumisse uma função secundária ou pelo menos ficasse inacessível para que os aplicativos não funcionassem com dados antigos.
O mesmo procedimento, mas usando a configuração de espelho obsoleta, se comporta dessa maneira.
Como esse é um grupo de disponibilidade sem cluster (escala de leitura), não há nada coordenando automaticamente em qual função cada nó está - esse processo é totalmente manual.
É por isso que o antigo primário volta a ser o primário - nada lhe disse para mudar seu papel.
Você vai querer seguir as instruções descritas aqui:
Failover da réplica primária em um grupo de disponibilidade de escala de leitura - Failover manual forçado com perda de dados
No final, você pode adicionar manualmente o antigo primário como secundário: