GitLabによって管理されているリポジトリの移動

GitLabによって管理されているすべてのリポジトリを、別のファイルシステムまたは別のサーバーに移動します。

GitLabインスタンス内のデータの移動

GitLab APIを使用してGitリポジトリを移動します:

• サーバー間。
• 異なるリポジトリストレージ間。
• 単一ノードGitalyからGitalyクラスター (Praefect)へ。

GitLabリポジトリは、プロジェクト、グループ、およびスニペットに関連付けることができます。これらの各タイプには、リポジトリを移動するための個別のAPIがあります。GitLabインスタンス上のすべてのリポジトリを移動するには、各タイプのリポジトリを各リポジトリストレージに移動する必要があります。

各リポジトリは移動中読み取り専用になり、移動が完了するまで書き込みできません。

リポジトリを移動するには:

1. すべてのローカルおよびクラスターリポジトリストレージがGitLabインスタンスにアクセスできることを確認します。この例では、これらは<original_storage_name>と<cluster_storage_name>です。
2. 新しいリポジトリストレージがすべての新規プロジェクトを受け取るように、リポジトリストレージのウェイトを設定します。これにより、移行の進行中に既存のリポジトリストレージで新規プロジェクトが作成されるのを防ぎます。
3. プロジェクト、スニペット、およびグループのリポジトリ移動をスケジュールします。
4. あなたがGeoを使用している場合は、すべてのリポジトリを再同期します。
5. SidekiqポッドでHorizontal Pod Autoscalerを使用している場合、移行中のスケールを防ぐためにSidekiqポッドのHPAを無効にします。

プロジェクトを移動する

すべてのプロジェクト、または個々のプロジェクトを移動できます。

APIを使用してすべてのプロジェクトを移動するには:

1. APIを使用して、ストレージシャード上のすべてのプロジェクトのリポジトリストレージ移動をスケジュールします。例:

   curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" \
        --header "Content-Type: application/json" \
        --data '{"source_storage_name":"<original_storage_name>","destination_storage_name":"<cluster_storage_name>"}' \
        "https://gitlab.example.com/api/v4/project_repository_storage_moves"

2. APIを使用して、最新のリポジトリ移動をクエリします。応答は次のいずれかを示します:

   • 移動が正常に完了しました。stateフィールドがfinishedです。
   • 移動が進行中です。完了するまでリポジトリ移動を再クエリします。
   • 移動は失敗しました。ほとんどの失敗は一時的なものであり、移動を再スケジュールすることで解決されます。

3. 移動が完了したら、APIを使用してプロジェクトをクエリし、すべてのプロジェクトが移動したことを確認します。古いリポジトリストレージに設定されたrepository_storageフィールドでプロジェクトが返されないようにする必要があります。例:

   curl --header "PRIVATE-TOKEN: <your_access_token>" --header "Content-Type: application/json" \
   "https://gitlab.example.com/api/v4/projects?repository_storage=<original_storage_name>"

   または、Railsコンソールを使用して、すべてのプロジェクトが移動したことを確認します:

   ProjectRepository.for_repository_storage('<original_storage_name>')

4. 必要に応じて、各リポジトリストレージに対して繰り返します。

すべてのプロジェクトを移動しない場合は、個々のプロジェクトの移動に関する指示に従ってください。

スニペットを移動する

すべてのスニペット、または個々のスニペットを移動できます。

APIを使用してすべてのスニペットを移動するには:

1. ストレージシャード上のすべてのスニペットのリポジトリストレージ移動をスケジュールします。例:

   curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" \
        --header "Content-Type: application/json" \
        --data '{"source_storage_name":"<original_storage_name>","destination_storage_name":"<cluster_storage_name>"}' \
        "https://gitlab.example.com/api/v4/snippet_repository_storage_moves"

2. 最新のリポジトリ移動をクエリします。応答は次のいずれかを示します:

   • 移動が正常に完了しました。stateフィールドがfinishedです。
   • 移動が進行中です。完了するまでリポジトリ移動を再クエリします。
   • 移動は失敗しました。ほとんどの失敗は一時的なものであり、移動を再スケジュールすることで解決されます。

3. 移動が完了したら、Railsコンソールを使用して、すべてのスニペットが移動したことを確認します:

   SnippetRepository.for_repository_storage('<original_storage_name>')

   このコマンドは、元のリポジトリストレージのスニペットを返さないはずです。

4. 必要に応じて、各リポジトリストレージに対して繰り返します。

すべてのスニペットを移動しない場合は、個々のスニペットに関する指示に従ってください。

グループを移動する

すべてのグループ、または個々のグループを移動できます。

APIを使用してすべてのグループを移動するには:

1. ストレージシャード上のすべてのグループのリポジトリストレージ移動をスケジュールします。例:

   curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" \
        --header "Content-Type: application/json" \
        --data '{"source_storage_name":"<original_storage_name>","destination_storage_name":"<cluster_storage_name>"}' \
        "https://gitlab.example.com/api/v4/group_repository_storage_moves"

