このバージョンの GitHub Enterprise サーバーはこの日付をもって終了となりました: 2026-04-09. 重大なセキュリティの問題に対してであっても、パッチリリースは作成されません。 パフォーマンスの向上、セキュリティの向上、新機能の向上を図るために、最新バージョンの GitHub Enterprise サーバーにアップグレードしてください。 アップグレードに関するヘルプについては、GitHub Enterprise サポートにお問い合わせください。

クラスタノードの入れ替え

          GitHub Enterprise Server クラスターでノードが失敗した場合、またはリソースを追加する新しいノードを追加する場合は、置き換えるノードをオフラインとしてマークしてから、新しいノードを追加します。

この機能を使用できるユーザーについて

GitHub はクラスタリングの適格性を決定し、インスタンスのライセンスの構成を有効にする必要があります。 クラスタリングには、慎重な計画と追加の管理オーバーヘッドが必要です。 詳しくは、「クラスタリングについて」をご覧ください。

この記事で

          GitHub Enterprise Server クラスター ノードの置換について

          GitHub Enterprise Server クラスター内の機能ノードを置き換えるか、予期せず失敗したノードを置き換えることができます。

ノードを置き換えた後、 お使いの GitHub Enterprise Server インスタンス はジョブを新しいノードに自動的に分散しません。 インスタンスに強制的に指示してノード間でジョブのバランスを取ることができます。 詳しくは、「クラスター ワークロードの再調整」をご覧ください。

警告

競合を避けるため、クラスターのノードに以前に割り当てられていたホスト名を再利用しないでください。

関数ノードの入れ替え

クラスター内の既存の関数ノードを置き換えることができます。 たとえば、追加の CPU、メモリ、またはストレージ リソースを仮想マシン (VM) に提供できます。

機能ノードを置き換えるには、 GitHub Enterprise Server アプライアンスを新しい VM にインストールし、IP アドレスを構成し、新しいノードをクラスター構成ファイルに追加し、クラスターを初期化して構成を適用してから、置き換えたノードをオフラインにします。

メモ

プライマリ データベース ノードを置き換える場合は、「プライマリ データベース ノードを置き換える」を参照してください。

  1. 置き換えノードに一意のホスト名を指定し、GitHub Enterprise Server をプロビジョニングしてインストールします。

  2. 管理シェルまたは DHCP を使用して、置換ノードの IP アドレスのみを構成します。 その他の設定は行わないでください。

  3. 任意のノードに対して、新たにプロビジョニングされた置換ノードを追加するには、cluster.conf ファイルを修正し、障害が起きたノードを取り除き、置換ノードを追加します。 たとえば、このように変更した cluster.conf ファイルでは、ghe-data-node-3 を新しくプロビジョニングされた ghe-replacement-data-node-3 ノードで置換します。

    [cluster "ghe-replacement-data-node-3"]
  hostname = ghe-replacement-data-node-3
  ipv4 = 192.168.0.7
  # ipv6 = fd12:3456:789a:1::7
  consul-datacenter = PRIMARY-DATACENTER
  git-server = true
  pages-server = true
  mysql-server = true
  elasticsearch-server = true
  redis-server = true
  memcache-server = true
  metrics-server = true
  storage-server = true

    新しい MySQL レプリカ ノードのデータベース シード処理の延期ができます。その結果、アプライアンスをトラフィックに対してより早く開くことができます。 詳しくは、「データベース シード処理の遅延」をご覧ください。

  4. 変更された cluster.conf があるノードの管理シェルから、ghe-cluster-config-init を実行します。 これで、クラスタに新たに追加されたノードが初期化されます。

  5. 同じノードから、ghe-cluster-config-apply を実行します。 これにより、構成ファイルが検証され、クラスター内の各ノードにコピーされ、変更された cluster.conf ファイルに従って各ノードが設定されます。

  6. 置き換えるノードをオフラインにするには、クラスターのプライマリ MySQL ノードから次のコマンドを実行します。

    ghe-remove-node NODE-HOSTNAME

    このコマンドは、ノードで実行されているデータ サービスからデータを除外し、ノードを構成でオフラインとしてマークし、ノードへのトラフィックのルーティングを停止します。 詳しくは、「コマンド ライン ユーティリティ」をご覧ください。

