截断 MSSQL 事务日志

症状

仅当启用 你的 GitHub Enterprise Server 实例 时，MSSQL 才会在 GitHub Actions 上运行。 当其事务日志增长过大时，可能会看到以下任一内容。

• 数据磁盘使用量稳步攀升，不会下降。
• MSSQL 报告错误，指出数据库的事务日志已满。
• 自托管运行器无法注册。 单个事务日志不能超过 2 TB，一旦达到该限制，写入该数据库就会失败。
• MSSQL 复制失败，或花费的时间比预期要长得多。

原因

每个 MSSQL 数据库都有一个以 .mdf 结尾的数据文件和一个文件名以 _log.ldf 结尾的事务日志。 每次更改都会首先写入事务日志。

在高可用性配置中，数据库在完整恢复模式下运行，复制需要该模式。 在该模型中，日志空间仅在备份运行时可重用。 如果备份运行频率不够或失败，则日志文件会不断扩展以保存新记录。 它将增长到填满数据磁盘，或直到达到每个文件 2 TB 的限制（以先发生者为准）。

确认问题

1. 通过 SSH 连接到管理 shell。 有关详细信息，请参阅“访问管理 shell (SSH)”。

2. 列出 MSSQL 数据目录。

   sudo ls -lth /data/user/mssql/data
   

3. 将每个 .mdf 数据文件与其匹配的 _log.ldf 事务日志进行比较，并确定哪些文件使用最多的空间。

   大型 _log.ldf 文件本身无法证明截断失败。 截断会使文件内的空间可重用，它不会收缩文件，因此已成功截断的日志仍可能很大。 列表会告诉你哪些文件占用了磁盘空间。

   -rw-r----- 1 mssql mssql 156G Apr 17 02:52 Mps_cf856db1-88f0-412a-b35d-8df36a8350ac_log.ldf
   -rw-r----- 1 mssql mssql  72M Apr 17 02:52 Mps_cf856db1-88f0-412a-b35d-8df36a8350ac.mdf
   -rw-r----- 1 mssql mssql 836M Apr 17 02:52 Pipelines_45f96584-c933-460c-8706-5d8928261202_log.ldf
   -rw-r----- 1 mssql mssql  72M Apr 17 02:52 Pipelines_45f96584-c933-460c-8706-5d8928261202.mdf
   -rw-r----- 1 mssql mssql 3.4G Apr 17 02:58 Mps_Configuration_log.ldf
   -rw-r----- 1 mssql mssql 136M Apr 17 02:58 Mps_Configuration.mdf
   

   此处的每个日志文件都比其数据文件大五倍以上，这远远超出了正常增长。 在此示例中，第一个日志文件相比 72 MB 的数据文件为 156 GB，因此它是填满磁盘的日志文件。

解决问题

下面的过程暂时将数据库切换到 SIMPLE 恢复模式，该模式允许截断事务日志，然后再切回 FULL 恢复模式。

按照符合您的环境的过程操作。 两者不同，因为复制依赖于 FULL 恢复模式，因此，在高可用性配置中，必须先禁用复制，才能截断日志。

高可用性环境

如果 你的 GitHub Enterprise Server 实例 有一个或多个副本，请使用此过程。 在主服务器上运行每个命令。

1. 使用配置的备份解决方案执行手动备份。

   ghe-backup
   

   如果未配置备份解决方案，请改为导出 MSSQL 数据库。

   ghe-export-mssql --compress --stats 1
   

2. 记录当前文件大小，以便之后可以确认文件大小是否减小。

   sudo du --all --human-readable /data/user/mssql/data
   

3. 截断事务日志。 这会在每个副本上禁用 MSSQL 复制，删除可用性组，将数据库切换到 SIMPLE 恢复模式，并收缩日志。

   sudo /usr/local/share/enterprise/ghe-mssql-shrinkfile --disable-mssql-replication --set-simple-recovery-model
   

4. 确认文件变小了。

   sudo du --all --human-readable /data/user/mssql/data
   

5. 检查 MSSQL 容器是否正常。

   ghe-actions-check -s mssql
   

6. 重新启用 MSSQL 复制。 这会重新创建可用性组并还原 FULL 恢复模式。

   ghe-cluster-each --serial --exclude --role mssql -- /usr/local/share/enterprise/ghe-repl-start-mssql
   

7. 监视播种过程，直到副本同步。在播种过程完成之前，副本不包含任何 MSSQL 数据。

   与上述步骤不同，请在每个副本而不是主副本上运行此操作。

   ghe-repl-status
   

多个独立环境

如果 你的 GitHub Enterprise Server 实例 没有副本，请使用此过程。

1. 使用配置的备份解决方案执行手动备份。

   ghe-backup
   

   如果未配置备份解决方案，请改为导出 MSSQL 数据库。

   ghe-export-mssql --compress --stats 1
   

2. 记录当前文件大小。

   sudo du --all --human-readable /data/user/mssql/data
   

3. 截断事务日志。 这会将数据库切换到 SIMPLE 恢复模式并收缩日志。

   sudo /usr/local/share/enterprise/ghe-mssql-shrinkfile --set-simple-recovery-model
   

4. 确认文件更小了。

   sudo du --all --human-readable /data/user/mssql/data
   

5. 检查 MSSQL 容器是否正常。

   ghe-actions-check -s mssql
   

6. 进行全新备份。 这会恢复为 FULL 恢复模式。

   ghe-export-mssql --compress --stats 1
   

   警告

   在独立实例上，不会自动恢复为 FULL 恢复模式。 必须进行此备份。 如果数据库保留在 SIMPLE 恢复模式下，则会在每个检查点截断事务日志，如果以后添加副本，复制将失败。

防止再次发生

事务日志由备份清除，因此日志仅在备份可靠运行时保持合理的大小。

• 按计划运行备份，并检查它们是否已完成。 有关详细信息，请参阅“配置备份计划”。
• 监视数据磁盘使用情况，以便在磁盘写满之前看到日志增长。 有关详细信息，请参阅“建议的警报阈值”。
• 在备份失败的任何时间段后，请再次检查文件大小，因为日志在此期间已经增大。

联系 GitHub 支持

如果这些步骤无法解决问题，或者您不确定其中任何一步该如何操作，请联系 GitHub 支持，而不要继续。 有关详细信息，请参阅“创建支持工单”。

如果已打开支持工单，附加支持包有助于 GitHub 支持 更快地诊断问题。 有关详细信息，请参阅“向GitHub支持提供数据”。

延伸阅读

• 增加存储容量