CentOS上装SqlServer 2019启动报错排查

最近在CentOS8上安装的SqlServer 2019时不时就挂掉了，重新启动服务也无效，重启CentOS后有效了一段时间后又无法启动。
使用systemctl命令查询SQL server的状态

systemtcl status mssql-server

状态信息：

● mssql-server.service - Microsoft SQL Server Database Engine
   Loaded: loaded (/usr/lib/systemd/system/mssql-server.service; enabled; vendor preset: disabled)
   Active: failed (Result: signal) since Tue 2020-10-27 17:26:23 CST; 8s ago
     Docs: https://docs.microsoft.com/en-us/sql/linux
  Process: 1863 ExecStart=/opt/mssql/bin/sqlservr (code=killed, signal=ABRT)
 Main PID: 1863 (code=killed, signal=ABRT)

 systemd[1]: mssql-server.service: Main process exited, code=killed, status=6/ABRT
 systemd[1]: mssql-server.service: Failed with result 'signal'.
 systemd[1]: mssql-server.service: Service RestartSec=100ms expired, scheduling restart.
 systemd[1]: mssql-server.service: Scheduled restart job, restart counter is at 3.
 systemd[1]: Stopped Microsoft SQL Server Database Engine.
 systemd[1]: mssql-server.service: Start request repeated too quickly.
 systemd[1]: mssql-server.service: Failed with result 'signal'.
 systemd[1]: Failed to start Microsoft SQL Server Database Engine.

重新启动服务发现有提示使用journalctl命令查看日志明细信息

Job for mssql-server.service failed because a fatal signal was delivered to the control process.
See "systemctl status mssql-server.service" and "journalctl -xe" for details.

于是使用该命令查下mssql-server服务的日志

journalctl -u mssql-server

翻到最后一页，发现一个错误信息

sqlservr: Unable to read instance id from /var/opt/mssql/.system/instance_id: No such file or directory

/var/opt/mssql/.system/instance_id 无法读取该文件，是不是权限设置不对呢，使用xshell查看下权限
发现是有读取权限的

使用关键词搜索，发现官方文档说明：

https://support.microsoft.com/zh-cn/help/4078097/kb4078097-newsequentialid-generates-duplicate-guid-after-restarting-sq

症状

假设你使用 NEWSEQUENTIALID （） 函数为 Linux 上的 SQL Server 2017 中的表生成唯一 GUID。 重新启动 SQL Server 后， NEWSEQUENTIALID （） 函数可能会生成 guid，该 guid 是此函数生成的以前的 guid 的副本。

更多信息

Linux 上的 SQL Server 在/var/opt/mssql/.system/instance_id 中存储顺序 UUID 种子，并在启动期间递增它。 备份 instance_id 文件，以防系统出现故障。 如果文件丢失，则缺少种子，并且会重新生成新的种子。 初始种子生成基于随机位模式和 UUID，以避免冲突。 但是，在种子丢失后，必须按顺序排序的新种子不会按顺序排列。

也就是说instance_id该文件是用来生成唯一GUID的，在网上又查到一篇文章说把instance_id文件删除即可，先备份到本地，再删除instance_id，然后重启服务，发现已经启动成功了。

刷新下/var/opt/mssql/.system/目录，发现已经生成了一个新的instance_id文件，对比原来的文件，区别就是第一行多了一个GUID的字符串，说明报错的无法读取instance_id文件的意思是无法获取该文件的GUID，删除后会重新生成一个带GUID的文件。