緊急時のノードの入れ替え

クラスター内の障害が発生したノードを置き換えることができます。 たとえば、ソフトウェアまたはハードウェアの問題がノードの可用性に影響を与える可能性があります。

メモ

プライマリ データベース ノードを置き換える場合は、「プライマリ データベース ノードを置き換える」を参照してください。

緊急時にノードを置き換えるには、障害が発生したノードをオフラインにし、交換ノードをクラスターに追加してから、コマンドを実行して、削除されたノード上のデータ サービスへの参照を削除します。

  1. クラスターから問題が発生しているノードを削除するには、クラスターのプライマリ MySQL ノードから、次のコマンドを実行します。 NODE-HOSTNAME を、オフラインにするノードのホスト名に置き換えます。

    ghe-remove-node --no-evacuate NODE-HOSTNAME

    このコマンドは、構成でノードをオフラインとしてマークし、ノードへのトラフィックのルーティングを停止します。 このコマンドを no-evacuate モードで実行できるようになりました。これは、この手順の後半で、クラスター内の他の使用可能なノードにレプリカをコピーするようにノード上のデータ サービスに指示するコマンドを実行するためです。 詳しくは、「コマンド ライン ユーティリティ」をご覧ください。

  2. 代替ノードをクラスターに追加します。

    1. 置き換えノードに一意のホスト名を指定し、GitHub Enterprise Server をプロビジョニングしてインストールします。

    2. 管理シェルまたは DHCP を使用して、置換ノードの IP アドレスのみを構成します。 その他の設定は行わないでください。

    3. 任意のノードに対して、新たにプロビジョニングされた置換ノードを追加するには、cluster.conf ファイルを変更して置換ノードを追加します。 たとえば、次の変更された cluster.conf ファイルは、新しくプロビジョニングされたノード ghe-replacement-data-node-3 を追加します。

      [cluster "ghe-replacement-data-node-3"]
  hostname = ghe-replacement-data-node-3
  ipv4 = 192.168.0.7
  # ipv6 = fd12:3456:789a:1::7
  git-server = true
  pages-server = true
  mysql-server = true
  elasticsearch-server = true
  redis-server = true
  memcache-server = true
  metrics-server = true
  storage-server = true

    4. 変更された cluster.conf があるノードの管理シェルから、ghe-cluster-config-init を実行します。 これで、クラスタに新たに追加されたノードが初期化されます。

    5. 同じノードから、ghe-cluster-config-apply を実行します。 これにより、構成ファイルが検証され、クラスター内の各ノードにコピーされ、変更された cluster.conf ファイルに従って各ノードが設定されます。

  3. 削除したノード上のデータ サービスへの参照を削除します。

    1. 削除したノードの UUID を見つけます。 UUID を見つけるには、次のコマンドを実行し、HOSTNAME をノードのホスト名に置き換えます。 この UUID は次のステップで使用します。

      ghe-config cluster.HOSTNAME.uuid

    2. データ サービスへの参照を削除するには、次のコマンドを実行します。 UUID をノードの UUID に置き換えます。

      これらのコマンドは、ノードが完全に削除されることを各サービスに示します。 サービスは、クラスター内の使用可能なノード上のノード内に含まれるすべてのレプリカを再作成します。

      メモ

      レプリカ間でデータのバランスが取られる間、これらのコマンドによってサーバーの負荷が増える可能性があります。

          `git-server` サービスの場合 (リポジトリ データに使用)：

      ghe-spokesctl server destroy git-server-UUID

          `pages-server` サービス (GitHub Pages サイト ビルドに使用):

      ghe-dpages remove pages-server-UUID

          `storage-server` サービス (Git LFS データ、アバター 画像、添付ファイル、リリース アーカイブに使用)：

      ghe-storage destroy-host storage-server-UUID --force

  4. 必要に応じて、 cluster.conf ファイル内の削除されたノードのエントリを削除します。 そうすることで、cluster.conf ファイルが整理された状態に保たれ、今後の config-apply の実行時の時間を節約できます。

    1. ファイルからエントリを削除するには、次のコマンドを実行し、HOSTNAME が削除されたノードのホスト名に置き換えます。

      ghe-config --remove-section "cluster.HOSTNAME"

    2. 構成をクラスター内の他のノードにコピーするには、cluster.conf を変更したノードの管理シェルから ghe-cluster-config-apply を実行します。

