Falar comigo

Blog

Mas que CU (Cumulative Update), hein?!

· Administração, AlwaysOn

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.

Referências