此版本的 GitHub Enterprise Server 已于以下日期停止服务 2024-09-25. 即使针对重大安全问题，也不会发布补丁。 为了获得更好的性能、更高的安全性和新功能，请升级到最新版本的 GitHub Enterprise。 如需升级帮助，请联系 GitHub Enterprise 支持。

有关对实例的升级的已知问题

请参阅有关影响 GitHub Enterprise Server 升级过程或在完成升级后影响实例的问题的解决方法概述。

本文内容

关于 GitHub Enterprise Server 升级的已知问题

GitHub 知道以下问题，这些问题可能会影响对 GitHub Enterprise Server 新版本的升级。 有关详细信息，请参阅 GitHub Enterprise Server 发行说明中的“已知问题”。

GitHub 强烈建议定期备份实例的配置和数据。 在继续处理任何升级之前，请备份实例，然后在过渡环境中验证备份。 有关详细信息，请参阅 在实例上配置备份 和 设置暂存实例。

在 GitHub Enterprise Server 3.9 或更高版本中，由于 MySQL 8 升级，I/O 利用率增加

如果是从 GitHub Enterprise Server 3.7 或 3.8 升级到 3.9 或更高版本，则实例上的数据库软件升级会增加 I/O 利用率。 在某些情况下，这可能会影响实例的性能。

GitHub Enterprise Server 包括 InnoDB 存储引擎支持的 MySQL 数据库服务器。 GitHub Enterprise Server 3.8 及更早版本使用 MySQL 5.7。 2023 年 10 月，Oracle 将终止对 MySQL 5.7 的外延支持。 有关详细信息，请参阅 Oracle 支持网站上的 Oracle 生存期支持策略。

为了实现面向未来的 GitHub Enterprise Server 并提供最新的安全更新、bug 修复和性能改进，GitHub Enterprise Server 3.9 及更高版本使用 MySQL 8.0。 有了重新设计的 REDO 日志，MySQL 8.0 可实现更高的每秒查询数 (QPS)。 有关详细信息，请参阅 DimitriK (dim) Weblog 上的 MySQL 性能：8.0 重新设计 REDO 日志以及 ReadWrite 工作负载可伸缩性。

升级到 GitHub Enterprise Server 3.9 后，如果实例的性能出现不可接受的降级，可以从实例的监视器仪表板收集数据以确认影响。 你可以尝试缓解此问题，并且可以向 GitHub 支持 提供数据，以帮助分析并传达此更改的实际影响。

Warning

鉴于此升级的性质，请在继续处理升级之前备份实例的配置和数据。 在过渡环境中验证备份。 有关详细信息，请参阅 在实例上配置备份 和 设置暂存实例。

在进行 MySQL 升级之前收集基线 I/O 利用率数据

在升级到 GitHub Enterprise Server 3.9 或更高版本之前收集基线数据。 若要收集基线数据，GitHub 建议设置运行 3.7 或 3.8 的 GitHub Enterprise Server 暂存实例，并使用 GitHub Enterprise Server Backup Utilities 从生产实例还原数据。 有关详细信息，请参阅 设置暂存实例 和 在实例上配置备份。

可能无法模拟实例在生产环境中经历的负载。 但在暂存实例上模拟生产环境中的使用模式时收集基线数据是很有帮助的。

  1. 浏览到实例的监视器仪表板。 有关详细信息，请参阅“关于监视器仪表板”。

  2. 通过监视器仪表板监视相关图。

    • 在“进程”下，监视图中的“I/O 操作(读取 IOPS)”和“I/O 操作(写入 IOPS)”，筛选 mysqld。 这些图显示所有节点服务的 I/O 操作。
    • 在“存储”下，监视图中的“磁盘利用率(数据设备 DEVICE-ID)”。 此图显示节点的所有 I/O 操作所花费的时间量。

在 MySQL 升级后查看 I/O 利用率数据