プライマリ データベース ノードを置き換える (MySQL または MySQL と MSSQL)

データベース サービスを提供するには、クラスターにプライマリ MySQL ノードと少なくとも 1 つのレプリカ MySQL ノードが必要です。 詳しくは、「クラスタノードについて」をご覧ください。

クラスター GitHub Actions 有効になっている場合は、次の手順で MSSQL を考慮する必要もあります。

プライマリ MySQL (または MySQL と MSSQL) ノードにさらにリソースを割り当てる必要がある場合、または障害が発生したノードを置き換える必要がある場合は、クラスターに新しいノードを追加できます。 ダウンタイムを最小限に抑えるには、新しいノードを追加し、MySQL (または MySQL と MSSQL) データをレプリケートしてから、それをプライマリ ノードに昇格させます。 昇格プロセス中には、ある程度のダウンタイムが必ず発生します。

  1. 置き換えノードに一意のホスト名を指定し、GitHub Enterprise Server をプロビジョニングしてインストールします。

  2. 管理シェルまたは DHCP を使用して、置換ノードの IP アドレスのみを構成します。 その他の設定は行わないでください。

  3. お使いの GitHub Enterprise Server インスタンス に接続するには、クラスターのいずれかのノードに SSH 接続します。 ワークステーションから、次のコマンドを実行します。 HOSTNAME は、ノードのホスト名に置き換えます。 詳しくは、「管理シェル (SSH) にアクセスする」をご覧ください。

    Shell
    ssh -p 122 admin@HOSTNAME

  4. テキスト エディターで、/data/user/common/cluster.conf のクラスター構成ファイルを開きます。 たとえばVimを利用できます。 ファイルを編集する前に、 cluster.conf ファイルのバックアップを作成します。

    Shell
    sudo vim /data/user/common/cluster.conf

  5.        クラスター構成ファイルでは、<code>[cluster "<em>HOSTNAME</em>"]</code> 見出しの下に各ノードが示されます。 ノードの新しい見出しを追加し、構成のキーと値のペアを入力します。プレースホルダーは実際の値に置き換えます。
    • mysql-server = true キーと値のペアを必ず含めます。
    • クラスターで GitHub Actions が有効になっている場合は、 mssql-server = true キーと値のペアも含める必要があります。
    • 次のセクションは例であり、ノードの構成は異なる場合があります。
    ...
[cluster "HOSTNAME"]
  hostname = HOSTNAME
  ipv4 = IPV4-ADDRESS
  # ipv6 = IPV6-ADDRESS
  consul-datacenter = PRIMARY-DATACENTER
  datacenter = DATACENTER
  mysql-server = true
  redis-server = true
  ...
