Cenário: SQL Server 2014 CU6. 1 AG com 2 bancos de dados (nível de compatibilidade 100). Cluster de failover com 3 nós no Windows Server 2012 R2. Réplica de disponibilidade primária no nó 1 e nó 2. Réplica de disponibilidade secundária no nó 3 (sem votos). Confirmação assíncrona, failover manual, secundário legível. O nó 3 é usado para executar relatórios nesses 2 bancos de dados (dos 8 bancos de dados executados fora do AG nos nós 1 e 2).
Problema: procurando corrigir isso do SQL 2014 para o SP1 e o CU mais recente. Não é minha construção e nenhuma experiência com AG ou FC até agora. Meu ambiente de "teste" também é usado para desenvolvimento, então não há espaço para erros.
Perguntas:
Qual é a melhor ordem para corrigir os 3 nós?
Primeiro preciso remover os bancos de dados do AG no nó que estou corrigindo?
Preciso remover o Secundário ao corrigi-lo?
Não tenho experiência nisso e não consigo encontrar respostas claras para o meu cenário (talvez sem suporte?) nos documentos: https://msdn.microsoft.com/en-us/library/dn178483(v=sql.120) .aspx
O cenário é chamado e suportado no link que você forneceu.
Grupo de Disponibilidade com Uma Réplica Secundária Remota
Se você implantou um grupo de disponibilidade apenas para recuperação de desastres, pode ser necessário fazer failover do grupo de disponibilidade para uma réplica secundária de confirmação assíncrona. Tal configuração é ilustrada pela figura a seguir:
Atualização do grupo de disponibilidade no cenário de DR
Nessa situação, você deve fazer failover do grupo de disponibilidade para a réplica secundária de confirmação assíncrona durante o upgrade/atualização sem interrupção. Para evitar a perda de dados, altere o modo de confirmação para confirmação síncrona e aguarde a sincronização da réplica secundária antes de fazer o failover do grupo de disponibilidade. Portanto, o processo de atualização/atualização sem interrupção pode ter a seguinte aparência:
1. Atualize/atualize o servidor remoto
2.Altere o modo de confirmação para confirmação síncrona
3. Aguarde até que o estado de sincronização seja SINCRONIZADO
4. Failover do grupo de disponibilidade para o site remoto
5. Atualize/atualize o servidor local (site primário)
6. Failover do grupo de disponibilidade para o site primário
7.Altere o modo de confirmação para confirmação assíncrona
A documentação foi atualizada desde então e sinto que a resposta abaixo é perfeita para o meu cenário:
Remova o failover automático em todas as réplicas de confirmação síncrona
Atualize todas as instâncias de réplica secundária remota executando réplicas secundárias de confirmação assíncrona
Atualize todas as instâncias secundárias da réplica local que não estão executando a réplica primária no momento
Failover manualmente do AG para uma réplica secundária local de confirmação síncrona
Atualize ou atualize a instância de réplica local que anteriormente hospedava a réplica primária
Configure os parceiros de failover automático conforme desejado
Se necessário, você pode executar um failover manual extra para retornar o AG à sua configuração original.
Tornar o secundário assíncrono é importante, pois quando ele desaparece, o primário não será capaz de proteger a transação no secundário e aguardará 30 segundos ou o tempo de pulsação. Faça Async para permitir commits nos primeiros 30 segundos.
A documentação ! não parece exigir que o secundário esteja no modo ASYNCH, no entanto. Apenas diz definido como failover "MANUAL". Na seção "NOTA".
"Atualizar uma réplica de confirmação síncrona e colocá-la offline não atrasará as transações na réplica primária. Depois que a réplica secundária é desconectada, as transações são confirmadas na primária sem esperar que os logs sejam protegidos na réplica secundária."