O que é EOFS?

O EOFS (End of Full Support) é uma etapa no ciclo de vida de products da Alibaba Cloud. O MongoDB 3.4 entrou na fase EOFS, o que significa:

Como verifico se minha instância é afetada?

1. Faça login no console do MongoDB.

2. Na lista de instâncias, verifique a coluna Database Version da sua instância.

3. Se a versão exibida for 3.4, sua instância é afetada pelo EOFS e deve ser atualizada o mais rápido possível.

Quais são as restrições específicas após o EOFS?

Tabela de referência rápida de caminhos de atualização

Encontre seu caminho de atualização com base na arquitetura e no tipo de armazenamento da sua instância:

Instâncias standalone podem ser atualizadas diretamente?

Sim. Instâncias Standalone 3.4 podem ser atualizadas diretamente para uma versão principal superior pelo console.

A versão 4.2 é a máxima para instâncias de disco local?

Instâncias de disco local podem ser atualizadas até a versão 4.2 via console. Para atualizar para a 5.0 ou superior, migre primeiro para uma instância de disco em nuvem e então continue a atualização. Recomendamos criar uma nova instância de disco em nuvem de versão superior e migrar os dados usando o DTS pelos seguintes motivos:

• Podem existir problemas de compatibilidade entre versões inferiores e superiores. A migração via DTS ajuda a identificar incompatibilidades antecipadamente, enquanto uma atualização de versão principal não pode ser revertida. Para informações sobre compatibilidade entre versões principais, consulte .

• Múltiplas atualizações resultam em múltiplas desconexões breves. Para了解 o impacto das atualizações de versão principal, consulte Upgrade database major version.

É possível atualizar diretamente da 3.4 para a 4.2 (pulando a 4.0)?

• Instâncias do tipo replica set e sharded cluster executando a versão 3.4 podem ser atualizadas diretamente para a 4.2. O backend realiza a atualização da versão principal passo a passo (3.4 → 3.6 → 4.0 → 4.2), e cada etapa causa uma breve desconexão. Não é necessária intervenção manual nas versões intermediárias.

• Instâncias standalone executando a versão 3.4 podem ser atualizadas apenas para a 4.0.

Por quanto tempo a atualização interromperá meu service?

• Replica set e sharded cluster: A atualização aciona de 1 a 2 failovers primário/secundário, cada um causando uma breve desconexão de aproximadamente 30 segundos.

  Nota

  Atualizações entre versões (como da 3.4 para a 4.2): O backend atualiza a versão principal passo a passo. Cada etapa de versão aciona múltiplos failovers e de 1 a 2 desconexões breves. Execute as atualizações fora do horário de pico e garanta que sua aplicação possua um mecanismo de reconexão.

  Reduzindo o impacto: Recomendamos conectar-se ao banco de dados usando o ConnectionStringURI em ambientes de produção.

  Ao conectar-se via ConnectionStringURI, o nó conectado permanece sempre como o nó primário, evitando interrupções de leitura/escrita causadas por failover primário/secundário. Para mais informações sobre conexão via ConnectionStringURI, consulte Replica set instance connection ou Connect to a sharded cluster instance.

• Instâncias standalone: A instância é reiniciada automaticamente durante a atualização, causando uma interrupção de service de aproximadamente 2 minutos.

A atualização causará perda de dados?

Não. O processo de atualização não causa perda de dados. No entanto, recomendamos criar manualmente um backup completo antes de atualizar, por precaução.

Minhas credenciais de conta mudarão após a atualização?

Não. Contas e senhas permanecem inalteradas após a atualização.

Minha string de conexão mudará após a atualização?

• Atualização local (replica set/sharded cluster com disco local): A string de conexão permanece inalterada.

• Migração via DTS (instâncias standalone): A nova instância terá uma string de conexão diferente. Atualize a configuração de conexão no código da sua aplicação após a atualização.

Posso reverter após a atualização?

Não. Downgrades não são suportados após uma atualização de versão principal. Antes de atualizar, certifique-se de realizar testes de compatibilidade e backup de dados.

Preciso verificar o espaço em disco antes de atualizar?

