Supondo que eu tenha AG em um cluster de 4 nós, com 2 nós no site primário e 2 nós no site de DR, 1 testemunha de nuvem. O modo failover é manual.
Agora, por algum motivo, suponha que a rede do site primário caia, especificamente, não consigo me conectar ao data center primário.
Caso 1: o primário tem quorum, pois ainda é capaz de se comunicar com a testemunha da nuvem. Como há algum problema de rede no site primário, o SQL ainda está em execução no site primário e pensa que é o primário.
Caso 2: o primário não consegue se comunicar com a testemunha da nuvem e perdeu o quorum. Testemunho dinâmico e quórum dinâmico podem entrar em ação.
Suponha que agora eu me conecte a um dos nós de DR e invoque um failover manual forçado.
O SQL no site de DR pensará que é o principal, pois invoquei o failover manual. Tecnicamente, este é um cenário de cluster dividido.
O cenário de divisão no caso 1 é óbvio. No caso 2, pode ser devido ao testemunho dinâmico e ao início do quórum dinâmico.
Quando a rede primária for restabelecida, o que preciso fazer para lidar com esse cenário? Porque se o que estou pensando estiver certo, ambos os sites pensarão que possui o servidor SQL primário.
Você também está com o cérebro dividido de propósito. Como o lado DR não terá quorum, ele precisaria ser forçado, o que significa que quando todos esses nós se comunicarem novamente, o lado primário original verá o quorum forçado e o lado primário irá imediatamente cair e reiniciar para sincronizar com os novos bancos de dados de cluster do lado de DR que foi forçado. Isto terá o efeito de derrubar o AG no lado primário. O problema é que agora você tem o potencial (embora seja quase uma garantia) de que o primário original tenha dados que o lado DR não possui devido à divisão do cérebro que você forçou.
Isso significa que você precisará reconciliar manualmente os dados e colocá-los no banco de dados de DR, a partir do banco de dados primário original. Ninguém pode lhe dizer as operações necessárias, pois serão específicas para seu banco de dados e sua empresa.
Depois que os dados tiverem sido (ou decidido não ser) reconciliados, as réplicas provavelmente precisarão ser reinicializadas porque as bifurcações de recuperação estão muito distantes umas das outras e a última bifurcação comum será a partir da data e hora em que o problema ocorreu. Como o failover forçado foi usado, os bancos de dados precisarão ter a movimentação de dados retomada ou ser completamente removidos para serem propagados automaticamente (ou você pode propagar manualmente). Você não será capaz de registrar restaurações magicamente ou qualquer coisa aqui, pois os bancos de dados se bifurcaram em seus caminhos de recuperação.
O lado primário não terá os votos, não permanecerá no poder. Se o lado DR conseguir obter acesso à testemunha, então deverá ter os votos e o quórum deverá ser alcançado. Se o failover automático estiver definido para uma réplica no local de DR, então ele deverá falhar automaticamente; caso contrário, será necessário fazer o failover normalmente (se for um parceiro de commit síncrono) ou forçado (parceiro de commit assíncrono). Em seguida, você precisará retomar a movimentação de dados em cada réplica ainda ativa no lado da DR. Dependendo de quanto tempo eles estão fora de comunicação, pode ser necessário descartar as réplicas no lado primário original.
Assim que o AG for forçado, quando as comunicações retornarem, o AG verá se foi forçado ou não. Se tiver, todas as comunicações serão feitas com os bancos de dados em cada réplica no lado primário original, presumindo que as réplicas não foram descartadas. Se estivessem, você precisará adicioná-los novamente ao AG.