...

  6. 変更された cluster.conf があるノードの管理シェルから、ghe-cluster-config-init を実行します。 これで、クラスタに新たに追加されたノードが初期化されます。

  7.        `cluster.conf` を変更したノードの管理シェルから、`ghe-cluster-config-apply` を実行します。 新しく追加されたノードはレプリカ MySQL ノードになり、他の構成済みサービスはそこで実行されます。

    メモ

    前のスニペットでは、クラスターで GitHub Actions が有効になっていることを前提としていません。

  8. MySQL レプリケーションが完了するまで待ちます。 クラスター内の任意のノードからの MySQL レプリケーションを監視するには、ghe-cluster-status -v を実行します。

    クラスターで GitHub Actions が有効になっている場合は、MSSQL レプリケーションが完了するまで待機する必要があります。

    クラスターにノードを追加した直後、レプリケーションが追いつくまでレプリケーション ステータスのエラーが表示される場合があります。 インスタンスの負荷、データベースデータ量と、インスタンスが最後にデータベース シードを生成した時間によっては、レプリケーションに数時間かかる場合があります。

  9. 予定メンテナンス ウィンドウで、メンテナンス モードを有効にします。 詳しくは、「メンテナンスモードの有効化とスケジューリング」をご覧ください。

  10.        `ghe-cluster-status -v` を実行して、クラスター内の任意のノードから MySQL (または MySQL と MSSQL) のレプリケーションが完了していることを確認します。

    警告

    MySQL (または MySQL と MSSQL) のレプリケーションが完了するまで待たないと、インスタンス上のデータが失われる恐れがあります。

  11. 現在の MySQL プライマリ ノードを読み取り専用モードに設定するには、MySQL プライマリ ノードから次のコマンドを実行します。

    Shell
    echo "SET GLOBAL super_read_only = 1;" | sudo mysql

  12. プライマリ MySQL ノードとレプリカ MySQL ノードで設定されたグローバル トランザクション識別子 (GTID) が同じになるまで待ちます。 GTID をチェックするには、いずれかのクラスター ノードから次のコマンドを実行します。

    Shell
    ghe-cluster-each -r mysql -- 'echo "SELECT @@global.gtid_executed;" | sudo mysql'
    • グローバル MySQL 変数が正常に設定されたことをチェックするには、次のコマンドを実行します。
    Shell
     echo "SHOW GLOBAL VARIABLES LIKE 'super_read_only';" | sudo mysql

  13. クラスターで GitHub Actions が有効になっている場合は、新しいプライマリ MSSQL ノードになるノードに SSH 接続します。

    Shell
    ssh -p 122 admin@NEW_MSSQL_NODE_HOSTNAME
    • screen セッション内から次のコマンドを実行して、MSSQL を新しいノードに昇格させます。
    Shell
    /usr/local/share/enterprise/ghe-mssql-repl-promote

    これにより、現在のプライマリ MSSQL ノードへのアクセスが試行され、正常なフェールオーバーが実行されます

  14. プライマリ MySQL ノードとレプリカ MySQL ノードの GTID が一致したら、テキスト エディターの /data/user/common/cluster.conf でクラスター構成ファイルを開いてクラスター構成を更新します。

    • ファイルを編集する前に、 cluster.conf ファイルのバックアップを作成します。
    • トップレベルの [cluster] セクション で、置き換えたノードのホスト名を mysql-master キーと値のペアから削除し、代わりに新しいノードを割り当てます。 新しいノードがプライマリ Redis ノードでもある場合は、redis-master キーと値のペアを調整します。
    • クラスターで GitHub Actions が有効になっている場合は、 mssql-server = true キーと値のペアも含める必要があります。
    [cluster]
  mysql-master = NEW-NODE-HOSTNAME
  redis-master = NEW-NODE-HOSTNAME
  primary-datacenter = primary
...

  15.        `cluster.conf` を変更したノードの管理シェルで、`screen` セッションを開始し、`ghe-cluster-config-apply` を実行します。 このコマンドを実行すると、クラスターを再構成し、新しく追加されたノードをプライマリ MySQL ノードに昇格させ、元のプライマリ MySQL ノードをレプリカに変換することができます。

    メモ

    前のスニペットでは、クラスターで GitHub Actions が有効になっていることを前提としていません。

  16. クラスターで GitHub Actions が有効になっている場合は、新しい MySQL ノードと MSSQL ノードから次のコマンドを実行します。

    Shell
    /usr/local/share/enterprise/ghe-repl-post-failover-mssql

  17.        `ghe-cluster-status -v` を実行して、クラスター内の任意のノードから MySQL (または MySQL と MSSQL) のレプリケーションの状態をチェックします。

  18. MySQL (または MySQL と MSSQL) のレプリケーションが完了したら、クラスター内の任意のノードからメンテナンス モードを無効にします。 「メンテナンスモードの有効化とスケジューリング」を参照してください。