このバージョンの GitHub Enterprise サーバーはこの日付をもって終了となりました: 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 が使用されています。 Oracle は 2023 年 10 月に MySQL 5.7 の延長サポートを終了します。 詳細については、Oracle Support Web サイトの 「オラクルのLifetime Support Policy」を参照してください。

GitHub Enterprise Server を将来も保証し、最新のセキュリティ アップデート、バグ修正、パフォーマンス向上を提供するには、GitHub Enterprise Server 3.9 以降では MySQL 8.0 が使用されています。 MySQL 8.0 では、再設計された REDO ログにより、1 秒あたりのクエリ数 (QPS) が向上しました。 詳細については、DimitriK の (dim) ウェブログで「MySQL Performance: 8.0 re-designed REDO log & ReadWrite Workloads Scalability」を参照してください。

GitHub Enterprise Server 3.9 へのアップグレード後、インスタンスのパフォーマンスに許容できないほどの低下が発生した場合は、インスタンスのモニター ダッシュボードからデータを収集して影響を確認できます。 問題の軽減を試みたり、データを GitHub Support に提供して、この変更による実際の影響をプロファイリングして伝達したりすることができます。この問題を軽減し、GitHub Support にデータを提供して、この変更の実際の影響をプロファイリングして伝達することができます。

警告: このアップグレードの性質上、続行する前にインスタンスの構成とデータをバックアップしてください。 ステージング環境でバックアップを検証します。 詳細については、「インスタンスでのバックアップの構成」および「ステージングインスタンスのセットアップ」を参照してください。

MySQL アップグレード前のベースライン I/O 使用率データの収集

GitHub Enterprise Server 3.9 以降にアップグレードする前に、ベースライン データを収集します。 ベースライン データを収集するために、GitHub では、GitHub Enterprise Server 3.7 または 3.8 を実行するステージング インスタンスをセットアップし、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 以降のみを対象としています。

警告: フラッシュ方法を調整するには、インスタンスのストレージ デバイスにバッテリベースのキャッシュが必要です。 デバイスのキャッシュがバッテリでバックアップされていない場合は、データ損失のリスクがあります。

  • オンプレミスのデータセンター内で仮想化ハイパーバイザーを使用してインスタンスをホストする場合は、ストレージの仕様を確認してください。
  • インスタンスをパブリック クラウド サービスでホストする場合は、プロバイダーのドキュメントを参照するか、サポート チームに問い合わせして確認してください。

  1. お使いの GitHub Enterprise Server インスタンス に SSH で接続します。 インスタンスが複数のノードで構成されている場合は (高可用性や geo レプリケーションが構成されている場合など)、プライマリ ノードに SSH 接続します。 クラスターを使用する場合は、任意のノードに SSH 接続できます。 HOSTNAME をインスタンスのホスト名、またはノードのホスト名または IP アドレスに置き換えます。 詳しくは、「管理シェル (SSH) にアクセスする」を参照してください。

    Shell
    ssh -p 122 admin@HOSTNAME

  2. InnoDB の現在のフラッシュ方法を検証するには、次のコマンドを実行します。

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

    既定では、コマンドは false を返します。これは、インスタンスが各書き込み操作の後に fsync() システム コールを実行することを示します。

  3. 各書き込み操作の後に fsync() システム コールをスキップするように InnoDB を構成するには、次のコマンドを実行します。

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

  4. 構成を適用するには、次のコマンドを実行します。

    注: 構成の実行中に、お使いの GitHub Enterprise Server インスタンス 上のサービスが再起動する可能性があり、これによりユーザーに短時間のダウンタイムが発生する場合があります。

    Shell
    ghe-config-apply

  5. 設定の実行が完了するのを待ってください。

インスタンスのストレージをアップグレードする

インスタンスのノードに高速なストレージをプロビジョニングすることで、保留中の操作を減らし、IOPS を向上させ、パフォーマンスを向上させることができます。 インスタンスのストレージをアップグレードするには、インスタンスをバックアップし、バックアップを新しい置換インスタンスに復元します。 詳しくは、「インスタンスでのバックアップの構成」を参照してください。

GitHub とデータを共有する

最後に、MySQL 8 へのアップグレードによる実際の影響の問題を GitHub に報告するために、収集したデータを GitHub Supportに提供できます。　　 データを収集した期間をカバーするサポート バンドルと共に、モニター ダッシュボードからベースラインとアップグレード後の監視結果を提供します。 詳細については、「GitHub Supportについて」および「GitHub Support へのデータの提供」を参照してください。

送信したデータは、GitHub がパフォーマンスの高い製品を提供し続けるのに役立ちますが、GitHub は提供されたデータにより製品に対して問題軽減のための追加の手順や変更を保証するものではありません。

GitHub Enterprise Server 3.9 または 3.10 へのアップグレード後に MySQL が起動しない

GitHub Enterprise Server 3.9 へのアップグレード中に、3.9 (3.7 または 3.8 から) または 3.10 (3.8 のみから) へのアップグレード中、GitHub Enterprise Server のシャットダウン中に MySQL が優雅にシャットダウンしなかった場合、MySQL はクラッシュ・リカバリを試みます。3.7 または 3.8 インスタンスのシャットダウン中に MySQL が優雅にシャットダウンしなかった場合、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 インスタンスをアップグレード試行前の状態に復元し、前のセクションの手順に従います。

失敗したアップグレードから復元するための詳細については、「失敗したアップグレードからのリストア」を参照してください。