直接移行のトラブルシューティング
- プラン: 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このエラーは、次の場合に発生する可能性があります:
- 高いメモリまたはCPU使用量により、インポートを処理中のSidekiqワーカーが再起動した場合。インポート中の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エラーが発生します。
エラー: BulkImports::FileDownloadService::ServiceError Invalid content type
GitLabインスタンス間で直接転送を使用すると、次のエラーが発生する可能性があります:
BulkImports::FileDownloadService::ServiceError Invalid content typeこのエラーは、インスタンス間のネットワークトラフィックのルーティング方法に関連しています。application/gzip以外のコンテンツタイプが返された場合、ネットワークリクエストがGitLab Workhorseをバイパスしている可能性があります。
この問題を解決するには、次の手順に従います:
- お使いのIngressが、
8181ポートでGitLab Workhorseを介してトラフィックをルーティングするように設定されていることを確認してください。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。
この情報を使用して、マイルストーンを見つけ、好みに合わせてタイトルを更新できます。