Todos os produtos
Search
Central de documentação

ApsaraMQ for RocketMQ:Migrate a self-managed Apache RocketMQ cluster to ApsaraMQ for RocketMQ

Última atualização: Jun 27, 2026

Ao executar um cluster Apache RocketMQ autogerenciado, você assume a responsabilidade por aplicar patches, dimensionar, monitorar e proteger cada nó broker. O ApsaraMQ for RocketMQ elimina essa sobrecarga ao oferecer um serviço de mensagens totalmente gerenciado. A ferramenta de migração integrada transfere seu cluster para uma instância do ApsaraMQ for RocketMQ com interrupção mínima: sincroniza metadados, roteia o tráfego por meio de uma troca gradual por tópico e oferece suporte a operações em lote e rollback em todas as etapas.

Pré-requisitos

Antes de começar, verifique se você tem:

  • Uma instância do ApsaraMQ for RocketMQ 5.0. Consulte Criar uma instância

  • A função vinculada ao serviço para migração, conforme descrito na tabela a seguir. Consulte Funções vinculadas ao serviço

    Item

    Valor

    Nome da função

    AliyunServiceRoleForRMQMigration

    Política

    AliyunServiceRolePolicyForRMQMigration

    Finalidade

    Permite que o ApsaraMQ for RocketMQ acesse Virtual Private Clouds (VPCs) durante a migração

Avaliar o cluster atual

Antes de iniciar, verifique a compatibilidade do cluster de origem e planeje o escopo da migração.

Requisitos do cluster de origem

O cluster Apache RocketMQ de origem deve atender aos seguintes requisitos. Caso contrário, abra um ticket.

Requisito

Detalhes

Versão do Broker

Apache RocketMQ 4.x ou 5.x

Rede

Implantado em uma VPC. Se estiver on-premises, o cluster deve ser acessível a partir de uma VPC.

Região

China (Hangzhou), China (Shanghai), China (Beijing), China (Shenzhen), China (Zhangjiakou), China (Hong Kong), EUA (Silicon Valley) ou Singapura

Limites da instância de destino

Parâmetro

Limite

Tamanho da mensagem

Máximo de 4 MB

Período de retenção de mensagens

De 24 horas (mínimo) a 720 horas (máximo)

Atraso de mensagem agendada

Standard Edition por assinatura e pagamento conforme o uso, Standard e Professional Edition serverless: 7 dias. Professional Edition e Enterprise Platinum Edition por assinatura e pagamento conforme o uso: 40 dias.

Para a lista completa, consulte Cotas e limites.

Compatibilidade de SDK

SDK

Linguagem

Versão

Atualização necessária?

Apache RocketMQ Remoting SDK

Java

5.x

Não. Compatível com o ApsaraMQ for RocketMQ.

Apache RocketMQ Remoting SDK

Java, C++

4.x

Sim, se você usar PullConsumer, DefaultLitePullConsumer ou DefaultPullConsumer. Atualize para a versão 5.x. Consulte Visão geral do SDK.

O Remoting SDK utiliza a seguinte dependência Maven e formato de endpoint:

<dependency>
    <groupId>org.apache.rocketmq</groupId>
    <artifactId>rocketmq-client</artifactId>
    <version>{version}</version>
</dependency>
producer.setNamesrvAddr("xxx:9876");
consumer.setNamesrvAddr("xxx:9876");
Nota

Se você envia e recebe mensagens pelo conector RocketMQ Flink, use a versão mais recente do SDK (compilação necessária). Consulte rocketmq-flink.

Mensagens agendadas e de nova tentativa

Verifique se o cluster de origem contém mensagens agendadas ou pendentes de nova tentativa. Após a migração, todas as conexões de produtores e consumidores passam para a instância do ApsaraMQ for RocketMQ. Mensagens agendadas e de nova tentativa remanescentes no cluster de origem podem não ser consumidas. Mantenha processos de consumidor em execução no cluster de origem para drenar essas mensagens antes de desativá-lo.

Planejar lotes de migração

A ferramenta de migração suporta migração por tópico com operações em lote, canary release e rollback, o que reduz o impacto de cada alteração.

  1. Selecione tópicos e planeje lotes. Identifique os tópicos a migrar e agrupe-os em lotes. Comece com tópicos de negócios não críticos.

  2. Coordene com equipes upstream e downstream. Notifique todos os aplicativos produtores e consumidores que usam os tópicos selecionados. Cada aplicativo deve atualizar seu endpoint.

Importante

Garanta que todos os aplicativos upstream e downstream atualizem seus endpoints. Aplicativos que não fizerem a troca podem causar atrasos no consumo de mensagens.

