Skip to main content

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

データベース シード処理の遅延

データベースのシード処理の延期で、新しい MySQL レプリカ ノードをクラスターに追加するプロセスを高速化できます。

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

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

MySQL レプリカ ノードのデータベース シード処理の遅延について

Note

パッチ リリース はパブリック ベータとして利用ができます。

プライマリ ノードに 7 日を超えるデータがある場合に新しい MySQL レプリカ ノードをクラスターに追加することで、通常、データベースのシード処理がトリガーされ、データの量によっては数時間かかることがあります。 データベースのシード処理を延期して、構成の適用の実行が早く完了するように選択ができます。これによって、トラフィックに対するアプライアンスを早く開くことができます。

データベース のシード処理は、少なくともひとつの MySQL レプリカを既に構成していて、追加の MySQL レプリカを追加している場合にのみ延期をする必要があります。 それ以外の場合は、シード処理が完了するまで MySQL の冗長性はありません。

データベースのシード処理を延期する場合、後でシード処理が手動で完了するまで、新しい MySQL レプリカはレプリケーション用に構成されず、MySQL プライマリ ノード上のデータのコピーも保持されません。

新しい MySQL ノードを追加する場合の MySQL シード処理の遅延の構成

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

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

  3. cluster.conf新しい MySQL ノードのエントリを作成し、skip-data-setup = trueフィールドを含めます。 次の例では、ホスト名 ghe-data-node-3mysql-serverロールを持つ新しいノードを 追加します。

     ...
     [cluster "ghe-data-node-3"]
       hostname = ghe-data-node-3
       ipv4 = 192.168.0.9
       # ipv6 = fd12:3456:789a:1::7
       mysql-server = true
       skip-data-setup = true
     ...
     
  4. クラスタ内の新しいノードを初期化するには、cluster.conf変更したノードの管理シェルから ghe-cluster-config-initを実行します。

  5. 設定ファイルを検証し、また修正されたcluster.confファイルに従って各ノードをコピーして設定するには、ghe-cluster-config-applyを実行します。

データの手動シード処理

ghe-cluster-config-applyを実行すると、MySQL サービスは新しいノードで実行されますが、レプリカとして構成されることも、MySQL プライマリ ノードのデータがシード処理されることもありません。 MySQL プライマリ ノードからデータをシードするには、レプリケーションを手動で構成することが必要です。

  1. 新しいノードから MySQL プライマリ ノード データの手動レプリケーションを開始するには、次のコマンドを実行し、 PRIMARY_IP をMySQL プライマリを実行しているノードの IP アドレスに置き換えます。

    /usr/local/share/enterprise/ghe-mysql-repl-start PRIMARY_IP
    

データベースのシード処理に必要な時間は、データのサイズで異なります。 大規模なデータセットの場合は、screenセッションで上記のコマンドを実行して、SSH 切断が維持されるようにすることをお勧めします。