ダイレクト転送移行のトラブルシューティング
- プラン: Free、Premium、Ultimate
- 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated
Railsコンソールセッションで、グループのインポート試行の失敗またはエラーメッセージを見つけることができます:
# Get relevant import records
import = BulkImports::Entity.where(namespace_id: Group.id).map(&:bulk_import).last
# Alternative lookup by user
import = BulkImport.where(user_id: User.find(...)).last
# Get list of import entities. Each entity represents either a group or a project
entities = import.entities
# Get a list of entity failures
entities.map(&:failures).flatten
# Alternative failure lookup by status
entities.where(status: [-1]).pluck(:destination_name, :destination_namespace, :status)APIエンドポイントを使用すると、関連する失敗のあるすべての移行済みエンティティも確認できます。
移行が遅いか、タイムアウトしている
非常に遅い移行またはタイムアウトが発生している場合は、これらの戦略を使用して移行期間を短縮してください。
移行先インスタンスにSidekiqワーカーを追加する
GitLab Self-Managedインスタンスに移行する場合、移行を高速化するために、宛先インスタンスにSidekiqワーカーを追加できます。Sidekiqワーカーの数を増やす場合、次の点を考慮する必要があります:
- 単一のダイレクト転送移行は、宛先インスタンスで利用可能なSidekiqワーカーの数に関係なく、一度に5つのグループまたはプロジェクトを移行します。
- 宛先インスタンスには、より多くの同時ジョブを処理する能力が必要です。もしそうなら、より多くのSidekiqワーカーを追加すると、各グループまたはプロジェクトをインポートするのにかかる時間を短縮できます。
宛先インスタンスにSidekiqワーカーを追加する方法の詳細については、インポート用のSidekiq設定を参照してください。
個別の移行を開始する
ソースインスタンスが5つのグループを並行してエクスポートするリソースを持っていない場合、遅延や潜在的なタイムアウトが発生する可能性があります。ソースインスタンスのリソースが不足している場合、宛先インスタンスはエクスポートされたデータが利用可能になるまで待機する必要があります。
並行エクスポートによって引き起こされる遅延を軽減するため、すべてのグループとプロジェクトを同時に行うのではなく、各グループに対して個別の移行を開始してください。GitLab UIはトップレベルグループのみを移行できるため、APIを使用してサブグループ内のプロジェクトを移行する必要がある場合があります。
古いインポート
移行は、ソースまたは宛先インスタンスの問題により、停止するかtimeoutステータスで完了する可能性があります。これらの問題を解決するには、ソースインスタンスと宛先インスタンスの両方からログを検査してください。
ソースインスタンス
ソースインスタンスでは、古いインポートは、Sidekiqプロセスを再起動し、エクスポートジョブを中断する可能性のある過剰なメモリ使用が原因であることがよくあります。宛先インスタンスは、移行が最終的にタイムアウトするまで、エクスポートファイルを待機する可能性があります。
グループまたはプロジェクトのリレーションが正常にエクスポートされたかを確認するには、次のコマンドを実行します:
curl --request GET --location "https://example.gitlab.com/api/v4/projects/:ID/export_relations/status" \
--header "PRIVATE-TOKEN: <your_access_token>"リレーションが1以外のステータスの場合、そのリレーションは正常にエクスポートされず、問題はソースインスタンスにあります。
中断されたエクスポートジョブを検索するには、次のコマンドを実行することもできます。Sidekiqログは再起動後にローテーションされる可能性があるため、ローテーションされたログも確認するようにしてください。
grep `BulkImports::RelationBatchExportWorker` sidekiq.log | grep "interrupted_count"Sidekiqの再起動が問題を引き起こしている場合:
エクスポートジョブ用に個別のSidekiqプロセスを設定します。詳細については、インポート用のSidekiq設定を参照してください。問題が解決しない場合は、Sidekiqの並行処理を減らして、同時に処理されるジョブの数を制限してください。
Sidekiqメモリ制限を増やします: お使いのインスタンスに利用可能なメモリがある場合、Sidekiqプロセスの最大RSS制限を増やすことができます。例えば、頻繁な再起動を防ぐために、制限を2 GBから3 GBに増やすことができます。
最大中断回数を増やします: ジョブが失敗する前により多くの中断を許可するには、
BulkImports::RelationBatchExportWorkerの最大中断回数を増やすことができます:制限を
20に増やすには、次の設定を追加します（デフォルト値は3です）:sidekiq_options max_retries_after_interruption: 20変更を有効にするため、Sidekiqを再起動します。
これで、新しい移行をトリガーするか、プロジェクトリレーションエクスポートAPIを使用して手動でエクスポートをトリガーすることができます。リレーションが正常にエクスポートされているかを確認するには、エクスポートステータスを確認してください。
例えば、特定のプロジェクトのエクスポートをトリガーするには、次のコマンドを実行します:
curl --request POST --location "https://example.gitlab.com/api/v4/projects/:ID/export_relations" \
--header "PRIVATE-TOKEN: <your_access_token>" \
--form 'batched="true"'宛先インスタンス
まれに、宛先インスタンスがグループまたはプロジェクトの移行に失敗する可能性があります。詳細については、イシュー498720を参照してください。
この問題を解決するには、インポートAPIを使用して、失敗したグループまたはプロジェクトを移行します。このAPIを使用すると、特定のグループやプロジェクトを個別に移行できます。
エラー: 404 Group Not Found
数字のみで構成されるパス（例: 5000）を持つグループをインポートしようとすると、GitLabはパスではなくIDでグループを検索しようとします。これにより、GitLab 15.4および以前では404 Group Not Foundエラーが発生します。
これを解決するには、次のいずれかを使用してソースグループのパスを非数値文字を含むように変更する必要があります:
GitLab UI:
- 上部のバーで、検索または移動先を選択して、グループを見つけます。
- 設定 > 一般を選択します。
- 高度な設定を展開します。
- グループのURLの変更の下で、グループのURLを非数値文字を含むように変更します。
その他の404エラー
グループをインポートする際に、その他の404エラーを受け取る可能性があります。例えば:
"exception_message": "Unsuccessful response 404 from [FILTERED] Bo...",
"exception_class": "BulkImports::NetworkError",このエラーは、ソースインスタンスからの転送に関する問題を示しています。これを解決するには、ソースインスタンスで前提条件を満たしていることを確認してください。
不一致のグループまたはプロジェクトのパス名
ソースグループまたはプロジェクトのパスが命名規則に準拠していない場合、そのパスが有効であることを確認するために正規化されます。例えば、Destination-Project-Pathはdestination-project-pathに正規化されます。
エラー: command exited with error code 15 and Unable to save [FILTERED] into [FILTERED]
ダイレクト転送を使用してプロジェクトを移行する際に、ログでcommand exited with error code 15 and Unable to save [FILTERED] into [FILTERED]エラーを受け取る可能性があります。このエラーを受け取った場合、安全に無視できます。GitLabは終了したコマンドを再試行します。
エラー: Batch export [batch_number] from source instance failed
宛先インスタンスで、次のエラーが発生する可能性があります:
Batch export [batch_number] from source instance failed: [source instance error]このエラーは、ソースインスタンスが一部のレコードのエクスポートに失敗した場合に発生します。最も一般的な理由は次のとおりです:
- ディスク容量不足
- メモリ不足によるSidekiqジョブの複数の中断
- データベースステートメントタイムアウト
この問題を解決するには、次の手順に従います:
- ソースインスタンスで問題を特定して修正します。
- 部分的にインポートされたプロジェクトまたはグループを宛先インスタンスから削除し、新しいインポートを開始します。
エクスポートに失敗したリレーションとバッチの詳細については、ソースインスタンスでプロジェクトとグループのエクスポートステータスAPIエンドポイントを使用してください。
エラー: duplicate key value violates unique constraint
レコードをインポートする際、次のエラーが発生する可能性があります:
PG::UniqueViolation: ERROR: duplicate key value violates unique constraintこのエラーは次の場合に発生する可能性があります:
- インポートを処理中のSidekiqワーカーが、高いメモリまたはCPU使用率のために再起動した場合。インポート中のSidekiqのリソース問題を軽減するには:
- インポート用のSidekiq設定を最適化します。
bulk_import_concurrent_pipeline_batch_limitアプリケーション設定で、同時ジョブの数を制限します。
- 異なるソースグループから単一の宛先グループに、グループまたはプロジェクトを統合しています。異なるソースグループからのエピックが同じ内部ID（単一グループ内で一意）を持っている場合、それらを単一の宛先グループにインポートすると競合が発生します。この競合により、
index_issues_on_namespace_id_iid_uniqueまたはindex_epics_on_group_id_and_iidを参照するPG::UniqueViolation: ERROR: duplicate key value violates unique constraintエラーが発生します。
エラー: Import::BulkImports::FileDownloadStrategy::ServiceError Invalid content type
GitLabインスタンス間でダイレクト転送を使用する場合、次のエラーが発生する可能性があります:
Import::BulkImports::FileDownloadStrategy::ServiceError Invalid content typeこのエラーは、インスタンス間でネットワークトラフィックがルーティングされる方法に関連しています。application/gzip以外のコンテンツタイプが返された場合、ネットワークリクエストがGitLab Workhorseをバイパスしている可能性があります。
この問題を解決するには、次の手順に従います:
- お使いのIngressが、GitLab Workhorseを介して
8181ポートでトラフィックをルーティングするように設定されていること、Pumaに直接ではないことを確認してください。 - オブジェクトストレージのプロキシダウンロードを有効にすることを検討してください。
マイルストーンのタイトルに(imported-xx-datetime)が付加された
グループをインポートする際、宛先ネームスペースでグループおよびプロジェクトのマイルストーンタイトルが既存のタイトルと競合する場合、インポートされたマイルストーンには、タイトルに一意のサフィックスが付加されます。例: 18.0 (imported-3d-1770206299)。
これらのマイルストーンを特定するには、宛先インスタンスでlog/importer.logファイルを検索して、次のものを見つけてください:
Updating milestone title - source title used by existing group or project milestoneログエントリには以下が含まれます:
importable_id: インポートされているグループのID。milestone_title: 名前が変更されているマイルストーンのタイトル。existing_group_idまたはexisting_project_id: 既存のマイルストーンを含むグループまたはプロジェクトのID。
この情報を使用して、マイルストーンを特定し、好みに合わせてタイトルを更新できます。
エラー: Destination belongs to a different organization than the current one
ソースと宛先のネームスペースが異なる組織に属し、どちらかの組織が隔離済みとしてマークされている場合、ダイレクト転送による移行は失敗します。
このエラーを解決するには、現在の組織に属する宛先ネームスペースに移行してください。詳細については、イシュー595674を参照してください。
ダウンロードされたファイルが最大ダウンロードファイルサイズを超過した場合の直接転送の失敗
ソースインスタンスからダウンロードされたファイルが、デフォルトの5 GiBである最大ダウンロードファイルサイズより大きい場合、直接転送は失敗します。直接転送はほとんどのデータを小さなバッチでエクスポートするため、ほとんどのファイルはこの制限を超えません。制限を超える可能性が高いのは、repository、lfs、uploadsの各リレーションのみです。
GitLab Self-ManagedおよびGitLab Dedicatedでは、管理者は最大ダウンロードファイルサイズを増やすことができます。
GitLab.comでは、制限は固定されており、引き上げることはできません。制限を超えるプロジェクトを移行するには、移行する前に影響を受けるリレーションのサイズを減らしてください:
repository: 大規模ファイルを削除するためにGitの履歴を書き換えます。この操作により、すべてのコミットSHAが変更されます。詳細については、リポジトリサイズを削減するメソッドを参照してください。lfs: プロジェクトを移行する際、不足しているLFSオブジェクトを宛先に手動でプッシュする。詳細については、LFSオブジェクトがプッシュ時に不足を参照してください。uploads: 回避策はありません。詳細については、イシュー526344を参照してください。