Como funciona

A migração segue cinco etapas, cada uma com verificações de validação integradas e suporte a rollback.

Migration process

Etapa

O que acontece

1. Avaliar a migração

Verifica a compatibilidade de versão e recursos entre o cluster de origem e a instância de destino. Define quais tópicos migrar em cada lote.

2. Configurar a rede

Fornece os detalhes de rede e de nós do cluster de origem. A ferramenta de migração usa essas informações para ler metadados do cluster por uma conexão de privilégio mínimo.

3. Migrar metadados

Seleciona tópicos e grupos de consumidores do cluster de origem e importa seus metadados para a instância de destino.

4. Alterar o endpoint

Atualiza o endpoint em todos os aplicativos produtores e consumidores do endereço do cluster de origem para o endereço da instância de destino.

5. Trocar o tráfego

Realiza a troca gradual de tráfego por tópico e move o tráfego de leitura e gravação do cluster de origem para a instância de destino.

Configurar a rede

Crie uma tarefa de migração e forneça os detalhes de rede do cluster Apache RocketMQ de origem. A ferramenta de migração usa esses detalhes para ler metadados do cluster e gerenciar a troca de tráfego.

O que a ferramenta de migração acessa

A ferramenta de migração acessa apenas as seguintes informações do cluster de origem (privilégio mínimo):

  • Metadados de tópicos

  • Metadados de grupos de consumidores

  • Registro de roteamento dinâmico para tópicos

  • Status de conexão do consumidor e acumulação de mensagens

A ferramenta não acessa outros dados do cluster nem grava configurações no cluster de origem.

Importante

Verifique as configurações de rede antes de prosseguir. Ao passar para a próxima etapa, não será possível retornar para modificar as configurações de rede. Para alterar a configuração de rede, crie uma nova tarefa de migração.

Procedimento

  1. Faça login no console do ApsaraMQ for RocketMQ.

  2. Na barra de navegação superior, selecione a região onde o cluster de origem e a instância de destino estão localizados. No painel de navegação à esquerda, escolha RocketMQ Copilot > Migration to Cloud.

  3. Na página Migration to Cloud, clique em Create Task.

  4. No painel Create Migration Task, configure os parâmetros descritos na tabela a seguir e clique em OK.

  5. Na etapa Network Settings do assistente de migração, insira os detalhes de rede do cluster Apache RocketMQ de origem e clique em Configure Network.

  6. Aguarde a conclusão da configuração de rede e clique em Next.

Referência de parâmetros

Parâmetro

Descrição

Exemplo

Cluster Type

O ambiente de rede do cluster de origem. Internet-connected Cluster: implantado pela Internet. VPC-connected Cluster: implantado em uma VPC da Alibaba Cloud.

VPC-connected Cluster

Cluster Name

Um nome personalizado para identificar o cluster de origem. Usado apenas para exibição.

first

VPC

O ID da VPC onde o cluster de origem está implantado. Necessário apenas para VPC-connected Cluster.

vpc-bp1mhd\\\\\\24chrxn

vSwitch

O vSwitch que permite à ferramenta de migração acessar a rede do cluster de origem. Selecione um vSwitch em uma zona suportada pela região da tarefa de migração. Consulte Regiões e zonas. Se nenhum vSwitch estiver disponível, crie um em uma zona suportada. Consulte Criar e gerenciar vSwitches. Necessário apenas para VPC-connected Cluster.

vsw-bp1hejs\\\\\\0los38rn

Security Group

O grupo de segurança para acesso à rede. Use o mesmo grupo de segurança da instância do Elastic Compute Service (ECS) que executa o cluster de origem. Se usar um grupo diferente, certifique-se de que as regras permitam o acesso à instância de destino. Necessário apenas para VPC-connected Cluster.

sg-bp160q\\\\\\vtcxvwl

Name Server Address

Os endereços IP de todos os name servers no cluster de origem. Separe vários endereços com vírgulas (,) ou ponto e vírgula (;).

192.168.XX.XX:9876

Access Credential

N/A: Access Control List (ACL) não está habilitada. ACL: ACL está habilitada. Forneça credenciais de administrador.

ACL

Username

O nome da conta de administrador. Necessário apenas quando a ACL está habilitada.

admin

Password

A senha da conta de administrador. Necessária apenas quando a ACL está habilitada.

\\\\\\

Importante

Especifique todos os endereços IP dos name servers. Endereços ausentes podem impedir que tópicos apareçam durante a migração.

Migrar metadados

