Wenn bei Ihrer Migration ein Problem auftritt, überprüfen Sie den Migrationsstatus mit gh elm migration status --migration-id MIGRATION-ID und sehen Sie sich die Fehlerinformationen an.
Status und empfohlene Aktionen
| Status | Bedeutung | Empfohlene Maßnahme |
|---|---|---|
| Erstellt | Die Migration wurde erstellt, aber noch nicht gestartet. | Ausführen gh elm migration start |
| Queued | Die Migration wartet auf den Start | Warten |
| Exportieren | Daten werden aus der Quelle exportiert. | Überwachen mit gh elm migration status |
| Verarbeitung | Exportierte Daten werden an das Ziel importiert. | Überwachen mit gh elm migration status |
| Bereit für die Umschaltung | Die erste Migration ist abgeschlossen, und die Migration ist für die Übernahme bereit. | Wenn Sie bereit sind, führen Sie gh elm migration cutover aus. |
| Migrieren per Cutover | Das Quell-Repository wird archiviert, und die verbleibenden Änderungen werden auf das Ziel angewendet. | Monitor; der Status wechselt zu "Abgeschlossen" |
| Completed | Die Migration wurde erfolgreich abgeschlossen. | Überprüfen des Ziel-Repositorys und Zurückfordern von Mannequins |
| Fehler | Bei der Migration ist ein nicht wiederherstellbarer Fehler aufgetreten. | Untersuchen des Fehlers (siehe unten) |
| Pausiert | Die Migration wird angehalten. | Überprüfen Sie den Grund für die Unterbrechung und beheben Sie ihn (siehe unten). |
| Beendet | Die Migration wurde abgebrochen. | N/A |
| Beeinträchtigt | Das Ziel ist nicht erreichbar. | Überprüfen der Netzwerkkonnektivität zwischen der GitHub Enterprise Server-Appliance und GHE.com (siehe unten) |
Der Migrationsstatus lautet "Fehlgeschlagen"
Eine Migration wechselt in den Status "Fehler" , wenn ein nicht behebbarer Fehler verhindert, dass sie fortgesetzt wird. Dies unterscheidet sich von einzelnen Ressourcen, die nicht importiert werden konnten . Eine fehlgeschlagene Migration bedeutet, dass die Migration selbst nicht fortgesetzt werden kann.
Führen Sie gh elm migration status --migration-id MIGRATION-ID aus und prüfen Sie die Fehlerdetails in der Antwort, um sie zu untersuchen. Jeder Fehler enthält eine Korrelations-ID im Format (Correlation ID for Support: UUID). Wenn Sie kontaktieren GitHub-Support, geben Sie diese ID an, damit das Supportteam untersuchen kann.
Nachdem das zugrunde liegende Problem behoben wurde, brechen Sie die fehlgeschlagene Migration mit gh elm migration cancel --migration-id MIGRATION-ID ab und starten Sie eine neue Migration.
Der Migrationsstatus ist „Angehalten“
Eine Migration wechselt in den Status " Angehalten ", wenn für ein Problem ein Eingreifen erforderlich ist, bevor sie fortgesetzt werden kann. Führen Sie gh elm migration status --migration-id MIGRATION-ID aus und überprüfen Sie den Grund für die Unterbrechung.
Häufige Pausengründe:
- Anmeldeinformationen abgelaufen: Eine der personal access tokens (classic) Anmeldeinformationen ist abgelaufen. Erstellen Sie ein neues Token mit den erforderlichen Bereichen, und aktualisieren Sie es mit
gh elm credential update. Starten Sie dann die Migration neu. - Ratenbegrenzung: Die Migration stieß auf API-Ratenbegrenzungen. Warten Sie einige Minuten, und starten Sie es dann neu.
So starten Sie eine angehaltene Migration nach dem Beheben des zugrunde liegenden Problems neu:
gh elm migration start --migration-id MIGRATION-ID
Migrationsstatus ist "Herabgestuft"
Ein herabgestufter Status bedeutet, dass der Migrationsdienst in der GitHub Enterprise Server Appliance das Zielunternehmen nicht erreichen kann. Die Migration wird auf der Quellseite fortgesetzt, der Zielstatus ist jedoch unbekannt.
Überprüfen Sie die Netzwerkkonnektivität zwischen dem GitHub Enterprise Server-Gerät und Ihrer Unterdomäne GHE.com, und führen Sie dann gh elm migration status --migration-id MIGRATION-ID erneut aus. Die Statusantwort enthält einen Zeitstempel für den letzten erfolgreichen Kontakt mit dem Ziel, mit dem Sie beurteilen können, wie lange das Verbindungsproblem aufgetreten ist.
Die Migration bleibt beim "Exportieren" hängen
Wenn Ihre Migration 30 Minuten oder länger im Status Exportieren ohne Fortschritt verbleibt, hat sich der Exporter möglicherweise aufgehängt.
-
Führen Sie
gh elm migration status --migration-id MIGRATION-IDaus und notieren Sie, ob sich die Ressourcenzahlen ändern. -
Wenn die Zählerstände unverändert bleiben, überprüfen Sie die Netzwerkverbindung der Appliance zum Ziel.
-
Überprüfen von Exporterprotokollen in der GitHub Enterprise Server Appliance (erfordert SSH-Administratorzugriff):
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 -
Wenn die Exporteraufgabe abgestürzt ist, sollte sie automatisch wiederhergestellt werden. Wenn dies nicht der Fall ist, wenden Sie sich an GitHub-Support.
Git-Synchronisierung nicht abgeschlossen
Wenn gh elm migration status angezeigt wird, dass der anfängliche Git-Push nach einem längeren Zeitraum nicht abgeschlossen wurde, überprüfen Sie die Git-Synchronisierungsprotokolle:
journalctl -t elm-exporter-git-syncer --since "2 hours ago"
journalctl -t elm-exporter-git-syncer --since "2 hours ago"
Suchen nach:
connection refused: Ein Netzwerkproblem zwischen der GitHub Enterprise Server Appliance und dem Ziel. Überprüfen Sie Firewallregeln und DNS-Auflösung.authentication failed: personal access token (classic) verfügt möglicherweise nicht über die erforderlichen Berechtigungsbereiche oder ist abgelaufen.remote: error: Das Ziel kann den Push ablehnen. Wenden Sie sich mit den Fehlerdetails an GitHub-Support.
Einige Ressourcen konnten nicht importiert werden.
Einzelne Ressourcen können nicht importiert werden, ohne dass die gesamte Migration fehlschlägt. Die Anzahl der fehlgeschlagenen Ressourcen wird in der Ausgabe von gh elm migration status --migration-id MIGRATION-IDangezeigt.
Fehlgeschlagene Ressourcen werden erst angezeigt, nachdem alle automatischen Wiederholungsversuche erschöpft sind, sodass die angezeigten Fehler ohne Eingreifen als unlösbar bestätigt werden. Überprüfen Sie die Fehlerdetails in der Statusantwort: "state": "failed" wird für jede Ressource angezeigt, die in der Rückfüllung oder bei Live-Updates fehlgeschlagen ist.
Wenn die Anzahl und Arten der fehlgeschlagenen Ressourcen als akzeptabel gelten, können Sie mit der Übernahme fortfahren. Falls nicht, beenden Sie die Migration, beheben Sie das zugrunde liegende Problem, und starten Sie dann eine neue Migration.
Die Umstellung ist fehlgeschlagen und das Quell-Repository ist nicht verfügbar.
Wenn die Umstellung fehlschlägt, nachdem das Quell-Repository archiviert wurde, versucht der ELM-Dienst, die Archivierung des Repositorys rückgängig zu machen. Wenn dies fehlschlägt, kann ein Repositoryadministrator die Archivierung des Repositorys aufheben. Siehe Repositorys archivieren.
Beachten Sie, dass das Aufheben der Archivierung eines Repositorys zusätzliche Last für die Instanz verursacht, da alle Probleme und Pullanforderungen im Repository in elasticsearch neu indiziert werden.
Nachdem die Archivierung des Quell-Repositorys rückgängig gemacht wurde, können Sie entweder die Umschaltung mit gh elm migration cutover --migration-id MIGRATION-ID erneut versuchen oder die Migration mit gh elm migration cancel --migration-id MIGRATION-ID abbrechen und eine neue Migration starten, wenn Sie bereit sind.
Die Migration muss aufgrund eines erzwungenen Push neu gestartet werden.
Wenn jemand während einer Migration in den Standardbranch des Quell-Repositorys zwangsweise pusht, wird die Git-Synchronisierung zwischen Quell- und Ziel-Repository unterbrochen. Erzwingt das Neuschreiben des Commitverlaufs auf eine Weise, die nicht schrittweise abgeglichen werden kann.
Wenn dies der Fall ist, brechen Sie die Migration mit gh elm migration cancel --migration-id MIGRATION-ID ab und starten Sie eine neue Migration. Teilen Sie Ihrem Team vor dem Neustart mit, dass erzwungene Pushs zu dem Standardzweig nicht gestattet sind, solange eine Migration aktiv ist.
Das Zugriffstoken für die Migration wurde abgelehnt
Wenn ihre Migration mit einem Authentifizierungsfehler fehlschlägt, überprüfen Sie Folgendes:
- Sowohl die Quell- als auch die Zieltoken sind personal access tokens (classic). Fine-grained personal access tokens werden nicht unterstützt.
- Wenn die Zielorganisation einmalige SAML-Anmeldung erzwingt, muss das Token für SSO autorisiert werden.
- Beide Token weisen die bereiche auf, die in Migrieren Ihres Repositorys mit Enterprise Live-Migrationen angegeben sind.
Wenn Sie kürzlich ein Token gedreht haben, nimmt die Migration automatisch neue Anmeldeinformationen auf. Sie müssen den Migrationsdienst nicht ausführen ghe-config-apply oder neu starten.
GitHub CLI Das Access-Token wurde abgelehnt
Enterprise Live Migrations verwendet zwei Gruppen von Anmeldeinformationen. Dieser Abschnitt gilt für die operatortoken, die in Schritt 2 erstellt und lokal gespeichert werden.gh elm configure
Der Operator muss für jeden Endpunkt einen personal access token (classic) verwenden:
- Das Token des Quelloperators muss auf GitHub Enterprise Server erstellt werden.
- Das Token des Zieloperators muss auf GHE.com erstellt werden.
- Beide Token weisen die bereiche auf, die in Migrieren Ihres Repositorys mit Enterprise Live-Migrationen angegeben sind.
- Der Tokenbesitzer muss ein Administrator des entsprechenden Unternehmens sein. Das Auswählen eines Bereichs gewährt dem Benutzer keinen administratorbezogenen Zugriff.
- Fine-grained personal access tokens werden nicht unterstützt.
Allgemeine Antworten
| Antwort | Bedeutung | Abhilfe |
|---|---|---|
401 Bad credentials | Der Endpunkt konnte das Token nicht authentifizieren. Autorisierungsbereiche wurden noch nicht ausgewertet. | Überprüfen Sie, ob das Token nicht abgelaufen oder widerrufen wurde, dass es vollständig kopiert wurde und dass die Quell- und Zieltoken nicht ausgetauscht wurden. Vergewissern Sie sich, dass jedes Token auf dem Host erstellt wurde, auf dem es verwendet wird. |
403 Forbidden | Das Token wurde authentifiziert, aber sein Benutzer oder seine Berechtigungen sind nicht zur Ausführung der Operation autorisiert. | Verwenden Sie ein personal access token (classic) mit admin:enterprise. Vergewissern Sie sich, dass der Tokenbesitzer ein Administrator des Unternehmens ist. Wenn SAML SSO gilt, autorisieren Sie das Token für SSO. |
Resource not accessible by personal access token | Der Tokentyp oder die Berechtigungen werden nicht unterstützt. Dies tritt häufig mit einem fine-grained personal access token. | Ersetzen Sie es durch ein personal access token (classic)-Element, das admin:enterprise enthält. |
404 Not Found | Die Anforderung verwendet möglicherweise die falsche API-URL oder Enterprise Live Migrations ist für das Zielunternehmen nicht aktiviert. | Verwenden Sie für die Mandanten-API-URL, wie z. B. , ohne abschließenden Schrägstrich. Überprüfen Sie auch die Quell-API-URL. Wenn beide URLs korrekt sind, wenden Sie sich an GitHub-Support, um zu bestätigen, dass Enterprise Live Migrations aktiviert ist. |
Unabhängiges Überprüfen der Token
Testen Sie jedes Token gegen den /user-Endpunkt, bevor Sie es mit Enterprise Live Migrations verwenden. Diese Befehle drucken Antwortheader, verwerfen aber den Antworttext.
Für das Quelltoken (GitHub Enterprise Server):
curl --silent --show-error --output /dev/null --dump-header - \
--header "Authorization: Bearer $SOURCE_OPERATOR_TOKEN" \
"$SOURCE_API_URL/user"
Für das Zieltoken:
curl --silent --show-error --output /dev/null --dump-header - \
--header "Authorization: Bearer $TARGET_OPERATOR_TOKEN" \
"$TARGET_API_URL/user"
Jede Anfrage sollte 200 OK zurückgeben. Der X-OAuth-Scopes Antwortheader sollte admin:enterprise enthalten.
Wenn /user``200 OK zurückgibt, ein Enterprise Live Migrations-Befehl jedoch 401 Bad credentials, hat die CLI möglicherweise ein anderes Token oder eine andere URL gespeichert. Führen Sie gh elm configure erneut aus und ordnen Sie jedes Token sorgfältig dem entsprechenden Endpunkt zu.
Operatortoken werden lokal von der Enterprise Live Migrations CLI gespeichert. Führen Sie nach dem Rotieren eines Operator-Tokens gh elm configure erneut aus, oder geben Sie die neuen Anmeldeinformationen mithilfe der entsprechenden Befehlszeilenoptionen an.
Dies unterscheidet sich von den in Schritt 4 konfigurierten Migrationsdiensttoken. Aktualisierte Anmeldeinformationen des Migrationsdiensts werden automatisch übernommen und erfordern weder ghe-config-apply noch einen Neustart des Migrationsdiensts.
Schließen Sie keine Zugriffstoken in Protokolle, Screenshots, Supportpakete oder Supportanfragen ein. Wenn das Problem weiterhin besteht, stellen Sie GitHub-Support den HTTP-Status, den Endpunkthostnamen, die Migrations-ID, den Zeitstempel mit Zeitzone und alle Korrelations-ID bereit, aber nicht das Token.
Die Quell-GHES-URL wurde abgelehnt.
Enterprise Live Migrations erfordert, dass die GitHub Enterprise Server URL HTTPS verwendet. Wenn die URL mit HTTP konfiguriert ist, schlägt die Migration die Preflight-Überprüfung fehl.
Sammeln von Protokollen zur Unterstützung
Bei der Kontaktaufnahme mit GitHub-Support sind die hilfreichsten Artefakte:
- Ein Support-Paket (bevorzugt): Führen Sie
ghe-support-bundle -uauf der GitHub Enterprise Server Appliance aus. Dadurch werden alle Enterprise Live Migrations Protokolle automatisch erfasst. - Ausgabe des Migrationsstatus:
gh elm migration status --migration-id MIGRATION-ID - Die Migrations-ID und ungefähre Fehlerzeit (mit Zeitzone)
- Beliebige Korrelations-IDs aus Fehlermeldungen
Wenn ein Supportpaket nicht möglich ist, können Sie Protokolle manuell sammeln:
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