升级到 GitHub Enterprise Server 3.9 后，请查看实例的 I/O 利用率。 GitHub 建议升级运行 3.7 或 3.8 的 GitHub Enterprise Server 的暂存实例，其中包括从生产实例还原的数据，或者将生产实例中的数据还原到运行 3.9 的新暂存实例。 有关详细信息，请参阅 设置暂存实例 和 在实例上配置备份。

  1. 浏览到实例的监视器仪表板。 有关详细信息，请参阅“关于监视器仪表板”。

  2. 通过监视器仪表板监视相关图。

    • 在“进程”下，监视图中的“I/O 操作(读取 IOPS)”和“I/O 操作(写入 IOPS)”，筛选 mysqld。 这些图显示所有节点服务的 I/O 操作。
    • 在“存储”下，监视图中的“磁盘利用率(数据设备 DEVICE ID)”和“磁盘延迟(数据设备 DEVICE ID)”。 这些图显示节点的所有 I/O 操作所花费的时间量，以及整体磁盘延迟。
      • 如果磁盘延迟显著增加，可能表明实例正在强制磁盘 IOPS 等待完成。
      • 可以通过查看图中的“磁盘挂起操作(数据设备 DEVICE-ID)”来证实针对延迟增加的观察结果，这可能指示磁盘无法充分处理所有操作。

缓解 MySQL 升级的影响

为了解决不可接受的性能下降问题，GitHub 建议采用以下解决方案。

在生产环境中测试任何缓解过程之前，请备份实例、验证备份，然后在过渡环境中测试该过程。 有关详细信息，请参阅 在实例上配置备份 和 设置暂存实例。

调整 InnoDB 的刷新方法

若要尝试缓解性能方面的影响，可以调整 InnoDB 的刷新方法，在每次写入操作后跳过 fsync() 系统调用。 有关详细信息，请参阅 MySQL 8.0 参考手册中的 innodb_flush_method。

以下说明仅适用于 GitHub Enterprise Server 3.9 及更高版本。

Warning

调整刷新方法要求实例的存储设备具有带电池后备电源的缓存。 如果设备的缓存不带有电池后备电源，则面临数据丢失的风险。

  • 如果使用本地数据中心内的虚拟化虚拟机监控程序托管实例，请查看存储规范以进行确认。
  • 如果在公有云服务中托管实例，请查阅提供商的文档或向支持团队进行咨询以确认。

  1. 通过 SSH 连接到 你的 GitHub Enterprise Server 实例。 如果实例包含多个节点，例如，如果配置了高可用性或异地复制，则通过 SSH 连接到主节点。 如果使用群集，则可以通过 SSH 连接到任何节点。 将 HOSTNAME 替换为实例的主机名，或节点的主机名或 IP 地址。 有关详细信息，请参阅“访问管理 shell (SSH)”。

    Shell
    ssh -p 122 admin@HOSTNAME

  2. 若要验证 InnoDB 的当前刷新方法，请运行以下命令。

    Shell
    ghe-config mysql.innodb-flush-no-fsync

    默认情况下，该命令会返回 false，表示实例在每次写入操作后都会执行 fsync() 系统调用。

  3. 若要将 InnoDB 配置为在每次写入操作后跳过 fsync() 系统调用，请运行以下命令。

    Shell
    ghe-config mysql.innodb-flush-no-fsync true

  4. 若要应用配置，请运行以下命令。

    Note

    在配置运行过程中，你的 GitHub Enterprise Server 实例 上的服务可能会重启，这可能会导致用户短暂停机。

    Shell
    ghe-config-apply

  5. 等待配置运行完毕。

升级实例的存储

可以通过为实例的节点预配更快的存储来减少挂起的操作、增加 IOPS 并提高性能。 若要升级实例的存储，请备份实例并将备份还原到新的替换实例。 有关详细信息，请参阅“在实例上配置备份”。

与 GitHub 共享数据