Selecione os tópicos e grupos de consumidores a migrar com base no plano de migração. A ferramenta de migração lê todos os tópicos e grupos do cluster de origem e os exibe para seleção.

Importante

Não é possível retornar a esta etapa após prosseguir. Certifique-se de importar todos os tópicos e grupos do lote de migração atual antes de clicar em Next. Tópicos ausentes devem ser criados manualmente depois.

Procedimento

  1. Na etapa Metadata Migration, clique na aba Topic Metadata.

  2. Selecione um tópico na lista, escolha o Message Type correto na lista suspensa e clique em Confirm and Import. Para importar vários tópicos simultaneamente, selecione-os e clique em Batch Import.

    Importante

    O Apache RocketMQ 4.x não define tipos de mensagem no nível do tópico. O ApsaraMQ for RocketMQ valida se o tipo de mensagem atribuído corresponde às mensagens reais no tópico. Selecione o tipo com base na lógica do aplicativo. Se você selecionar um tipo incorreto, o envio ou recebimento de mensagens falhará após a migração. Em caso de dúvida sobre o tipo de mensagem, abra um ticket.

  3. Clique na aba Group Metadata. Selecione um grupo de consumidores, escolha a Consumption Order correta na lista suspensa e clique em Confirm and Import. Para importar vários grupos simultaneamente, selecione-os e clique em Batch Import.

    Importante

    No SDK do Apache RocketMQ 4.x, a ordem de consumo de mensagens é especificada no lado do cliente. No ApsaraMQ for RocketMQ 5.x, o broker controla a ordem de consumo no nível do grupo. Selecione a ordem com base nos requisitos do aplicativo. Uma ordem incorreta causa exceções de consumo. Em caso de dúvida, abra um ticket.

  4. Verifique se todos os tópicos e grupos deste lote de migração foram importados e clique em Next.

Alterar o endpoint

Atualize o endpoint em todos os aplicativos produtores e consumidores do endereço do cluster de origem para o endereço da instância de destino do ApsaraMQ for RocketMQ 5.x. Durante esta etapa, a ferramenta de migração continua a rotear o tráfego para o cluster de origem. Portanto, o envio de mensagens funciona normalmente, independentemente da ordem em que os aplicativos atualizam seus endpoints.

Antes de prosseguir

  • Após alterar o endpoint, reinicie cada aplicativo para conectá-lo à instância de destino.

  • Certifique-se de que todos os aplicativos produtores e consumidores atualizem seus endpoints:

    • Produtores que não fizerem a troca: algumas mensagens falharão no envio.

    • Consumidores que não fizerem a troca: as mensagens acumularão e não poderão ser consumidas.

Exemplos de alteração de endpoint

Apache RocketMQ Remoting SDK

Antes (cluster de origem):

producer.setNamesrvAddr("192.168.XX.XX:9876");
consumer.setNamesrvAddr("192.168.XX.XX:9876");

SDK version >= 4.5.1

Depois (instância de destino) -- versão 4.5.1 e posteriores:

producer.setNamesrvAddr("rmq-cn-pe334******-vpc.cn-hangzhou.rmq.aliyuncs.com:8080");
// vipChannelEnabled defaults to false. If set to true, comment out this line.
// producer.setVipChannelEnabled(false);

consumer.setNamesrvAddr("rmq-cn-pe334******-vpc.cn-hangzhou.rmq.aliyuncs.com:8080");
// vipChannelEnabled defaults to false. If set to true, comment out this line.
// consumer.setVipChannelEnabled(false);

SDK version < 4.5.1

Depois (instância de destino) -- versões anteriores à 4.5.1:

producer.setNamesrvAddr("rmq-cn-pe334******-vpc.cn-hangzhou.rmq.aliyuncs.com:8080");
// vipChannelEnabled defaults to true. Set it to false.
producer.setVipChannelEnabled(false);

consumer.setNamesrvAddr("rmq-cn-pe334******-vpc.cn-hangzhou.rmq.aliyuncs.com:8080");
// vipChannelEnabled defaults to true. Set it to false.
consumer.setVipChannelEnabled(false);

Apache RocketMQ gRPC SDK

Antes:

ClientConfiguration clientConfiguration = ClientConfiguration.newBuilder()
            .setEndpoints("192.168.XX.XX:9876")
            .setCredentialProvider(sessionCredentialsProvider)
            .build();

Depois:

ClientConfiguration clientConfiguration = ClientConfiguration.newBuilder()
            .setEndpoints("rmq-cn-pe334******-vpc.cn-hangzhou.rmq.aliyuncs.com:8080")
            .setCredentialProvider(sessionCredentialsProvider)
            .build();

Procedimento