Sim. Recomendamos que o espaço livre em disco seja de pelo menos 20% antes da atualização para garantir espaço suficiente para reorganização de dados durante o processo. Como a fase EOFS foi atingida, a expansão de disco não está mais disponível. Se o espaço livre estiver abaixo de 20%, tente as seguintes alternativas:

1. Limpe dados redundantes: Exclua coleções, índices ou dados temporários não utilizados para liberar espaço antes da atualização.

2. Tente a atualização diretamente: 20% é uma recomendação, não um limite rígido. As atualizações ainda podem ter sucesso com um pouco menos de espaço livre. Se a atualização falhar devido a espaço insuficiente, o sistema reverte automaticamente sem afetar a instância.

3. Use a migração via DTS: Compre uma nova instância de versão superior com maior espaço em disco, migre os dados usando o DTS e libere a instância antiga após a migração. Essa abordagem não é limitada pelo espaço em disco.

Quais riscos de compatibilidade existem?

As alterações de compatibilidade introduzidas ao atualizar da versão 3.4 para a 4.0 e 4.2 são as seguintes:

Atualizando para a 4.0 (via 3.6):

Atualizando para a 4.2 (via 3.6 → 4.0 → 4.2, inclui todas as alterações acima, mais as seguintes):

Para descrições completas das alterações de compatibilidade de cada versão, consulte Compatibility changes in MongoDB major version upgrades.

Atualização direta pelo console (replica set/sharded cluster)

Verificação pós-atualização

Após a conclusão da atualização, execute as seguintes verificações:

1. Confirmação de versão: Confirme no console que a versão do banco de dados mudou para a versão alvo.

2. Teste de conexão: Conecte-se à instância usando um cliente e confirme que a conexão está normal.

3. Integridade dos dados: Verifique se os dados críticos de negócios estão completos.

4. Funcionalidade da aplicação: Teste as funções principais de negócios para confirmar que estão funcionando adequadamente.

5. Monitoramento de desempenho: Observe as métricas de desempenho após a atualização para confirmar que estão normais.

A instância está prestes a expirar, mas não pode ser atualizada a tempo

Se você não conseguir concluir a atualização antes da expiração da instância, envie um ticket o mais rápido possível com as seguintes informações:

• ID da instância

• Data de expiração atual

• Plano de atualização e cronograma

A equipe de suporte técnico prestará assistência com base na sua situação específica.

A instância expirou e está bloqueada

Se sua instância expirou e entrou no estado de bloqueio:

1. Cronograma de bloqueio: Do dia 1 ao dia 15 após a expiração, a instância fica bloqueada e inacessível. No 16º dia após a expiração, os recursos de computação da instância são liberados. No 23º dia após a expiração, os dados deixam de ser retidos.

   Aviso

   • O cronograma acima aplica-se apenas a instâncias replica set 3.4.

   • Instâncias standalone e sharded cluster de disco local não suportam restauração da lixeira após a liberação. Atualize a versão principal o mais rápido possível durante o período de bloqueio (do dia 1 ao dia 15 após a expiração). Não espere até que os recursos de computação sejam liberados. Para mais informações, consulte Recycle bin precautions.

2. Método de recuperação: Instâncias do MongoDB no estado bloqueado ainda podem ser atualizadas para uma versão principal superior. Você pode primeiro atualizar a versão principal e depois renovar a assinatura.

3. Atualize imediatamente após a recuperação: Após o acesso ser restaurado, atualize a versão principal do banco de dados o mais rápido possível.

P1: Minha instância está prestes a expirar e não consigo renová-la. O que devo fazer?

R: Instâncias standalone, replica set e sharded cluster podem ser atualizadas diretamente para a 4.0 ou 4.2 pelo console. Após a atualização, você pode renovar normalmente. Se tiver circunstâncias especiais, envie um ticket imediatamente com uma explicação.

P2: Por que a renovação automática parou de funcionar?

R: O MongoDB 3.4 deixou de suportar services de renovação a partir de 30 de junho de 2026, o que faz com que a renovação automática pare de funcionar. O sistema notificará você via SMS e mensagens internas antes da data do EOFS. Você precisa atualizar a versão principal do banco de dados para restaurar a renovação.

