Eu gostaria de receber alguns conselhos, por favor.
Preciso corrigir um ambiente do SQL 2019 Availability Group com duas réplicas locais.
Alto nível de medidas que pretendo tomar:
- Alterar o modo de failover de automático para manual no primário
- Corrigir réplica secundária primeiro
- Failover do AG para o secundário corrigido
- Corrigir o novo secundário (ou seja, o antigo primário)
- failback para o primário antigo
É realmente essencial alterar o modo de confirmação síncrono para assíncrono no primário antes de começar?
Minha preocupação em fazer isso é que a instância em questão tem mais de 300 bancos de dados, alguns dos quais são muito grandes. Se eu alterar o modo de disponibilidade para assíncrono, quando eu terminar de aplicar patches no secundário e fizer failover do AG para o secundário corrigido, precisarei retomar a movimentação de dados no novo secundário (ou seja, o antigo primário) em cada banco de dados . Para uma instância com mais de 300 bancos de dados, esse é um processo demorado.
A minha pergunta é, portanto:
- Se eu conseguir garantir um tempo de inatividade para a tarefa e não tiver transações acontecendo durante o processo de patch, é seguro continuar o processo sem mudar para o modo de confirmação assíncrona? Nesse caso, tudo o que preciso fazer é mudar para failover manual, aplicar patch no secundário, fazer failover para o secundário corrigido, aplicar patch no novo secundário (ou seja, primário antigo) e fazer failback para o primário antigo.
Além disso, se por qualquer motivo eu não conseguir garantir o tempo de inatividade para a tarefa, e o primário estiver em uso enquanto o secundário estiver sendo corrigido. Correrei o risco de perda de dados se deixar o modo de disponibilidade como síncrono durante o processo de correção?
Por favor, informe-nos.
obrigado.
Espero que você tenha lido o guia da Microsoft sobre Atualizar réplicas de grupos de disponibilidade .
É essencial alterar o modo de confirmação síncrono para assíncrono no primário antes de começar?
Do link acima:
Desde que você esteja totalmente sincronizado entre as réplicas, a parte crítica é "Remover failover automático em todas as réplicas de confirmação síncrona".
Para uma instância com mais de 300 bancos de dados, esse é um processo demorado.
Você testou isso com um script TSLQL em vez de usá-lo individualmente na GUI?
Se eu conseguir garantir um tempo de inatividade para a tarefa e não tiver transações acontecendo durante o processo de patch, é seguro continuar o processo sem mudar para o modo de confirmação assíncrona? Nesse caso, tudo o que preciso fazer é mudar para failover manual, aplicar patch no secundário, fazer failover para o secundário corrigido, aplicar patch no novo secundário (ou seja, primário antigo) e fazer failback para o primário antigo.
Sim.
Não consigo garantir tempo de inatividade para a tarefa, e o primário está em uso enquanto o secundário está sendo corrigido. Correrei risco de perda de dados se deixar o modo de disponibilidade como síncrono durante o processo de correção?
Não, desde que você altere o failover automático para manual para evitar failover acidental. Os logs de transação não serão truncados, a menos que suas transações sejam copiadas para todas as réplicas secundárias.