Si la migración encuentra un problema, compruebe el estado de la migración con gh elm migration status --migration-id MIGRATION-ID y revise la información de error.
Estados y acciones recomendadas
| Situación | Meaning | Acción recomendada |
|---|---|---|
| Created | La migración ha sido creada, pero aún no ha comenzado. | Ejecute gh elm migration start: |
| Queued | La migración está esperando a iniciarse | Wait |
| Exportación | Los datos se exportan desde el origen | Supervisar con gh elm migration status |
| En procesamiento | Los datos exportados se importan al destino | Supervisar con gh elm migration status |
| Listo para la migración total | La migración inicial se ha completado y la migración está lista para la transición | Cuando esté listo, ejecute gh elm migration cutover |
| Transición | El repositorio de origen se archiva y se aplican los cambios restantes al destino. | Monitor; el estado pasará a Completado. |
| Completed | La migración ha finalizado correctamente | Comprobación del repositorio de destino y reclamación de maniquíes |
| Fallido | La migración encontró un error irrecuperable | Investigar el error (consulte a continuación) |
| En pausa | La migración está en pausa | Compruebe el motivo de pausa y resuelva (consulte a continuación) |
| Finalizado | Se canceló la migración. | N/A |
| Degradado | El destino no es accesible | Comprobación de la conectividad de red entre el dispositivo de GitHub Enterprise Server y GHE.com (consulte a continuación) |
El estado de la migración es "Fallido"
Una migración entra en el estado Error cuando un error irrecuperable impide que continúe. Esto es distinto de los recursos individuales que no se pueden importar; un fallo en la migración significa que la migración en sí misma no puede proceder.
Para investigar, ejecute gh elm migration status --migration-id MIGRATION-ID y revise los detalles del error en la respuesta. Cada error incluye un identificador de correlación con el formato (Correlation ID for Support: UUID). Si se comunica con Soporte de GitHub, proporcione este identificador para que el equipo de soporte técnico pueda investigar.
Después de resolver el problema subyacente, anule la migración con errores con gh elm migration cancel --migration-id MIGRATION-ID y comience una nueva migración.
El estado de la migración es "Pausado"
Una migración entra en el estado Pausado cuando un problema requiere la intervención antes de poder continuar. Ejecute gh elm migration status --migration-id MIGRATION-ID y compruebe el motivo de pausa.
Motivos comunes de pausa:
- Caducidad de credenciales: uno de los personal access tokens (classic) ha caducado. Cree un nuevo token con los ámbitos necesarios y actualícelo con
gh elm credential update. A continuación, reinicie la migración. - Limitación de tasa: La migración alcanzó los límites de tasa de la API. Espere unos minutos y, a continuación, reinicie.
Para reiniciar una migración en pausa después de resolver el problema subyacente:
gh elm migration start --migration-id MIGRATION-ID
El estado de la migración es "Degradado"
Un estado Degradado significa que el servicio de migración del GitHub Enterprise Server dispositivo no puede llegar a la empresa de destino. La migración continúa en el lado de origen, pero el estado de destino es desconocido.
Compruebe la conectividad de red entre el dispositivo y el GitHub Enterprise Server subdominio de GHE.com y ejecute gh elm migration status --migration-id MIGRATION-ID de nuevo. La respuesta de estado incluye una marca de tiempo para el último contacto exitoso con el destino, lo que puede ayudar a evaluar cuánto tiempo ha estado ocurriendo el problema de conectividad.
Migración bloqueada en "Exportando"
Si la migración permanece en el estado Exportación sin ningún cambio de progreso durante 30 minutos o más, el exportador puede estar bloqueado.
-
Ejecute
gh elm migration status --migration-id MIGRATION-IDy observe si los recuentos de recursos cambian. -
Si los recuentos son estáticos, compruebe la conectividad de red del dispositivo con el destino.
-
Revise los registros del exportador en el GitHub Enterprise Server dispositivo (requiere acceso de administrador 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 tarea del exportador ha fallado, debería recuperarse automáticamente. Si no lo hace, póngase en contacto con Soporte de GitHub.
Sincronización de Git no completada
Si gh elm migration status muestra que la inserción inicial de Git no se ha completado después de un período prolongado, compruebe los registros del sincronizador de Git:
journalctl -t elm-exporter-git-syncer --since "2 hours ago"
journalctl -t elm-exporter-git-syncer --since "2 hours ago"
Busque:
connection refused: un problema de red entre el GitHub Enterprise Server dispositivo y el destino. Compruebe las reglas de firewall y la resolución DNS.authentication failed: Puede que el/la personal access token (classic) no tenga los permisos necesarios o que haya caducado.remote: error: Es posible que el destino esté rechazando el envío. Contacte con Soporte de GitHub con los detalles del error.
Algunos recursos no se pudieron importar
Los recursos individuales pueden no importarse sin provocar un error en la migración general. Puede ver un recuento de recursos fallidos en la salida de gh elm migration status --migration-id MIGRATION-ID.
Los recursos con errores solo se muestran después de que se hayan agotado todos los reintentos automáticos, por lo que los errores que vea se confirman como irresolubles sin intervención. Revise los detalles del error en la respuesta de estado: cada recurso fallido en relleno de datos o actualizaciones en tiempo real mostrará "state": "failed".
Si el número y los tipos de recursos con errores son aceptables, puede continuar con la transición. Si no es así, anule la migración, resuelva el problema subyacente y, a continuación, inicie una nueva migración.
El cambio final ha fallado y el repositorio de origen no está disponible
Si falla el cambio definitivo después de que se haya archivado el repositorio de origen, el servicio ELM intentará desarchivar el repositorio. Si se produce un error, un administrador del repositorio puede desarchivar el repositorio. Consulte Archivar repositorios.
Tenga en cuenta que la desarchivación de un repositorio provocará una carga adicional en la instancia, ya que todos los problemas y las solicitudes de incorporación de cambios en el repositorio se volverán a indexar en Elasticsearch.
Después de que el repositorio de origen no esté archivado, puede volver a intentar la migración mediante gh elm migration cutover --migration-id MIGRATION-IDo anular la migración con gh elm migration cancel --migration-id MIGRATION-ID e iniciar una nueva migración cuando esté listo.
La migración debe reiniciarse debido a un empuje forzado
Si alguien hace inserciones forzadas en la rama predeterminada del repositorio de origen mientras una migración está en curso, se rompe la sincronización de Git entre el origen y el destino. Las inserciones forzadas reescriben el historial de compromisos de una manera que no se puede conciliar incrementalmente.
Si esto sucede, anule la migración con gh elm migration cancel --migration-id MIGRATION-ID e inicie una nueva migración. Antes de reiniciar, comunique al equipo que no se permiten envíos forzados a la rama predeterminada mientras una migración está activa.
Se rechazó el token de acceso para la migración
Si se produce un error de autenticación en la migración, compruebe lo siguiente:
- Los tokens de origen y de destino son personal access tokens (classic). Fine-grained personal access tokens no se admiten.
- Si la organización de destino aplica el inicio de sesión único de SAML, el token debe estar habilitado para SSO.
- Ambos tokens tienen los ámbitos especificados en Migración del repositorio con Enterprise Live Migrations.
Si ha girado recientemente un token, la migración recoge automáticamente las nuevas credenciales. No es necesario ejecutar ghe-config-apply ni reiniciar el servicio de migración.
GitHub CLI se rechazó el token de acceso
Enterprise Live Migrations usa dos conjuntos de credenciales. Esta sección se aplica a los tokens de operador creados en el paso 2 y almacenados localmente por gh elm configure.
El operador debe usar un personal access token (classic) para cada punto de conexión:
- El token del operador de origen debe crearse en GitHub Enterprise Server.
- El token del operador de destino debe crearse en GHE.com.
- Ambos tokens tienen los ámbitos especificados en Migración del repositorio con Enterprise Live Migrations.
- El propietario del token debe ser un administrador de la empresa correspondiente. Al seleccionar un ámbito no se concede al usuario acceso administrativo.
- Fine-grained personal access tokens no se admiten.
Respuestas comunes
| Respuesta | Meaning | Solución |
|---|---|---|
401 Bad credentials | El punto de conexión no pudo autenticar el token. Todavía no se han evaluado los ámbitos de autorización. | Compruebe que el token no ha expirado o revocado, que se copió por completo y que no se intercambiaron los tokens de origen y destino. Confirme que cada token se creó en el host donde se está usando. |
403 Forbidden | El token se autenticó, pero su usuario o ámbitos no autorizan la operación. | Usa un personal access token (classic) con admin:enterprise. Confirme que el propietario del token es un administrador de la empresa. Si se aplica el inicio de sesión único de SAML, autorice el token para el inicio de sesión único. |
Resource not accessible by personal access token | El tipo de token o los permisos no son compatibles. Esto suele ocurrir con un fine-grained personal access token. | Reemplácelo por un personal access token (classic) que tenga admin:enterprise. |
404 Not Found | Es posible que la solicitud use la dirección URL de API incorrecta o Enterprise Live Migrations que no esté habilitada para la empresa de destino. | Para GHE.com, use la dirección URL de la API de inquilino, como https:/, sin una barra diagonal final. Compruebe también la dirección URL de la API de origen. Si ambas direcciones URL son correctas, póngase en contacto con Soporte de GitHub para confirmar que Enterprise Live Migrations está habilitada. |
Validar los tokens de forma independiente
Pruebe cada token en el /user punto de conexión antes de usarlo con Enterprise Live Migrations. Estos comandos imprimen encabezados de respuesta, pero descartan el cuerpo de la respuesta.
Para el token de origen (GitHub Enterprise Server):
curl --silent --show-error --output /dev/null --dump-header - \
--header "Authorization: Bearer $SOURCE_OPERATOR_TOKEN" \
"$SOURCE_API_URL/user"
Para el token de destino:
curl --silent --show-error --output /dev/null --dump-header - \
--header "Authorization: Bearer $TARGET_OPERATOR_TOKEN" \
"$TARGET_API_URL/user"
Cada solicitud debe devolver 200 OK. El X-OAuth-Scopes encabezado de respuesta debe incluir admin:enterprise.
Si /user devuelve 200 OK pero un Enterprise Live Migrations comando devuelve 401 Bad credentials, la CLI puede tener un token o una dirección URL diferentes almacenados. Vuelva a ejecutar gh elm configure y asocie cuidadosamente cada token con su punto de conexión correspondiente.
La Enterprise Live Migrations CLI almacena los tokens de operador localmente. Después de rotar un token de operador, vuelva a ejecutar gh elm configure o proporcione las credenciales de reemplazo mediante las opciones de línea de comandos adecuadas.
Esto difiere de los tokens de servicio de migración configurados en el paso 4. Las credenciales actualizadas del servicio de migración se seleccionan automáticamente y no requieren ghe-config-apply ni un reinicio del servicio de migración.
No incluya tokens de acceso en registros, capturas de pantalla, agrupaciones de soporte técnico ni solicitudes de soporte técnico. Si el problema continúa, proporcione Soporte de GitHub el estado HTTP, el nombre de host del punto de conexión, el identificador de migración, la marca de tiempo con la zona horaria y cualquier identificador de correlación, pero no con el token.
Se rechazó la dirección URL de GHES de origen.
Enterprise Live Migrations requiere que la GitHub Enterprise Server dirección URL use HTTPS. Si la dirección URL está configurada con HTTP, se producirá un error en la validación previa de la migración.
Recopilación de registros para soporte técnico
Al ponerse en contacto con Soporte de GitHub, los elementos más útiles son:
- Un paquete de soporte técnico (preferido): ejecute
ghe-support-bundle -uen el GitHub Enterprise Server dispositivo. Esto captura todos los Enterprise Live Migrations registros automáticamente. - Salida del estado de la migración:
gh elm migration status --migration-id MIGRATION-ID - El identificador de migración y la hora aproximada del error (con zona horaria)
- Cualquier identificador de correlación de cualquier mensaje de error
Si no es posible generar un paquete de soporte, puede recopilar los archivos de registro manualmente:
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