最后，如果你愿意帮助 GitHub 了解升级到 MySQL 8 的实际影响，可以向 GitHub 支持 提供你收集到的数据。 提供监视器仪表板中的基线和升级后的观察结果，以及涵盖收集数据期间的支持捆绑包。 有关详细信息，请参阅 关于 GitHub 支持 和 向 GitHub 支持提供数据。

你提交的数据有助于 GitHub 继续提供高性能产品，但 GitHub 不保证会根据你提供的数据而对产品执行其他缓解步骤或更改。

升级到 GitHub Enterprise Server 3.9 或 3.10 后，MySQL 无法启动

在升级到 GitHub Enterprise Server 3.9（从 3.7 或 3.8）或 3.10（仅从 3.8）期间，如果在关闭 GitHub Enterprise Server 3.7 或 3.8 实例期间 MySQL 未正常关闭，则当 GitHub Enterprise Server 3.9 或 3.10 实例启动时，MySQL 将尝试进行故障修复。 由于 GitHub Enterprise Server 3.7 和 3.8 使用 MySQL 5.7，并且 GitHub Enterprise Server 3.9 和 3.10 已升级到 MySQL 8.0，因此 MySQL 将无法完成故障修复。

如果要从 GitHub Enterprise Server 3.9 升级到 3.10，则不会受此问题影响，因为实例上的 MySQL 已从 5.7 升级到 8.0。

如果遇到此问题，以下错误将出现在 mysql 错误日志 (/var/log/mysql/mysql.err) 中：

Shell
[ERROR] [MY-012526] [InnoDB] Upgrade after a crash is not supported. This redo log was created with MySQL 5.7.40. Please follow the instructions at http://dev.mysql.com/doc/refman/8.0/en/upgrading.html

避免此问题

强烈建议在升级到 3.9 或 3.10 之前，将 GitHub Enterprise Server 实例升级到最新修补程序版本（3.7.14 或更高版本，或者 3.8.7 或更高版本）。 这些版本包含针对升级问题的修补程序。

如果无法升级 你的 GitHub Enterprise Server 实例，则可以在开始升级到 GitHub Enterprise Server 3.9（从 3.7 或 3.8）或 3.10（仅从 3.8）之前更新 MySQL 的 nomad 超时来避免此问题：

  1. 将实例置于维护模式：

    Shell
    ghe-maintenance -s

  2. 更新 nomad 的 consul 模板：

    Shell
    sudo sed -i.bak '/kill_signal/i \      kill_timeout = "10m"' /etc/consul-templates/etc/nomad-jobs/mysql/mysql.hcl.ctmpl

  3. 呈现 nomad 的 consul 模板：

    Shell
    sudo consul-template -once -template /etc/consul-templates/etc/nomad-jobs/mysql/mysql.hcl.ctmpl:/etc/nomad-jobs/mysql/mysql.hcl

  4. 验证当前 kill_timeout 设置：

    Shell
    nomad job inspect mysql | grep KillTimeout

    预期响应：

    Shell
    "KillTimeout": 5000000000

  5. 停止 MySQL：

    Shell
    nomad job stop mysql

  6. 运行新的 MySQL 作业：

    Shell
    nomad job run /etc/nomad-jobs/mysql/mysql.hcl

  7. 验证 kill_timeout 是否已更新：

    Shell
    nomad job inspect mysql | grep KillTimeout

    预期响应：

    Shell
    "KillTimeout": 600000000000,

  8. 将实例退出维护模式：

    Shell
    ghe-maintenance -u

更新 MySQL 的 nomad 超时后，可以将 GitHub Enterprise Server 实例升级到 3.9。

缓解 MySQL 重启失败的问题

如果受此问题影响，请将 GitHub Enterprise Server 实例还原到升级尝试之前的状态，然后按照上一部分中的步骤操作。

有关从失败的升级还原的详细信息，请参阅“从失败的升级中恢复”。