P3: Devo atualizar para a 4.0 ou 4.2?

R:

• Se o seu código usa o comando group, recomendamos atualizar primeiro para a 4.0 (o comando group ainda está disponível, mas obsoleto na 4.0). Após concluir a refatoração do código, atualize para a 4.2.

• Se você não usa o comando group, pode atualizar diretamente para a 4.2. A versão 4.2 suporta recuperação de espaço em disco via console (compact), enquanto a 4.0 não suporta.

P4: Preciso modificar meu código Java após a atualização?

R: Atualizar da 3.4 para a 4.0/4.2 geralmente não requer modificações no código Java, mas confirme:

• Você não está usando o comando group (removido na 4.2)

• Você não está usando comandos removidos como copydb, clone, cloneCollection, geoNear ou repairDatabase

• Sua versão do Java Driver é compatível com a versão alvo do MongoDB (recomendamos usar a versão do Driver recomendada oficialmente pelo MongoDB, consulte Matriz de Compatibilidade de Drivers)

P5: Quanto tempo leva para migrar 200 GB de dados?

R: Usando a migração via DTS, 200 GB de dados geralmente são concluídos em algumas horas. A migração completa é gratuita. Se for necessária migração incremental (switchover sem tempo de inatividade), você deve primeiro habilitar o oplog na instância de origem.

P6: Posso cancelar o processo de atualização?

R: Uma tarefa de atualização em andamento não pode ser cancelada. No entanto, você pode modificar o tempo de switchover para adiar a troca até fora do horário de pico. Recomendamos iniciar atualizações fora do horário de pico.

P7: Apenas 2 nós são exibidos no console do replica set após a atualização

R: Isso é normal. O nó Hidden do replica set não é exibido no console por padrão. A instância ainda mantém uma arquitetura de três nós, o que não afeta a alta disponibilidade.

P8: Os dados são retidos após a expiração da instância?

R: A versão 3.4 possui apenas instâncias de disco local.

Após renovar e restaurar o acesso, você pode exportar os dados. Após a conclusão da exportação, você pode cancelar a assinatura da instância.

P9: Existem problemas de compatibilidade da 3.4 para a 4.0?

R: Não há problemas de compatibilidade de alto risco conhecidos da 3.4 para a 4.0. As principais alterações incluem o aggregate retornando um cursor em vez de um único documento, a opção de consulta snapshot deixando de ser suportada e o reIndex adicionando um bloqueio global de escrita. Recomendamos verificar seu código em relação à lista de alterações de compatibilidade antes de atualizar.

P10: Posso mudar para o faturamento pagamento conforme o uso após o EOFS?

R: Não. Após o EOFS, você não pode renovar nem mudar para o faturamento pagamento conforme o uso. Após a expiração, a instância entra em um período de bloqueio de 15 dias, após o qual os recursos são liberados. A única solução é atualizar a versão principal do banco de dados.

P11: Como posso concluir a atualização sem pessoal de operações?

R: Recomendamos o seguinte:

1. Envie um ticket com as informações da sua instância e requisitos de atualização. A equipe de suporte técnico fornecerá assistência.

2. Entre em contato com um parceiro da Alibaba Cloud para services de atualização.

P12: A atualização falha com o erro "InvalidSaleComponentFault"

R: Isso geralmente ocorre porque a especificação selecionada não está disponível para a versão alvo. Por exemplo, o tipo dedicado pode não ter uma especificação de 8 núcleos e 32 GB. Selecione uma especificação suportada pela versão alvo durante a atualização ou envie um ticket para confirmar a lista de especificações disponíveis.

P13: O Navicat não consegue conectar a instâncias 3.4

R: A versão 3.4 pode ter problemas de compatibilidade com drivers mais recentes do Navicat. Recomendamos usar uma versão mais antiga do driver do Navicat ou usar o mongo shell / mongosh para conectar. Após atualizar para a 4.0/4.2, você pode usar a versão mais recente do Navicat.