# Solução de problemas de migrações dinâmicas do GitHub Enterprise Server para o GHE.com Conselhos para problemas que você pode encontrar com sua migração. > \[!NOTE] > Enterprise Live Migrations está dentro prévia pública e sujeito a alterações. Se a migração encontrar um problema, verifique o status da migração com `elm migration status --migration-id MIGRATION-ID` e revise as informações de erro. ## Status e ações recomendadas | Status | Meaning | Ação recomendada | | ---------------------------- | ---------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ | | **Criado** | A migração foi criada, mas ainda não foi iniciada | Execute `elm migration start` | | **Queued** | A migração está aguardando o início | Wait | | **Exportadores** | Os dados estão sendo exportados da origem | Monitorar com `elm migration status` | | **Em processamento** | Os dados exportados estão sendo importados para o destino | Monitorar com `elm migration status` | | **Pronto para substituição** | A migração inicial está concluída e a migração está pronta para substituição | Quando estiver pronto, execute `elm migration cutover-to-destination` | | **Substituindo** | O repositório de origem é arquivado e as alterações restantes estão sendo aplicadas ao destino | Monitor; o status fará a transição para **Concluído** | | **Completed** | A migração foi concluída com êxito | Verifique o repositório de destino e recupere os modelos | | **Falhou** | A migração encontrou uma falha irrecuperável | Investigar o erro (veja abaixo) | | **Pausado** | A migração está pausada | Verifique o motivo da pausa e resolva (veja abaixo) | | **Terminado** | A migração foi cancelada | N/A | | **Degradado** | O destino é inacessível | Verificar a conectividade de rede entre o dispositivo GitHub Enterprise Server e GHE.com (veja abaixo) | ## O status da migração é "Falha" Uma migração entra no status **com falha** quando um erro irrecuperável o impede de continuar. Isso é diferente dos recursos individuais que não foram importados. Uma migração com falha significa que a migração em si não pode continuar. Para investigar, execute `elm migration status --migration-id MIGRATION-ID` e examine os detalhes do erro na resposta. Cada falha inclui uma ID de correlação no formato `(Correlation ID for Support: UUID)`. Se você entrar em contato Suporte do GitHub, forneça esta ID para que a equipe de suporte possa investigar. Depois de resolver o problema subjacente, anule a migração falha com `elm migration cancel --migration-id MIGRATION-ID` e inicie uma nova migração. ## O status da migração é "Pausado" Uma migração entra no status **pausado** quando um problema requer sua intervenção antes que ele possa continuar. Execute `elm migration status --migration-id MIGRATION-ID` e verifique o motivo da pausa. Motivos comuns de pausa: * **Expiração da credencial**: Uma das personal access tokens (classic) expirou. Crie um novo token com os escopos necessários e atualize-o com `elm credential update`. Em seguida, reinicie a migração. * **Limitação de taxa**: a migração esbarrou nos limites de taxa da API. Aguarde alguns minutos e reinicie. Para reiniciar uma migração pausada depois de resolver o problema subjacente: ```shell elm migration start --migration-id MIGRATION-ID ``` ## O status da migração é "Degradado" Um status **degradado** significa que o serviço de migração no GitHub Enterprise Server dispositivo não pode alcançar a empresa de destino. A migração continua no lado da origem, mas o status de destino é desconhecido. Verifique a conectividade de rede entre o GitHub Enterprise Server equipamento e o seu subdomínio de GHE.com, em seguida, execute `elm migration status --migration-id MIGRATION-ID` novamente. A resposta de status inclui um carimbo de data/hora do último contato bem-sucedido com o destino, ajudando a determinar há quanto tempo o problema de conectividade está ocorrendo. ## Migração presa em "Exportando" Se a migração permanecer no status **de Exportação** sem nenhuma alteração de progresso por 30 minutos ou mais, o exportador poderá ficar preso. 1. Execute `elm migration status --migration-id MIGRATION-ID` e observe se as contagens de recursos estão sendo alteradas. 2. Se as contagens forem estáticas, verifique a conectividade de rede do dispositivo com o destino. 3. Examine os logs do GitHub Enterprise Server exportador no dispositivo (requer acesso de administrador SSH): ```shell copy journalctl -t elm-exporter-backfiller --since "1 hour ago" | tail -50 journalctl -t elm-exporter-sender --since "1 hour ago" | tail -50 ``` 4. Se a tarefa do exportador falhar, ela deverá ser recuperada automaticamente. Se isso não acontecer, entre em contato com Suporte do GitHub. ## Sincronização do Git não concluída Se `elm migration status` indicar que o push inicial do Git não foi concluído após um longo período, verifique os logs do sincronizador Git: ```shell copy journalctl -t elm-exporter-git-syncer --since "2 hours ago" ``` Pesquisar por: * **`connection refused`**: um problema de rede entre o GitHub Enterprise Server dispositivo e o destino. Verifique as regras de firewall e a resolução DNS. * **`authentication failed`**: O personal access token (classic) pode não ter os escopos necessários ou pode ter expirado. * **`remote: error`**: o destino pode estar rejeitando o push. Entre em contato com Suporte do GitHub e informe os detalhes do erro. ## Alguns recursos não foram importados Os recursos individuais podem falhar ao importar sem causar falha na migração geral. Você pode ver uma contagem de recursos falhados na saída de `elm migration status --migration-id MIGRATION-ID`. Os recursos com falha são mostrados somente depois que todas as novas tentativas automáticas tiverem sido esgotadas, portanto, todas as falhas que você vê são confirmadas como insolvíveis sem intervenção. Revise os detalhes do erro na resposta de status: cada recurso com falha em provisionamento ou atualizações ao vivo exibirá `"state": "failed"`. Se o número e os tipos de recursos com falha forem aceitáveis, você poderá continuar com a substituição. Caso contrário, anule a migração, resolva o problema subjacente e inicie uma nova migração. ## A migração falhou e o repositório de origem não está disponível Se uma transição falhar após o repositório de origem ter sido arquivado, o serviço ELM tentará desarquivar o repositório. Se isso falhar, um administrador de repositório poderá desarquivar o repositório. Consulte [Arquivar repositórios](/pt/enterprise-server@3.22/repositories/archiving-a-github-repository/archiving-repositories#unarchiving-a-repository). Lembre-se de que desarquivar um repositório causará carga adicional na instância, pois todos os problemas e solicitações de pull no repositório serão reindexados no Elasticsearch. Depois que o repositório de origem for desarquivado, você poderá tentar novamente a alternância usando `elm migration cutover-to-destination --migration-id MIGRATION-ID` ou abortar a migração com `elm migration cancel --migration-id MIGRATION-ID` e iniciar uma nova migração quando estiver pronto. ## A migração deve ser reiniciada devido a um push forçado Se alguém executar um push forçado para o ramo padrão do repositório de origem durante uma migração em andamento, a sincronização do Git entre o repositório de origem e o de destino é interrompida. Forçar pushes reescreve o histórico de commit de uma maneira que não pode ser reconciliada incrementalmente. Se isso acontecer, aborte a migração com `elm migration cancel --migration-id MIGRATION-ID` e inicie uma nova migração. Antes de reiniciar, comunique à sua equipe que pushes forçados para a ramificação padrão não são permitidos enquanto uma migração está ativa. ## O token de acesso foi rejeitado Se a migração falhar com um erro de autenticação, verifique se: * Os tokens de origem e de destino são personal access tokens (classic). Não há suporte para tokens refinados. * Os tokens têm os escopos especificados em [Migrando seu repositório com Enterprise Live Migrations](/pt/enterprise-server@3.22/migrations/elm/migrate-your-repository#1-create-access-tokens). * Se a organização de destino impor o logon único do SAML, o token deverá ser autorizado para SSO. Se você tiver girado um token recentemente, a migração obterá novas credenciais automaticamente. Você não precisa executar `ghe-config-apply` ou reiniciar o serviço de migração. ## A URL de origem do GHES foi rejeitada Enterprise Live Migrations requer a GitHub Enterprise Server URL para usar HTTPS. Se a URL estiver configurada com HTTP, a migração falhará na validação de pré-vôo. ## Coletando logs para suporte Ao entrar em contato com Suporte do GitHub, os artefatos mais úteis são: 1. **Um pacote de suporte** (preferencial): execute `ghe-support-bundle -u` no dispositivo GitHub Enterprise Server. Isso captura automaticamente todos os logs do ELM. 2. **Saída de status de migração**: `elm migration status --migration-id MIGRATION-ID` 3. **A ID de migração** e o tempo aproximado de falha (com fuso horário) 4. **Todas as IDs de correlação** de mensagens de erro Se um pacote de suporte não for possível, você poderá coletar logs manualmente: ```shell copy 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 ```