Depois que todos os aplicativos tiverem atualizado seus endpoints e reiniciado, clique em Next na etapa Change Endpoint.

Trocar o tráfego

Troque o tráfego de leitura e gravação por tópico do cluster de origem para a instância de destino. A troca de tráfego avança por quatro estágios sequenciais para cada tópico.

Antes de prosseguir

  • Em cada estágio, verifique se as mensagens estão sendo enviadas e recebidas corretamente antes de continuar. Se ocorrer um problema, faça rollback para o estágio anterior e solucione-o.

  • Troque o tráfego de todos os tópicos migrados e confirme a operação normal antes de concluir a tarefa de migração. As configurações de troca de tráfego não podem ser modificadas depois que a tarefa for marcada como concluída.

Estágios de troca de tráfego

Cada tópico avança pelos seguintes quatro estágios:

Estágio

Tráfego de leitura

Tráfego de gravação

O que verificar

Read and write in source cluster (inicial)

Cluster de origem

Cluster de origem

Estado inicial. Nenhuma ação necessária.

Write in source cluster, read in both clusters

Clusters de origem e destino

Cluster de origem

Consumidores recebem mensagens de ambos os clusters. Verifique se o consumo funciona corretamente no destino.

Write in destination cluster, read in both clusters

Clusters de origem e destino

Cluster de destino

Produtores enviam para o destino. Verifique se as mensagens são enviadas e recebidas corretamente. Aguarde até que as mensagens acumuladas no cluster de origem sejam totalmente consumidas.

Read and write in destination cluster (final)

Cluster de destino

Cluster de destino

A migração está concluída para este tópico. Todo o tráfego flui pela instância de destino.

Topologia de tráfego para cada estágio:

Estágio

Topologia

Leitura e gravação no cluster de origem

Read and write in source cluster

Gravação na origem, leitura em ambos

Write in source, read in both

Gravação no destino, leitura em ambos

Write in destination, read in both

Leitura e gravação no cluster de destino

Read and write in destination cluster

Verificações em cada estágio

Estágio

Verificações realizadas

Mudar para write in source, read in both

O tópico existe em ambos os clusters. As permissões foram concedidas corretamente. Todos os clientes estão conectados ao cluster de destino.

Mudar para write in destination, read in both

Mesmas verificações do estágio anterior.

Mudar para read and write in destination

Todas as verificações anteriores, além de: nenhuma mensagem está sendo produzida no cluster de origem e não há acúmulo de mensagens no cluster de origem.

Procedimento

  1. Na etapa Message Migration, selecione o tópico a migrar e verifique seu status de validação.

    • Check Passed: Prossiga para a próxima etapa.

    • Não passou: Solucione o problema com base no resultado da verificação e clique em Re-verify até que a verificação seja aprovada.

    • Não passou, mas confirmado como não bloqueante: Clique em Ignore Check e prossiga.

  2. Na coluna Actions, clique em Switch Traffic.

  3. Na caixa de diálogo de confirmação, clique em OK.

  4. Repita as etapas 1 a 3 para cada estágio até que Traffic Switching Stage mostre Read and Write in Destination Cluster.

  5. Depois que todos os tópicos forem totalmente trocados, clique em Migrated na parte inferior da página.

Operações adicionais

As seguintes operações estão disponíveis na página Message Migration:

  • Roll Back

    • Roll back to the previous stage: Reverte o tópico para o último estágio em que a migração funcionava corretamente. Solucione problemas antes de prosseguir novamente.

    • Roll back to the initial stage: Reverte para o estado de roteamento original. Use apenas para solução de problemas de emergência.

      Nota

      Fazer rollback para o estágio inicial pode causar atraso ou impossibilidade de processamento de mensagens não consumidas produzidas durante os estágios anteriores.

  • Create Topic: Se um tópico não foi selecionado durante a migração de metadados, crie-o diretamente na instância de destino do ApsaraMQ for RocketMQ 5.x.

  • Batch Traffic Switching / Batch Rollback: Troca o tráfego ou faz rollback para vários tópicos simultaneamente. Ambas as operações aplicam-se apenas a tópicos no mesmo estágio de troca de tráfego.

Referências

  • Para obter informações sobre as diferenças entre o Apache RocketMQ open-source e o ApsaraMQ for RocketMQ, incluindo o mecanismo de migração, consulte Visão geral da migração.

  • Após a conclusão da tarefa de migração, use métricas no painel do ApsaraMQ for RocketMQ para verificar se a instância está funcionando conforme o esperado. Se ocorrerem exceções, faça rollback da tarefa. Para mais informações, consulte Painel e Rollback.