CentOS上装SqlServer 2019启动报错排查
<p>最近在CentOS8上安装的SqlServer 2019时不时就挂掉了，重新启动服务也无效，重启CentOS后有效了一段时间后又无法启动。<br>使用systemctl命令查询SQL server的状态</p>
<pre><code class="language-shell">systemtcl status mssql-server
</code></pre>
<p>状态信息：</p>
<pre><code>● 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: mssql-server.service: Main process exited, code=killed, status=6/ABRT
systemd: mssql-server.service: Failed with result 'signal'.
systemd: mssql-server.service: Service RestartSec=100ms expired, scheduling restart.
systemd: mssql-server.service: Scheduled restart job, restart counter is at 3.
systemd: Stopped Microsoft SQL Server Database Engine.
systemd: mssql-server.service: Start request repeated too quickly.
systemd: mssql-server.service: Failed with result 'signal'.
systemd: Failed to start Microsoft SQL Server Database Engine.
</code></pre>
<p>重新启动服务发现有提示使用journalctl命令查看日志明细信息</p>
<pre><code>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.
</code></pre>
<p>于是使用该命令查下mssql-server服务的日志</p>
<pre><code>journalctl -u mssql-server
</code></pre>
<p>翻到最后一页，发现一个错误信息</p>
<pre><code>sqlservr: Unable to read instance id from /var/opt/mssql/.system/instance_id: No such file or directory
</code></pre>
<p><img src="https://img2020.cnblogs.com/blog/418139/202010/418139-20201027180428770-1667808201.png" alt="" loading="lazy"></p>
<p>/var/opt/mssql/.system/instance_id 无法读取该文件，是不是权限设置不对呢，使用xshell查看下权限<br>
发现是有读取权限的<br>
<img src="https://img2020.cnblogs.com/blog/418139/202010/418139-20201027175004822-1701506287.png" alt="" loading="lazy"></p>
<p>使用关键词搜索，发现官方文档说明：</p>
<p>https://support.microsoft.com/zh-cn/help/4078097/kb4078097-newsequentialid-generates-duplicate-guid-after-restarting-sq</p>
<blockquote>
<p>症状</p>
<blockquote>
<p>假设你使用 NEWSEQUENTIALID （） 函数为 Linux 上的 SQL Server 2017 中的表生成唯一 GUID。 重新启动 SQL Server 后， NEWSEQUENTIALID （） 函数可能会生成 guid，该 guid 是此函数生成的以前的 guid 的副本。</p>
</blockquote>
</blockquote>
<blockquote>
<p>更多信息</p>
<blockquote>
<p>Linux 上的 SQL Server 在/var/opt/mssql/.system/instance_id 中存储顺序 UUID 种子，并在启动期间递增它。 备份 instance_id 文件，以防系统出现故障。 如果文件丢失，则缺少种子，并且会重新生成新的种子。 初始种子生成基于随机位模式和 UUID，以避免冲突。 但是，在种子丢失后，必须按顺序排序的新种子不会按顺序排列。</p>
</blockquote>
</blockquote>
<p>也就是说instance_id该文件是用来生成唯一GUID的，在网上又查到一篇文章说把instance_id文件删除即可，先备份到本地，再删除instance_id，然后重启服务，发现已经启动成功了。<br>
<img src="https://img2020.cnblogs.com/blog/418139/202010/418139-20201027180559204-1843902993.png" alt="" loading="lazy"></p>
<p>刷新下/var/opt/mssql/.system/目录，发现已经生成了一个新的instance_id文件，对比原来的文件，区别就是第一行多了一个GUID的字符串，说明报错的无法读取instance_id文件的意思是无法获取该文件的GUID，删除后会重新生成一个带GUID的文件。<br>
<img src="https://img2020.cnblogs.com/blog/418139/202010/418139-20201027180908576-1441000080.png" alt="" loading="lazy"></p><br><br>
来源：https://www.cnblogs.com/townsend/p/13886391.html
頁:
[1]