GitLabで管理されているリポジトリの移動

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

GitLabインスタンス内のデータを移動する

Gitリポジトリを移動するには、GitLab APIを使用します:

• サーバー間。
• 異なるリポジトリストレージ間。
• シングルノードGitalyからGitalyクラスタリング（Praefect）へ。

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

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

リポジトリを移動するには、次の手順に従います:

1. すべてのローカルおよびクラスタリングストレージがGitLabインスタンスにアクセスできることを確認してください。この例では、これらは<original_storage_name>と<cluster_storage_name>です。
2. 新しいストレージがすべての新しいプロジェクトを受信するように、リポジトリのストレージのウェイトを構成する。これにより、移行の進行中に、既存のストレージに新しいプロジェクトが作成されなくなります。
3. プロジェクト、スニペット、およびグループのリポジトリの移動をスケジュールします。
4. GitLabを使用している場合は、すべてのリポジトリを再同期します。

プロジェクトの移動

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

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