Remarque
Enterprise Live Migrations est préversion publique et sujet à changement.
Si votre migration rencontre un problème, vérifiez l’état de la migration avec elm migration status --migration-id MIGRATION-ID et passez en revue les informations d’erreur.
États et actions recommandées
| État | Sens | Action recommandée |
|---|---|---|
| Créée | La migration a été créée, mais pas encore démarrée | Exécutez elm migration start |
| En file d'attente | La migration attend le démarrage | Wait |
| Exportation | Les données sont exportées à partir de la source | Surveiller avec elm migration status |
| Traitement | Les données exportées sont importées dans la destination | Surveiller avec elm migration status |
| Prêt pour le basculement | La migration initiale est terminée et prête pour le passage. | Quand vous êtes prêt, exécutez elm migration cutover-to-destination |
| Découpage | Le référentiel source est verrouillé et les modifications restantes sont appliquées à la destination | Moniteur; l’état passe à Terminé |
| Completed | La migration s’est terminée avec succès | Vérifier le référentiel de destination et récupérer des mannequins |
| Échec | La migration a rencontré un échec irrécupérable | Examiner l’erreur (voir ci-dessous) |
| suspendu | La migration est suspendue | Vérifier la raison de pause et résoudre (voir ci-dessous) |
| **** terminée | La migration a été annulée | N/A |
| Détérioré | La destination est inaccessible | Vérifier la connectivité réseau entre l’appliance GitHub Enterprise Server et GHE.com (voir ci-dessous) |
L’état de la migration est « Échec »
Une migration entre dans l’état Échec lorsqu’une erreur irrécupérable l’empêche de continuer. Il s’agit d’une différence entre les ressources individuelles qui n’ont pas pu être importées ; une migration ayant échoué signifie que la migration elle-même ne peut pas continuer.
Pour enquêter, exécutez elm migration status --migration-id MIGRATION-ID et passez en revue les détails de l'erreur dans la réponse. Chaque échec inclut un ID de corrélation au format (Correlation ID for Support: UUID). Si vous contactez Support GitHub, fournissez cet ID afin que l’équipe du support technique puisse examiner.
Après avoir résolu le problème sous-jacent, abandonnez la migration ayant échoué avec elm migration cancel --migration-id MIGRATION-ID et démarrez une nouvelle migration.
Le statut de la migration est « En pause »
Une migration entre dans l’état suspendu lorsqu’un problème nécessite votre intervention avant de pouvoir continuer. Exécutez elm migration status --migration-id MIGRATION-ID et vérifiez la raison de la pause.
Raisons courantes de pause :
- Expiration des informations d’identification : l’une des informations personal access tokens (classic) d’identification a expiré. Créez un jeton avec les étendues requises et mettez-le à jour avec
elm credential update. Redémarrez ensuite la migration. - Limitation du débit : la migration a atteint les limites de débit de l’API. Patientez quelques minutes, puis redémarrez.
Pour redémarrer une migration suspendue après avoir résolu le problème sous-jacent :
elm migration start --migration-id MIGRATION-ID
L’état de la migration est « Détérioré »
Un état détérioré signifie que le service de migration sur l’appliance GitHub Enterprise Server ne peut pas atteindre l’entreprise de destination. La migration se poursuit côté source, mais l’état de destination est inconnu.
Vérifiez la connectivité réseau entre l’appliance GitHub Enterprise Server et votre sous-domaine, GHE.compuis réexécutez elm migration status --migration-id MIGRATION-ID . La réponse d’état inclut un horodatage pour le dernier contact réussi avec la destination, ce qui peut vous aider à évaluer la durée pendant laquelle le problème de connectivité s’est produit.
Migration bloquée dans « Exportation »
Si votre migration reste dans l’état Exportation sans modification de progression pendant 30 minutes ou plus, l’exportateur peut être bloqué.
-
Exécutez
elm migration status --migration-id MIGRATION-IDet notez si les nombres de ressources changent. -
Si le nombre est statique, vérifiez la connectivité réseau de l’appliance à la destination.
-
Passez en revue les journaux d’activité de l’exportateur sur l’appliance GitHub Enterprise Server (nécessite un accès administrateur SSH) :
Shell journalctl -t elm-exporter-backfiller --since "1 hour ago" | tail -50 journalctl -t elm-exporter-sender --since "1 hour ago" | tail -50
journalctl -t elm-exporter-backfiller --since "1 hour ago" | tail -50 journalctl -t elm-exporter-sender --since "1 hour ago" | tail -50 -
Si la tâche de l’exportateur s’est écrasée, elle doit être récupérée automatiquement. Si ce n’est pas le cas, contactez Support GitHub.
Synchronisation Git non terminée
Si elm migration status indique que la commande push Git initiale n’est pas terminée au bout d’un long moment, vérifiez les journaux du synchroniseur Git :
journalctl -t elm-exporter-git-syncer --since "2 hours ago"
journalctl -t elm-exporter-git-syncer --since "2 hours ago"
Recherchez :
connection refused: problème réseau entre l’appliance GitHub Enterprise Server et la destination. Vérifiez les règles de pare-feu et la résolution DNS.authentication failed: il se peut que personal access token (classic) ne dispose pas des portées requises ou ait expiré.remote: error: la destination peut rejeter le push. Contactez Support GitHub en fournissant les détails de l’erreur.
Certaines ressources n’ont pas pu être importées
Les ressources individuelles peuvent ne pas être importées sans provoquer l’échec de la migration globale. Vous pouvez voir le nombre de ressources ayant échoué dans la sortie de elm migration status --migration-id MIGRATION-ID.
Les ressources ayant échoué sont affichées uniquement après que toutes les nouvelles tentatives automatiques ont été épuisées, les échecs que vous voyez sont donc confirmés comme non résolus sans intervention. Passez en revue les détails de l’erreur dans la réponse d’état : chaque ressource ayant échoué dans le remplissage rétroactif ou les mises à jour en direct s'affichera "state": "failed".
Si le nombre et les types de ressources ayant échoué sont acceptables, vous pouvez procéder au basculement. Si ce n’est pas le cas, abandonnez la migration, résolvez le problème sous-jacent, puis démarrez une nouvelle migration.
Échec du basculement et verrouillage du référentiel source
En cas d’échec d’un basculement en cours de processus, le dépôt source peut rester verrouillé ou archivé. Cela empêche les développeurs d’envoyer (push) vers la source alors que la destination peut toujours être incomplète.
Pour déverrouiller le référentiel source, un administrateur de site doit le déverrouiller à partir du GitHub Enterprise ServerConsole de gestion.
Une fois la source déverrouillée, vous pouvez effectuer une nouvelle tentative de basculement à l'aide de elm migration cutover-to-destination --migration-id MIGRATION-ID, ou l'abandonner avec elm migration cancel --migration-id MIGRATION-ID et démarrer une nouvelle migration quand vous êtes prêt.
La migration doit être redémarrée en raison d’un "force push"
Si quelqu’un effectue un "force push" sur la branche principale du dépôt source pendant qu’une migration est en cours, la synchronisation Git entre la source et la destination est rompue. Les poussées forcées réécrivent l’historique des commits d’une manière qui ne peut pas être réconciliée de manière incrémentielle.
Dans ce cas, interrompez la migration avec elm migration cancel --migration-id MIGRATION-ID et démarrez une nouvelle migration. Avant de redémarrer, communiquez à votre équipe que les push forcés vers la branche par défaut ne sont pas autorisés pendant qu’une migration est active.
Le jeton d’accès a été rejeté
Si votre migration échoue avec une erreur d’authentification, vérifiez que :
- Les deux jetons source et de destination sont personal access tokens (classic). Les jetons granulaires ne sont pas pris en charge.
- Les jetons ont les étendues spécifiées dans Migration de votre référentiel avec Enterprise Live Migrations.
- Si l’organisation de destination applique l’authentification unique SAML, le jeton doit être autorisé pour l’authentification unique.
Si vous avez récemment pivoté un jeton, la migration récupère automatiquement de nouvelles informations d’identification. Vous n’avez pas besoin d’exécuter ghe-config-apply ou de redémarrer le service de migration.
L’URL GHES source a été rejetée
Enterprise Live Migrations nécessite l’URL GitHub Enterprise Server pour utiliser HTTPS. Si l’URL est configurée avec HTTP, la migration échoue à la validation préliminaire.
Collecte des journaux d’activité pour la prise en charge
Lorsque vous contactez Support GitHub, les éléments les plus utiles sont les suivants :
- Offre groupée de support (par défaut) : Exécutez
ghe-support-bundle -usur l’appliance GitHub Enterprise Server . Cela collecte automatiquement tous les journaux ELM. - Sortie de l’état de la migration :
elm migration status --migration-id MIGRATION-ID - ID de migration et heure approximative d’échec (avec fuseau horaire)
- Tous les ID de corrélation des messages d’erreur
Si un bundle de support n’est pas possible, vous pouvez collecter les journaux manuellement :
journalctl -t elm-exporter-migration-manager --since "24 hours ago" > migration-manager.log journalctl -t elm-exporter-backfiller --since "24 hours ago" > backfiller.log journalctl -t elm-exporter-sender --since "24 hours ago" > sender.log journalctl -t elm-exporter-git-syncer --since "24 hours ago" > git-syncer.log
journalctl -t elm-exporter-migration-manager --since "24 hours ago" > migration-manager.log
journalctl -t elm-exporter-backfiller --since "24 hours ago" > backfiller.log
journalctl -t elm-exporter-sender --since "24 hours ago" > sender.log
journalctl -t elm-exporter-git-syncer --since "24 hours ago" > git-syncer.log