Na última segunda-feira (20/04/2020), véspera de feriado, um cliente da Power Tuning nos chamou dizendo que o seguinte erro ocorreu no SQL Server em um Ubuntu:
systemd[1]: mssql-server.service: Unit entered failed state.
systemd[1]: mssql-server.service: Failed with result ‘signal’.
systemd[1]: mssql-server.service: Service hold-off time over, scheduling restart.
systemd[1]: Stopped Microsoft SQL Server Database Engine.
systemd[1]: mssql-server.service: Start request repeated too quickly.
systemd[1]: Failed to start Microsoft SQL Server Database Engine.
systemd[1]: mssql-server.service: Unit entered failed state.
systemd[1]: mssql-server.service: Failed with result ‘start-limit-hit’.
Para quem está acostumado com Linux, este é um típico erro reportado pelo systemd (um gerenciador de serviço do Linux) quando o serviço falha ao iniciar, até esgotar as tentativas.
Como no bom e velho Windows, a alternativa aqui é analisar com mais detalhes os logs. No caso, o meu “Event Viewer” é o comando journalctl, e estou interessando em um serviço chamado mssql-server:
journalctl -u mssql-server
O log foi esse, e eu marquei as partes que mais me chamaram a atenção:
sqlservr[1202]: sqlservr: Unable to read instance id from /var/opt/mssql/.system/instance_id: Success (0)
sqlservr[1202]: This program has encountered a fatal error and cannot continue running at Mon Apr 20 23:24:16 2020
sqlservr[1202]: The following diagnostic information is available:
sqlservr[1202]: Reason: 0x00000003
sqlservr[1202]: Message: Unexpected call to legacy ABI.
sqlservr[1202]: Stacktrace: 000055a12a12e464 000055a12a12dfdf 000055a12a07266e
sqlservr[1202]: 000055a12a0bf977
sqlservr[1202]: Process: 1202 – sqlservr
sqlservr[1202]: Thread: 1463
sqlservr[1202]: Instance Id:
sqlservr[1202]: Crash Id:
sqlservr[1202]: Build stamp: 70437f6583b8ef39b1ef70539ef84690980315dc7a4436c9c40015f28610e4aa
sqlservr[1202]: Distribution: Ubuntu 16.04.5 LTS
sqlservr[1202]: Processors: 2
sqlservr[1202]: Total Memory: 8061263872 bytes
sqlservr[1202]: Timestamp: Mon Apr 20 23:24:16 2020
Pesquisando exatamente a mensagem destacada da primeira linha, eu cheguei a esta resposta do Andrew Matta no fórum msdn. Ele teve um problema parecido e sugeriu mover este arquivo instance_id. Se você notou, este arquivo fica num diretório oculto do linux (diretório que começa com . (ponto), que, neste caso, é o .system).
Então, foi isso que eu fiz! Movi o arquivo para um backup:
mv instance_id instance_id.bak
E então, reiniciei o serviço:
systemctl start mssql-server
E o serviço voltou normalmente!
Curiosamente, aqui está o conteúdo do arquivo original, antes de mover:
E aqui, está o arquivo após o restart (o sql recriou ele):
Por algum motivo, o arquivo original perdeu a primeira linha, e deveria existir algum valor lá. Infelizmente, a documentação internals do SQL Server on Linux carece de alguns detalhes. Eu busquei esse nome de arquivo e cheguei neste KB da Microsoft sobre um FIX, que de quebra ele fala um pouco mais sobre o arquivo misterioso:
Este arquivo pode conter diversas informações codificada nestes números. Conforme o artigo, uma delas parece ser a fonte do NEWSEQUENTIALID, que gera identificadores universais e sequenciais (UUID).
Outra coisa que mais me chamou a atenção foi a mensagem “Success (0)” na primeira linha log acima, que, num primeiro momento, me enganou, desviando a minha atenção dele. Eu subi um SQL 2019 em Ubuntu (e um 2017 também), e fiz algumas brincadeiras com este arquivo, mas não consegui obter exatamente a mesma mensagem:
Consegui reproduzir o problema em parte, mas ainda preciso de mais testes para identificar isso tudo.
A percepção que tive é que, quando este arquivo contém dados inválidos, ou faltantes, o SQL se atrapalha e gera um dump, e por isso estamos vendo esse monte de mensagens com binários, stacks e informações de processo. A melhor saída é fazer o backup deste arquivo e deixar o SQL criar um outro. Isso pode gerar uma inconsistência se você usa NEWSEQUENTIALID.
O que pode ter causado isso?
Uma boa pergunta. O cliente me informou que todos os dias desliga esta máquina. Então, meu melhor palpite é que, durante um dos desligamentos, o SQL Server foi interrompido abruptamente, e ele se atrapalhou quando estava mexendo nesse arquivo. De novo, isso é apenas uma suspeita minha e ainda não comprovei! Quando eu descobrir isso, eu atualizo o post.
Eu ainda não encontrei muita referência sobre este arquivo e assim que o fizer, eu irei atualizar este post. Aliás, todo o diretório .system que fica na “home” da instalação do SQL on Linux, contém uma mundo mágico que vale a pena ser explorado… Quem sabe num futuro próximo não voltamos com mais posts sobre isso aqui no blog!
Até mais!
DBA Team Leader na Power Tuning
Posts Relacionados:
Conhecendo o Processo do SQL Server no Windows e Linux – Parte 3
Conhecendo o Processo do SQL Server no Windows e Linux – Parte 2
BACKUP TO URL e o Tamanho do Backup – [1] Teoria…
Um Generalista a mais no mercado?
Entendendo o que é um banco de dados e o que faz um Administrador de Banco de dados (DBA)
Comments ( 2 )