Temos um AG de 4 nós configurado em dois data centers usando 4 réplicas com uma testemunha de compartilhamento de arquivos. Os nós 1 e 2 estão no datacenter 1 e os nós 3 e 4 no datacenter 2. O nó 1 é primário e está configurado para confirmação síncrona com failover automático para o nó 2 no mesmo datacenter. O nó 1 é configurado para confirmação assíncrona para os nós 3 e 4 no datacenter 2. A ponderação do nó é configurada para um para os nós 1 e 3 (nó principal em cada datacenter) e zero para os nós 2 e 4.
Por favor, alguém pode me dizer qual seria o comportamento se tivéssemos um SQL Server inesperado desligado no nó 1?
O AG tentaria fazer failover para o nó 3 no data center 2 devido à ponderação do nó, falharia e não tentaria fazer failover para outras réplicas. Ou o grupo AG ignoraria o nó 3 por ser assíncrono e tentaria fazer failover para a primeira réplica síncrona com failover automático com base na lista do proprietário preferencial?
A configuração descrita no tópico original é um pouco estranha. Existem dois grupos de recursos SYSTEM (CNO, CNO_VIP1, CNO_VIP2, FSW ) e AG (LISTENER, LISTENER_VIP1, LISTENER_VIP2, AG).
Esses dois grupos de recursos podem pertencer a diferentes nós WSFC. Por exemplo , SYSTEM é de propriedade do nó do DC 2 e AG é de propriedade do nó do DC 1 . Neste caso, se o link entre DC1 e DC2 estiver quebrado:
De acordo com a configuração de quórum, a parte DC 2 ficará viva (devido à maioria dos votos) e a DC 1 morrerá (devido à minoria de votos). Mas assim que a sincronização entre DC1 e DC2 for assíncrona, não haverá failover automático para DC2.
Assim, você terminará com a situação quando o DC2 estiver ativo, mas não puder lidar com a carga de trabalho do banco de dados, porque o AG aguardará a intervenção manual (allow_data_loss).
Para evitar tal situação, você precisa atribuir votos assim
DC1:
NÓ1: 1
NÓ2: 1
SINCRONIZAÇÃO ASYNC
DC2
NÓ3: 0
NÓ4: 0
Nessa configuração, o AG fará failover para o NODE2 (DC1).
É melhor você explicar o propósito do DC2. É o DC de recuperação de desastres ou você precisa dele para escala de leitura ou ambos?
O failover aconteceria e o failover estaria de acordo com a ordem em que os nós foram adicionados aos grupos de disponibilidade e configurados para failover automático. Como abaixo (Todas as imagens retiradas deste blog do MSDN
Este é o SQL Server 2016, onde você tem a opção de definir 3 réplicas com failover automático. Agora, o usuário adicionou réplicas de modo que o Nó 2 e o Nó 3 foram adicionados um após o outro. Agora, neste caso, se o Node1 ficar inativo, ele fará o failover para o Node 2. A sequência exata de failover pode ser vista na GUI do WSFC. Para este AG seria como abaixo
Isso informa a sequência de failover automático. se o nó 1 ficar inativo, ele fará failover automaticamente para o nó 2 e, se o nó 2 ficar inativo, fará failover automaticamente para o nó 3, assumindo que o WSFC estava ativo e fez o failover corretamente.
O peso do nó não entraria em cena aqui. Eu não tenho ideia de como você configurou o AG, então vá em frente, olhe para a GUI do cluster e você pode ver a ordem em que ele faria o failover.
Como falamos sobre o peso do nó, sugiro que você mantenha o peso do nó para réplicas de DR como 0, isso fará com que o número de votos no cluster seja ODD. 2 nós em DC e 1 testemunha FS. Você não gostaria que DR participasse da votação que está em algum lugar longe e dificilmente tem ideia