2. 最新のリポジトリ移動をクエリします。応答は次のいずれかを示します:

   • 移動が正常に完了しました。stateフィールドがfinishedです。
   • 移動が進行中です。完了するまでリポジトリ移動を再クエリします。
   • 移動は失敗しました。ほとんどの失敗は一時的なものであり、移動を再スケジュールすることで解決されます。

3. 移動が完了したら、Railsコンソールを使用して、すべてのグループが移動したことを確認します:

   GroupWikiRepository.for_repository_storage('<original_storage_name>')

   このコマンドは、元のリポジトリストレージのグループを返さないはずです。

4. 必要に応じて、各リポジトリストレージに対して繰り返します。

すべてのグループを移動しない場合は、個々のグループに関する指示に従ってください。

別のGitLabインスタンスに移行する

新しいGitLab環境に移行する場合、APIを使用してデータを移動することはできません。例:

• 単一ノードGitLabからスケールアウトされたアーキテクチャへ。
• プライベートデータセンターのGitLabインスタンスからクラウドプロバイダーへ。

この場合、シナリオに応じて、すべてのリポジトリを/var/opt/gitlab/git-data/repositoriesから/mnt/gitlab/repositoriesにコピーする方法があります:

• ターゲットディレクトリが空です。
• ターゲットディレクトリには、古いリポジトリのコピーが含まれています。
• 数千のリポジトリがある場合。

バックアップと復元を使用（推奨）

GitalyまたはGitalyクラスター (Praefect)のターゲットの場合、GitLabのバックアップと復元機能を使用する必要があります。Gitリポジトリは、GitalyによってデータベースとしてGitLabサーバー上でアクセス、管理、保存されます。rsyncのようなツールを使用してGitalyファイルに直接アクセスしてコピーすると、データ損失が発生する可能性があります。次のことが可能です。

• 複数のリポジトリを同時に処理することで、バックアップパフォーマンスを向上させます。
• スキップ機能を使用して、リポジトリのみのバックアップを作成します。

Gitalyクラスター (Praefect)ターゲットには、バックアップおよび復元方法を使用する必要があります。

tarを使用する

tarパイプを使用してリポジトリを移動できます（次の場合）:

• Gitalyターゲットを指定し、Gitalyクラスターターゲットは指定しない場合。
• ターゲットディレクトリ/mnt/gitlab/repositoriesが空である場合。

この方法はオーバーヘッドが低く、tarは通常システムにプリインストールされています。ただし、中断されたtarパイプは再開できません。tarが中断された場合、ターゲットディレクトリを空にし、すべてのデータを再度コピーする必要があります。

tarプロセスの進行状況を確認するには、-xfを-xvfに置き換えます。

sudo -u git sh -c 'tar -C /var/opt/gitlab/git-data/repositories -cf - -- . |\
  tar -C /mnt/gitlab/repositories -xf -'

別のサーバーにtarパイプを使用する

Gitalyターゲットの場合、tarパイプを使用してデータを別のサーバーにコピーできます。あなたのgitユーザーがgit@<newserver>として新しいサーバーにSSHアクセスできる場合、SSHを介してデータをパイプできます。

ネットワーク経由でデータを転送する前にデータを圧縮したい場合（CPU使用率が増加します）は、sshをssh -Cに置き換えることができます。

sudo -u git sh -c 'tar -C /var/opt/gitlab/git-data/repositories -cf - -- . |\
  ssh git@newserver tar -C /mnt/gitlab/repositories -xf -'

rsyncを使用する

rsyncを使用してリポジトリを移動できます（次の場合）:

• Gitalyターゲットを指定し、Gitalyクラスターターゲットは指定しない場合。
• ターゲットディレクトリに既にリポジトリの部分的または古いコピーが含まれているため、tarですべてのデータを再度コピーすることは非効率です。

次のコマンドの/.は非常に重要です。そうしないと、ターゲットディレクトリに間違ったディレクトリ構造が作成される可能性があります。進行状況を確認したい場合は、-aを-avに置き換えます。

sudo -u git  sh -c 'rsync -a --delete /var/opt/gitlab/git-data/repositories/. \
  /mnt/gitlab/repositories'

別のサーバーにrsyncを使用する

Gitalyターゲットの場合、ソースシステム上のgitユーザーがターゲットサーバーへのSSHアクセス権を持っている場合、rsyncでリポジトリをネットワーク経由で送信できます。

sudo -u git sh -c 'rsync -a --delete /var/opt/gitlab/git-data/repositories/. \
  git@newserver:/mnt/gitlab/repositories'

関連トピック

• Gitalyを設定する
• Gitaly Cluster (Praefect)
• プロジェクトリポジトリストレージ移動API
• ストレージ間グループリポジトリ移動API
• スニペットリポジトリストレージ移動API