MySQL レプリカ ノードのデータベース シード処理の遅延について
Note
データベースのシーディングを延期する機能 はパブリックベータとして利用可能です。
プライマリ ノードに 7 日を超えるデータがある場合に新しい MySQL レプリカ ノードをクラスターに追加することで、通常、データベースのシード処理がトリガーされ、データの量によっては数時間かかることがあります。 データベースのシード処理を延期して、構成の適用の実行が早く完了するように選択ができます。これによって、トラフィックに対するアプライアンスを早く開くことができます。
データベース のシード処理は、少なくともひとつの MySQL レプリカを既に構成していて、追加の MySQL レプリカを追加している場合にのみ延期をする必要があります。 それ以外の場合は、シード処理が完了するまで MySQL の冗長性はありません。
データベースのシード処理を延期する場合、後でシード処理が手動で完了するまで、新しい MySQL レプリカはレプリケーション用に構成されず、MySQL プライマリ ノード上のデータのコピーも保持されません。
新しい MySQL ノードを追加する場合の MySQL シード処理の遅延の構成
-
置き換えノードに一意のホスト名を指定し、GitHub Enterprise Server をプロビジョニングしてインストールします。
-
管理シェルまたは DHCP を使用して、置換ノードの IP アドレスのみを構成します。 その他の設定は行わないでください。
-
cluster.conf
新しい MySQL ノードのエントリを作成し、skip-data-setup = true
フィールドを含めます。 次の例では、ホスト名ghe-data-node-3
とmysql-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 ...
-
クラスタ内の新しいノードを初期化するには、
cluster.conf
変更したノードの管理シェルからghe-cluster-config-init
を実行します。 -
設定ファイルを検証し、また修正された
cluster.conf
ファイルに従って各ノードをコピーして設定するには、ghe-cluster-config-apply
を実行します。
データの手動シード処理
ghe-cluster-config-apply
を実行すると、MySQL サービスは新しいノードで実行されますが、レプリカとして構成されることも、MySQL プライマリ ノードのデータがシード処理されることもありません。 MySQL プライマリ ノードからデータをシードするには、レプリケーションを手動で構成することが必要です。
-
新しいノードから MySQL プライマリ ノード データの手動レプリケーションを開始するには、次のコマンドを実行し、
PRIMARY_IP
をMySQL プライマリを実行しているノードの IP アドレスに置き換えます。/usr/local/share/enterprise/ghe-mysql-repl-start PRIMARY_IP
データベースのシード処理に必要な時間は、データのサイズで異なります。 大規模なデータセットの場合は、screen
セッションで上記のコマンドを実行して、SSH 切断が維持されるようにすることをお勧めします。