Posted by Falaê, blz?!
Hoje venho aqui, pela primeira vez, compartilhar um pouco da experiência curiosa que tive ao atualizar uma CU no SQL Server. Dá uma olhada e deixa seu feedback pra mim! ;D
Agradeço aos meus parceiros Leandro Sampaio e Renato Siqueira da DataSide por estarem comigo nesse dia maluco.
O ambiente
- Azure
- 3 Servidores Windows 2016 Datacenter
- 3 Instâncias SQL Server 2017 Enterprise CU18
- 2 AlwaysON Availability Groups:
- AG1: Nós 1, 2 e 3
- AG2: Nós 2 e 3
O caso
As CUs (Cumulative Updates) do SQL Server são lançadas com certa frequência e somos sempre instruídos a manter as instâncias o mais atualizadas possível para corrermos menos riscos de segurança, bugs, performance ruim, etc. além de termos diversas melhorias frequentemente.
Baseado nisso, que é a própria Microsoft, fabricante do SGBD, quem recomenda, resolvemos aplicar a devida CU (24) no ambiente.
Vale ressaltar que desde o SQL Server 2017 a Microsoft não libera mais Service Pack, somente os pacotes de Cumulative Update.
NEVES, Tiago - Outubro de 2020
Seguindo o processo que sempre usei (Descrevo isso no próximo tópico) e que também é recomendado pela "Mãecrosoft" e alguns mestres da comunidade , fizemos a instalação da CU na réplica menos crítica do AG, usada somente para alguns reports pontuais e Disaster Recovery, com a ideia de em seguida aplicar nas demais instâncias. Ou seja, esse nó fica a maior parte do tempo em stand by e a réplica é assíncrona.
O processo
- Análise e download da CU a ser instalada;
- Instalação em um ambiente de testes;
- Análise do dashboard para garantir que todo o ambiente está saudável antes da instalação;
- Backup dos bancos de dados de sistema;
- Backup dos bancos de dados do usuário;
- Failover. Nesse caso não foi necessário por ser uma instância secundária;
- Suspender a movimentação de dados para este node. Já vi gente fazer e já fiz sem isso e deu bom também. Fica a critério;
- Instalação do patch;
- Restart da instância;
- Retomar a movimentação de dados.
O susto e o troubleshooting
Ao final da instalação, fomos checar o "healthly dashboard" dos grupos e...ué?! Cadê os AGs?
A partir daí, a conversa foi mais ou menos assim:
Leandro: Calma! Dá uma olhada nos bds, Douglas.
Douglas: Uuumm...a grande maioria em "Restoring" e alguns em "Suspect".
Aaa...talvez esteja só demorando pra voltar. Obs.: A negação no desespero é demais...
1 minuto depois:
Eita! Demorou muito.
Chamamos o Renato:
Renato: Vamos reiniciar a instância. Nada!
Reinicia a máquina então?! Mesma coisa!
Douglas: Vou checar o WSFC e o Cluster Events. Com exceção do node 3 down, tudo normal e nada esclarecedor no log.
Ai ai ai...
Renato: Perae! Dá um "SELECT @@SERVERNAME".
BINGO!
Depois da instalação da CU, o SQL Server, misteriosamente, assumiu o nome do host que estava na azure e não o "nome de rede" do servidor.
Imagina assim: O recurso na azure tem o nome de VM-SQL-03 mas no AD foi registrado como AZR-SQL-03. Entendeu agora?
Quando isso aconteceu, o node deixou de ser participante do AlwaysOn porquê o nome que ele conhecia não existia mais.
A partir disso, fizemos o seguinte:
- Imediatamente, paramos os backups de log nos nós primários a tempo para evitar uma dessincronização maior;
- Removemos o server, registrado na sys.servers, com o nome incorreto:
EXEC sp_dropserver 'VM-SQL-03' - Adicionamos novamente com o nome correto:
EXEC sp_addserver 'AZR-SQL-03' - Removemos o node dos AGs;
- Incluímos novamente com a opção de join only. E BOA! Praticamente todos os bds que estavam em restoring voltaram a vida. Deletamos os que se negaram e fizemos o automatic seeding. AEEE...tá quase!;
-
E os que estavam em suspect? Restauramos eles com a ajuda da magnífica dba-tools e aqui fica um ponto fantástico do backup no SQL Server + Azure. Nosso job de backup aponta diretamente para a Azure por meio de uma url. Assim, para baixá-los ou fazer o restore direto da nuvem, precisamos recuperar a url de cada um deles. Dá uma olhada nisso, que legal (Funciona também se não for cloud):
$MeuBackup = Get-DbaDbBackupHistory ` -SqlInstance 'AZR-SQL-03' ` -Database 'MeuDB' ` -Last $MeuBackup.FullName <# # Depois: RESTORE DATABASE MeuDB FROM URL = 'URL do MEUDB.bak' #> -
"Resume" neles:
ALTER DATABASE MeuDB SET HADR AVAILABILITY GROUP = AG01; ALTER DATABASE MeuBD SET HADR RESUME; - Pronto! Depois de ~6h, ambiente recuperado! Uffaa...menos mal que não era "Produção" de fato e nenhuma aplicação foi afetada.
Mas e agora...
Antes de seguirmos com a instalação nos demais nodes, resolvemos abrir um chamado na Microsoft.
Explicamos o caso detalhadamente, enviamos diversos logs gerados por uma ferramenta que eles nos forneceram, backup do master, etc. e mesmo assim eles não conseguiram simular a mesma falha. Pelo menos conseguiram identificar no log que, para a instância, o server realmente mudou de nome:
AZR-SQL-03_MSSQLSERVER_1033_ERRORLOG
2021-06-16 03:29:57.32 spid6s Server name is 'AZR-SQL-03'. This is an informational message only. No user action is required.
AZR-SQL-03_MSSQLSERVER_1033_ERRORLOG.1
2021-06-16 03:11:42.04 spid6s Server name is 'VM-SQL-03'. This is an informational message only. No user action is required.
AZR-SQL-03_MSSQLSERVER_1033_ERRORLOG.2
2021-06-16 03:00:53.47 spid6s Server name is 'VM-SQL-03'. This is an informational message only. No user action is required.
AZR-SQL-03_MSSQLSERVER_1033_ERRORLOG.3
2021-06-16 02:42:54.12 spid5s Server name is 'VM-SQL-03'. This is an informational message only. No user action is required.
AZR-SQL-03_MSSQLSERVER_1033_ERRORLOG.4
2021-06-16 02:41:16.07 spid5s Server name is 'VM-SQL-03'. This is an informational message only. No user action is required.
AZR-SQL-03_MSSQLSERVER_1033_ERRORLOG.5
2021-05-15 13:03:07.59 spid6s Server name is 'AZR-SQL-03'. This is an informational message only. No user action is required.
AZR-SQL-03_MSSQLSERVER_1033_ERRORLOG.6
2021-05-07 03:43:57.87 spid6s Server name is 'AZR-SQL-03'. This is an informational message only. No user action is required.Também tentei simular no meu lab e correu tudo bem.
A única justificativa que imaginamos foi alguém, manualmente, ter feito a mudança do nome do servidor algum tempo antes da atualização mas as poucas pessoas com esse acesso (E, digasse de passagem, conhecimento também) negaram ter feito essa alteração.
A fabricante ainda não fechou o chamado. Seguimos no aguardo de algo menos assustador.
E você? Qual sua experiência mais legal aplicando patchs de atualização? Ou o que faria de diferente nesse processo todo? Deixa aqui nos comentários.
Fala Douglas, ótimo post!
Realmente eu nunca vi nada do tipo até então, realmente é estranho, principalmente pro nome que acabou voltando para um padrão digamos “de fábrica”.
Certamente vai ajudar alguém seu post. Qualquer novidade sobre o caso conta pra gente também.
Obs: Eu já tive umas experiências “legais” com aplicação de patch inclusive na mesma semana que rolou esse do AG, mas sem dúvida esse foi o mais estranho.
Abs!
Valeu pelo apoio Renatão!
Pois é! Foi uma das coisas mais bizarras que já vi de perto no SQL Server. Ainda bem que não estava sozinho porquê ninguém acreditaria. rs