Ao testar uma atualização do SQL Server 2014 SP1 (12.0.4422.0) para o SQL Server 2016 CTP 3.2 (13.0.900.73), eu estava seguindo o processo de atualização recomendado e encontrei um problema em que o banco de dados não iniciava no primário antigo após o failover para o secundário atualizado. Nossa configuração é uma réplica primária e uma única réplica secundária, e as etapas que concluí foram:
- Remova o failover automático na réplica secundária de confirmação síncrona
- Faça upgrade das instâncias do servidor secundário para a nova versão
- Failover manualmente para a réplica secundária
- Verifique se os bancos de dados estão online na nova réplica primária
- Atualize a réplica primária anterior para a nova versão
A atualização do secundário e o failover para torná-lo o primário funcionaram exatamente como esperado. Mas depois de atualizar a réplica anteriormente primária, notei que os bancos de dados nela estavam listados no SSMS como Not Synchronizing / In Recovery . Também tentar acessá-los geraria uma mensagem de erro:
O banco de dados... não está acessível. (Explorador de Objetos)
Verificando através dos logs do SQL Server que vi
Não é possível abrir o banco de dados '...' versão 782. Atualize o banco de dados para a versão mais recente.
Consultar a tabela master..sysdatabases mostrou que realmente era uma versão mais antiga e não havia sido atualizada durante a atualização:
Infelizmente, os logs não indicaram por que não foi atualizado, e o Painel de Grupos de Disponibilidade forneceu apenas um aviso genérico indicando que o estado de sincronização de dados de algum banco de dados de disponibilidade não está íntegro sem motivo.
Eu tentei usar o TSQL para desanexar os bancos de dados ou defini-los offline para "chutá-lo" para atualização, mas como eles fazem parte do SQL AG, esses comandos não funcionam.
Como posso atualizar o banco de dados para a versão mais recente quando ele faz parte de um SQL AG?
Depois de bisbilhotar o SSMS por um tempo, notei que na réplica secundária havia um ícone de pausa ao lado dos bancos de dados de disponibilidade. O primário mostrou que ambos eram "verdes", mas havia uma opção no secundário para Retomar Movimentação de Dados . Retomei o primeiro banco de dados e imediatamente a mensagem de status In Recovery foi removida. Um minuto depois, mudou de Não Sincronizando para Sincronizado e tudo funcionou como esperado.
Aqui está uma captura de tela dos bancos de dados AG depois de corrigir "Patch", mas antes de corrigir o banco de dados de teste:
Observe que você também pode usar o TSQL no secundário para retomar a replicação em vários bancos de dados ao mesmo tempo: